GmxProxy.sol::setPerpVault
Impact: High
Likelihood: Medium
The protocol use tx.origin to confirm the ownerablity could lead many issues
The function setPerpVault incorrectly uses tx.origin to verify ownership, making it vulnerable to phishing attacks and breaking compatibility with multisig wallets and contract-based interactions. This issue can allow an attacker to trick the contract owner into unintentionally setting an attacker-controlled vault address.
tx.origin refers to the original externally owned account (EOA) that initiated the transaction, even if the call passes through multiple smart contracts
This makes the function vulnerable to phishing: a malicious contract could trick the owner into executing an external call that indirectly calls setPerpVault (Tx-Origin Phishing Attack Pattern).
Composability issue: The function cannot be called from multisigs, DAOs, or contract-based automation.
Ownership validation bypass: An attacker could steal control over the vault settings if the owner unknowingly interacts with a malicious contract.
Funds misdirection or loss: If the vault manages assets, an attacker could redirect funds to their own address.
Breaks interoperability: The contract cannot be used with multisigs, governance contracts, or relayers, limiting its usability in DeFi and DAOs.
Manual Code Review
Replace tx.origin with msg.sender.
Role-Based Access Control (RBAC) use OpenZeppelin’s Ownable onlyOwner
Modifier.
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.