Liquidity Management
Gamma
DeFiFoundry
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

hardcoded paraswap callee address

ashishlach

Summary

The function _validateCallData() under ParaSwapUtils.sol checks whether to address is correct paraswap address or not. But currently it is hardcode which can lead to problems in future. This protocol is not even upgradable. So there is no way to update this. It is better to store paraswap address in a storage variable and allow admin to update in future

function _validateCallData(address to, bytes memory callData) internal view {
require(to == address(0xDEF171Fe48CF0115B1d80b88dc8eAB59176FEe57), "invalid paraswap callee");
​

Vulnerability Details

Main reason why we should not use hardcoded paraswap address in our protocol ?

  1. If an attacker gains control over the address (e.g., due to a vulnerability in ParaSwap), our protocol will inherit the risk and there is no way to update this to new address.

Code:

https://github.com/CodeHawks-Contests/2025-02-gamma/blob/84b9da452fc84762378481fa39b4087b10bab5e0/contracts/libraries/ParaSwapUtils.sol#L29

Impact

Fund loss if attacker gains access to the hardcoded paraswap address and there is no way for gamma admin team to update to new paraswap address.

Tools Used

Manual review

Recommendations

Store the address in a variable and have a setter function which can allow only owner to update this variable anytime

Updates

Lead Judging Commences

n0kto Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

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.

Suppositions

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.