The StrategyMainnet
contract uses the Checks-Effects-Interactions (CEI) pattern, which mitigates reentrancy risk but does not entirely eliminate it. By not employing additional safeguards such as reentrancy guards, an attacker could potentially exploit an external contract call to re-enter functions like claimAndSwap
and repeatedly withdraw or manipulate funds.
A malicious or compromised transmuter
or router
contract could invoke a callback to StrategyMainnet
during the external call.
If the callback attempts to call claimAndSwap
(or another critical function) again before the first call completes, the contract could allow multiple re-entries, enabling the attacker to drain funds.
The following illustrates how an attacker could exploit reentrancy if the transmuter is replaced or upgraded to a malicious version.This PoC assumes an attacker has deployed a malicious contract masquerading as a legitimate transmuter.
Whenever claimAndSwap calls transmuter.claim(...), the malicious contract re-enters claimAndSwap before the first call finishes.
Likelihood: Medium
Exploitation requires that an attacker either controls or compromises the external contract (e.g., transmuter
or router
). In scenarios where the external contracts are well-audited and upgradable only through secure governance, the likelihood decreases. However, if there's any possibility of an attacker deploying or swapping in a malicious contract, the risk elevates to high.
Impact: High
In the event of a successful reentrancy exploit, attackers could repeatedly execute sensitive functions to drain funds or corrupt the strategy’s accounting. This could lead to substantial financial losses and undermine the strategy’s integrity.
Aderyn, Slither, Manual code review, AI
Use OpenZeppelin’s ReentrancyGuard to add the nonReentrant
modifier to critical functions like claimAndSwap
.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.