Closed code423n4 closed 1 year ago
minhquanym marked the issue as primary issue
minhquanym marked the issue as high quality report
POC -> high quality but probably Low
CJ42 marked the issue as disagree with severity
We consider this issue more as a QA than Medium. The severity is inflated.
This issue is also mentioned in a QA report (point 3) --> https://github.com/code-423n4/2023-06-lukso-findings/blob/main/data/gpersoon-Q.md#3-renounceownership-doesnt-notify-universalreceiver
CJ42 marked the issue as sponsor disputed
trust1995 changed the severity to QA (Quality Assurance)
trust1995 marked the issue as grade-c
Lines of code
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP14Ownable2Step/LSP14Ownable2Step.sol#L150
Vulnerability details
Impact
When confirming the renouncement of ownership, there are no LSP1 hooks, such as sending a
_TYPEID_LSP14_OwnershipTransferred_SenderNotification
message.As a result, contracts that use LSP10 data keys will contain keys for addresses for which they are no longer the owner of, contradicting the LSP10 standard.
Proof of Concept
A test written in foundry is provided where a universal profile implementing an LSP1 UniversalReceiver delegation still has keys for vaults that have been renounced.
Tools Used
Manual
Recommended Mitigation Steps
It is recommended to include an LSP1 hook when renouncing ownership.
Assessed type
Other