A vulnerability has been identified in the GMXProxy contract where the setPerpVault
function uses tx.origin
for access control instead of msg.sender
. This could allow an attacker to gain unauthorized admin privileges through a sophisticated phishing attack, potentially compromising the entire protocol's security.
The vulnerability exists in the setPerpVault
function of the GMXProxy contract:
The function uses tx.origin
for owner authentication instead of the more secure msg.sender
. This creates a potential attack vector where a malicious contract could bypass the ownership check through transaction origin spoofing.
An attacker could exploit this vulnerability through the following attack flow:
Deploy a malicious contract with an attractive airdrop function ,note that beforehand we need to be a usual user by deposit funds (small but okay so that we can call withdraw from perpVault)
Create a phishing campaign targeting the owner
When the owner interacts with the malicious contract:
The transaction origin will be the owner's address
The malicious contract can call setPerpVault through its receive function
The tx.origin check will pass, allowing the attack to succeed
The vulnerability could allow an attacker to:
Take control of the GMXProxy contract by changing the perpVault address
Manipulate protocol operations through unauthorized admin access
Potentially drain funds or disrupt protocol functionality
The impact is considered medium instead of high because:
It compromises a critical access control mechanism
Could lead to complete protocol compromise
Requires only a successful phishing attempt on the owner
Manual code review
Replace tx.origin with msg.sender
Lightchaser: Medium-5
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.