The _payExecutionFee
function sends ETH to GmxProxy
without validating the msg.value
. This allows an attacker to send an inflated execution fee (more ETH than required) and potentially manipulate the contract's state. The _payExecutionFee
function does not check if the msg.value
is reasonable or matches the required execution fee.
The refundExecutionFee
function allows arbitrary address recipients without proper checks. This means an attacker can specify a malicious recipient address to drain ETH from the GmxProxy
contract.
The attacker calls the deposit
function in PerpetualVault.sol
and sends an inflated execution fee (e.g., 10 ETH instead of the required 0.1 ETH).
The _payExecutionFee
function in PerpetualVault.sol
does not validate the msg.value
, so it accepts the inflated fee and transfers the ETH to GmxProxy
.
refundExecutionFee
with Malicious RecipientThe attacker calls the refundExecutionFee
function in GmxProxy.sol
and specifies a malicious recipient address (e.g., their own wallet).
The refundExecutionFee
function does not validate the recipient address or the amount being refunded, so it transfers the ETH to the attacker's address.
GmxProxy
The attacker repeats this process multiple times, draining all ETH from the GmxProxy
contract.
As a result, the protocol loses its ability to execute orders, as it no longer has ETH to pay for gas fees.
The _payExecutionFee
function does not check if the msg.value
is reasonable or matches the required execution fee. This allows an attacker to send an inflated amount of ETH, which can later be exploited.
The refundExecutionFee
function does not validate the recipient address. This allows an attacker to specify their own address and drain ETH from the contract.
It allows an attacker to drain all ETH from the GmxProxy
contract.
It disrupts the protocol's ability to execute orders, which is a critical function.
It can be exploited repeatedly with minimal cost to the attacker.
manual code review
Restrict the refundExecutionFee
function to only allow the PerpetualVault
contract to call it.
Validate the recipient address to ensure it is a legitimate user.
Ensure that the msg.value
matches the required execution fee. Revert if the amount is too high or too low.
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.