DeFiFoundry
50,000 USDC
View results
Submission Details
Severity: low
Invalid

Reentrancy Risk via _doDexSwap Calls

Summary

A critical reentrancy vulnerability has been identified in the runNextAction function due to unsafe external contract interactions during DEX swaps. This allows malicious ERC20 token contracts to reenter the protocol through callback mechanisms, potentially leading to fund drainage and state corruption. The root cause is the absence of reentrancy guards when interacting with external swap adapters.


Vulnerability Details

Technical Background

The vulnerability manifests in the DEX swap execution path:

function runNextAction(..., bytes[] memory metadata) external nonReentrant gmxLock {
...
(, bytes memory data) = abi.decode(metadata[1], (PROTOCOL, bytes));
_doDexSwap(data, false); // ← Vulnerable entry point
}
function _doDexSwap(bytes memory data, bool direction) internal {
(address to, uint256 amount, bytes memory callData) = abi.decode(data, (address,uint256,bytes));
ParaSwapUtils.swap(to, callData); // ← Untrusted external call
}
  1. The nonReentrant modifier only protects the outer runNextAction call

  2. Multiple swap operations in a single transaction enable callback-based reentry

  3. State variables (swapProgressData) are updated after external calls

Impact

  1. Recursive Withdrawals: Bypass share calculation logic through state corruption

  2. Oracle Manipulation: Interleave price updates during reentry windows

  3. Governance Takeover: If using shares for voting, enables instant majority control

Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Suppositions

There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Suppositions

There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!