There is no re-entry risk on true ERC-20 tokens that work according to the spec (i.e. audited, etc.).
However you can write a malicious ERC-20 with custom transferFrom() or approve() that have re-entrancy hooks to attack a target.
Furthermore ERC-777 is backwards compatible token standard with ERC-20 standard. ERC-777 has better usability, but it has transfer hooks that can cause re-entrancy.
Project developers have mentioned Reentrancy with the information below. However, to prevent Reentrancy, only the Checks-effects-interaction pattern is not enough.
VTVLVesting.sol#L385
// After the "books" are set, transfer the tokens
// Reentrancy note - internal vars have been changed by now
// Also following Checks-effects-interactions pattern
ERC20 generally doesn't result in reentrancy, however ERC777 tokens can and they can maskerade as ERC20. So if a contract interacts with unknown ERC20 tokens it is better to be safe and consider that transfers can create reentrancy problems.
Although reentrancy attack is considered quite old over the past two years, there have been cases such as:
Uniswap/LendfMe hacks (2020) ($25 mln, attacked by a hacker using a reentrancy)
The BurgerSwap hack (May 2021) ( $7.2 million because of a fake token contract and a reentrancy exploit.)
The SURGEBNB hack (August 2021) ($4 million seems to be a reentrancy-based price manipulation attack.)
CREAM FINANCE hack (August 2021) ($18.8 million, reentrancy vulnerability allowed the exploiter for the second borrow.)
Siren protocol hack (September 2021) ($3.5 million, AMM pools were exploited through reentrancy attack.)
Type of Reentrancy
Details
1 - Single Function Reentrancy
2 - Cross-Function Reentrancy
3 - Cross-Contract Reentrancy
Lines of code
https://github.com/code-423n4/2022-09-vtvl/blob/main/contracts/VTVLVesting.sol#L364-L392
Vulnerability details
Impact
Missing ReEntrancy Guard to Withdraw function
Proof of Concept
There is no re-entry risk on true ERC-20 tokens that work according to the spec (i.e. audited, etc.).
However you can write a malicious ERC-20 with custom transferFrom() or approve() that have re-entrancy hooks to attack a target.
Furthermore ERC-777 is backwards compatible token standard with ERC-20 standard. ERC-777 has better usability, but it has transfer hooks that can cause re-entrancy.
Project developers have mentioned Reentrancy with the information below. However, to prevent Reentrancy, only the Checks-effects-interaction pattern is not enough.
openzeppelin's view on the reentrancy problem
ERC20 generally doesn't result in reentrancy, however ERC777 tokens can and they can maskerade as ERC20. So if a contract interacts with unknown ERC20 tokens it is better to be safe and consider that transfers can create reentrancy problems.
Although reentrancy attack is considered quite old over the past two years, there have been cases such as:
Uniswap/LendfMe hacks (2020) ($25 mln, attacked by a hacker using a reentrancy)
The BurgerSwap hack (May 2021) ( $7.2 million because of a fake token contract and a reentrancy exploit.)
The SURGEBNB hack (August 2021) ($4 million seems to be a reentrancy-based price manipulation attack.)
CREAM FINANCE hack (August 2021) ($18.8 million, reentrancy vulnerability allowed the exploiter for the second borrow.)
Siren protocol hack (September 2021) ($3.5 million, AMM pools were exploited through reentrancy attack.)
Type of Reentrancy
Details 1 - Single Function Reentrancy 2 - Cross-Function Reentrancy 3 - Cross-Contract Reentrancy
Tools Used
Manuel code review
Recommended Mitigation Steps
Use Openzeppelin or Solmate Re-Entrancy pattern
Here is a example of a re-entracy guard