This is an interesting case we all can learn from. Smart contract ERC-827 allows / potentially enables a bad contract security practice.
From issue comments on the ERC-827 EIP by the security researcher:
We wrote a blog post, how replacing ERC20 with ERC827, can lead to unexpected reentrancy attacks.
…
- Given that potential use cases of transferAndCall are unclear, I see the value of our article in clarifying how it should not be used.
- Similar issues apply to approveAndCall, however, given that this functionality does not exist in ERC20 (as you said), we would have had to construct an example with vulnerable code to use it. If you have concrete cases, where approveAndCall is called from a smart contract we would be happy to check.
Overall, our intention was just to notify people that special care is needed when using these functions inside a smart contract.
– ritzdorf, CTO @ ChainSecurity
Related tweets and stories:
From OpenZeppelin’s GitHub issue on this:
It is a really bad practice to allow the abuse of CUSTOM_CALL in token standard.