Arbitrary State Manipulation via setVaultState
Summary
While the setVaultState function is not directly called in the provided code, its mere presence in the contract introduces a critical vulnerability. The function allows the owner to unilaterally override core vault state variables, creating a silent backdoor for fund theft or protocol manipulation.
Key Clarifications
-
Unused ≠ Safe:
Even if not currently called, the function exists in the contract bytecode and is callable by the owner at any time. This violates the principle of least privilege. -
No On-Chain Invocation Required for Risk:
The function's existence alone means a malicious/compromised owner can activate it in the future without requiring code changes, as it is already deployed.
Revised Exploit Scenario
-
Stealth Attack:
Owner waits until the vault holds significant user funds.
Calls
setVaultStateto:Set
curPositionKey = 0x0(fake closed position)Set
_gmxLock = false(bypass withdrawal locks)
Withdraws all collateral while the vault falsely reports active positions.
-
Freeze Attack:
Owner sets
_gmxLock = truepermanently, blocking all user withdrawals.
Impact Validation
Direct Loss of Funds:
✅ Confirmed: The function allows the owner to fabricate vault states to bypass withdrawal checks.
✅ Provable: Executable in one transaction with no dependencies.
Recommendations
Remove
setVaultState:// DELETE THIS FUNCTIONfunction setVaultState(...) external onlyOwner { ... }Time-Locked Emergency Recovery:
If state recovery is needed, implement a 7-day timelock for emergency state changes (example => OpenZeppelin'sTimelockController).
Why This Is Still Critical
Silent Backdoor: The function violates the protocol's trust model by allowing unilateral state overrides.
No Code Changes Needed for Exploit: The owner can trigger it at any time post-deployment.
Lead Judging Commences
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.
Admin is trusted / Malicious keepers
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. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."
Appeal created
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.
Admin is trusted / Malicious keepers
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. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.