A vulnerability has been identified in the GMXProxy contract where external calls to other contracts are not properly checking return values. This oversight could lead to silent failures in token transfers and contract interactions, inconsistent contract state.
The GMXProxy contract contains multiple instances of unchecked external calls, particularly in token transfer operations. The most critical instances are found in:
Token transfers using IERC20.safeTransfer
External contract calls using call()
Cross-contract interactions with GMX protocol components
The vulnerability stems from two primary technical issues:
External calls return boolean values indicating success/failure
Contract execution continues even if external calls fail silently
This creates a situation where the contract can proceed with incorrect assumptions about the success of external operations.
The vulnerability could lead to several severe consequences:
Users might not receive their funds
Contract state becomes inconsistent with reality
Failed transfers recorded as successful
Malicious contracts could exploit unchecked returns
Hidden errors might remain undetected
The following tools were utilized to identify and verify this vulnerability:
Static analysis using Slither
Manual code review
Contract flow analysis
To address this vulnerability, implement the following changes:
Add Return Value Checks
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.
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.
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.
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.
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.