There are methods that do not implement any minimal restrictions

[c4-bot-2]

Lines of code

https://github.com/code-423n4/2024-01-curves/blob/516aedb7b9a8d341d0d2666c23780d2bd8a9a600/contracts/Curves.sol#L114 https://github.com/code-423n4/2024-01-curves/blob/516aedb7b9a8d341d0d2666c23780d2bd8a9a600/contracts/Curves.sol#L159 https://github.com/code-423n4/2024-01-curves/blob/516aedb7b9a8d341d0d2666c23780d2bd8a9a600/contracts/Curves.sol#L162 https://github.com/code-423n4/2024-01-curves/blob/516aedb7b9a8d341d0d2666c23780d2bd8a9a600/contracts/Curves.sol#L108

Vulnerability details

Impact

All over the protocol there are methods like (setReferralFeeDestination, setERC20Factory, etc) which apply changes and do not have minimal restrictions like not using address 0. Simple mistake by the caller can lead to huge protocol issues in future.

Proof of Concept

All of the links above are methods which allow the caller to mistakenly change the core logic of the protocol to some wrong input like address 0, which can affect the overall functionality of the system. Consider integrating some minimal checks like not using address 0 when calling them.

Tools Used

Manual review

Recommended Mitigation Steps

Require some minimal restrictions

Assessed type

Context

[c4-pre-sort]

raymondfam marked the issue as insufficient quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #88

[c4-judge]

alcueca changed the severity to QA (Quality Assurance)

[c4-judge]

alcueca marked the issue as grade-b