In Stablecoin.sol at lines XX-YY, the erc20Rescue function is defined to accept ERC20PermitUpgradeable tokens, restricting its compatibility with standard ERC20 tokens that do not implement the permit extension.
Internal pre-conditions
The contract must attempt to rescue a token that does not implement ERC20PermitUpgradeable.
The SUPPORT_ROLE holder initiates the rescue.
External pre-conditions
Users may send unsupported ERC20 tokens to the contract, necessitating rescue operations.
Third-party ERC20 tokens without permit functionalities are present in the ecosystem.
Attack Path
Attack Path:
A user sends an ERC20 token that does not implement ERC20PermitUpgradeable to the contract.
The SUPPORT_ROLE holder attempts to rescue the token using erc20Rescue, which fails due to type incompatibility.
The token remains locked in the contract, causing operational issues.
Impact
Certain ERC20 tokens cannot be rescued, leading to potential loss of funds for users who mistakenly send unsupported tokens to the contract.
PoC
No response
Mitigation
Use Generic Interfaces: Modify the erc20Rescue function to accept the more general IERC20 interface, increasing compatibility with a wider range of ERC20 tokens.
CipherHawk
High
Support role may fail to rescue certain ERC20 tokens
Summary
https://github.com/sherlock-audit/2024-11-telcoin/blob/main/telcoin-audit/contracts/stablecoin/Stablecoin.sol#L19 The erc20Rescue function in Stablecoin.sol uses ERC20PermitUpgradeable as the parameter type instead of the more general IERC20. This will prevent rescuing certain ERC20 tokens that do not adhere to the ERC20PermitUpgradeable interface, as the function expects specific functionalities not present in all ERC20 tokens.
Root Cause
In Stablecoin.sol at lines XX-YY, the erc20Rescue function is defined to accept ERC20PermitUpgradeable tokens, restricting its compatibility with standard ERC20 tokens that do not implement the permit extension.
Internal pre-conditions
The contract must attempt to rescue a token that does not implement ERC20PermitUpgradeable.
The SUPPORT_ROLE holder initiates the rescue.
External pre-conditions
Users may send unsupported ERC20 tokens to the contract, necessitating rescue operations.
Third-party ERC20 tokens without permit functionalities are present in the ecosystem.
Attack Path
Attack Path:
A user sends an ERC20 token that does not implement ERC20PermitUpgradeable to the contract.
The SUPPORT_ROLE holder attempts to rescue the token using erc20Rescue, which fails due to type incompatibility.
The token remains locked in the contract, causing operational issues.
Impact
Certain ERC20 tokens cannot be rescued, leading to potential loss of funds for users who mistakenly send unsupported tokens to the contract.
PoC
No response
Mitigation
Use Generic Interfaces: Modify the erc20Rescue function to accept the more general IERC20 interface, increasing compatibility with a wider range of ERC20 tokens.
function erc20Rescue( IERC20 token, address destination, uint256 amount ) external onlyRole(SUPPORT_ROLE) { token.safeTransfer(destination, amount); }
Ensure Compatibility: Continue using SafeERC20 to handle various ERC20 implementations safely.
Audit Token Standards: Regularly audit the ERC20 tokens integrated into the ecosystem to ensure compatibility with rescue mechanisms