In the InheritanceManager contract, the _setDeadline() function is called at the end of several owner-controlled functions. However, if these functions revert before reaching the deadline update (due to failed transfers or insufficient balances), the inactivity timer will not be reset. This can lead to unintended inheritance triggers when an owner is actively using the contract but experiencing transaction failures.
The _setDeadline() function updates the deadline state variable, which is critical for the inheritance mechanism. It's called at the end of functions like sendERC20() and sendETH() but only after potentially reverting operations. For example:
same beahviour in sendETH()
This vulnerability can lead to:
Premature Inheritance: If an owner makes multiple failed attempts to send funds (due to recipient contract errors or insufficient balances), the deadline won't be extended despite active contract interaction. After 90 days from the last successful transaction, inheritance can be triggered even though the owner is actively using the contract.
Security Implications: The core security assumption of the contract is that inheritance should only trigger after 90 days of owner inactivity (i.e. no functions/contracts called). This vulnerability breaks that assumption.
Trust Issues: Beneficiaries could potentially gain access to funds even when the owner is actively managing the contract but experiencing technical issues.
Manual code review
Static analysis
To fix this vulnerability, implement one of these solutions:
Move the _setDeadline() call to the beginning of each function after the modifier checks:
Create an Activity Tracking Modifier: Implement a modifier that updates the deadline and apply it to all owner-controlled functions:
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.