Closed c4-bot-2 closed 1 month ago
koolexcrypto changed the severity to QA (Quality Assurance)
koolexcrypto marked the issue as grade-c
This previously downgraded issue has been upgraded by koolexcrypto
koolexcrypto marked the issue as duplicate of #687
koolexcrypto marked the issue as duplicate of #218
koolexcrypto changed the severity to QA (Quality Assurance)
Lines of code
https://github.com/code-423n4/2024-07-traitforge/blob/main/contracts/EntityForging/EntityForging.sol#L125-L126 https://github.com/code-423n4/2024-07-traitforge/blob/main/contracts/EntityForging/EntityForging.sol#L146-L148 https://github.com/code-423n4/2024-07-traitforge/blob/main/contracts/EntityForging/EntityForging.sol#L156-L159
Vulnerability details
Impact
Given the scenario below:
tokenId
99: 0.01 ethertokenId
99 withtokenId
100 and pays/sends 0.1 etherOutcome becomes:
uint256 forgingFee = _forgerListingInfo.fee;
= 0.01 ether / 1e16uint256 devFee = forgingFee / taxCut;
= 0.01 / 10 = 1e15 / 0.001 etheruint256 forgerShare = forgingFee - devFee;
= 1e16 - 1e15 = 9e15 / 0.009 ether(bool success, ) = nukeFundAddress.call{ value: devFee }('');
nukeFund contract receives 0.001 ether(bool success_forge, ) = forgerOwner.call{ value: forgerShare }('');
Forger token owner receives 0.009 etherEntityForging
contractThus the merger ends up losing the excess ethers sent. Given that a similar scenario is handled below in the
TraitForge
contract, this issue requires mitigation as well during token forging.Proof of Concept
EntityForging.sol
Tools Used
Manual review
Recommended Mitigation Steps
Assessed type
Payable