Thanks for the validation!
ERC1967 can help detect the changes in the underlying implementation contract but it can be too late for the accounts having given it approval to act upon it as the malicious author can enact an attack right after the upgrade.
When looking at this exploitation risk at large, I’m very concerned of the indefinite length of this exposed attack vector that every token approval given out can be a timed bomb in the future.
e.g. The majority of the current DeFi protocols need token approvals for an account interacting with it (e.g. Uniswap, Compound, Curve, and many many smaller DeFi protocols). If any of there protocols becomes malicious intentionally or due to a hack, all the users who have interacted with the protocol can lose all their tokens. (especially the case for ERC1155, where unscoped approval can lead to total loss of all the tokens held)
Using a rudimentary game theory analysis from three perspectives
(1) The upgradable proxy contract (e.g. DeFi protocol) would exploit the attack vector as long as
the value of all approved tokens (whether locked in the protocol or not) is greater than the cumulative future profit from the protocol
(2) The individual who has the access to upgrade the implementation contract (or the minimum number of admins when a multi-sig is used) would exploit the attack vector as long as the value of all the approved tokens (whether locked in the protocol or not) is greater than his/her own stake in the protocol + his reputation value
(3) End users would have to “ABSOLUTELY” trust a smart contract (DeFi protocol), no matter how much TVL it has, before interacting with it when a token approval is needed as one smart contract can potentially drain all the tokens being approved from an end user.
In regards to the implementation
As much as I want to keep the ERC token standards as they are since the problem is raised by upgradable proxy, I think we have to change how token approval works in the first place.