The removeBeneficiary
function silently removes the first beneficiary when attempting to remove an address that doesn't exist in the beneficiaries array. This occurs because the _getBeneficiaryIndex
helper function returns 0 (the default value for uint256) when the specified address isn't found, causing the function to delete the beneficiary at index 0 without any error or warning.
The vulnerability exists in the interaction between the removeBeneficiary
function and its helper function _getBeneficiaryIndex
:
When _beneficiary
is not found in the array, the function completes without setting _index
, which means it retains its default value of 0. The calling function then blindly uses this index to delete an entry, removing the first beneficiary rather than the intended one.
Additionally, there are two further issues in this function:
It uses delete
on an array element which sets it to the default value (address(0)) but doesn't remove the element from the array
It doesn't call _setDeadline()
to update the inactivity timer
This vulnerability has serious consequences for the inheritance management:
Unintended removal of legitimate beneficiaries
Loss of inheritance rights for the first beneficiary without any notification
If owner is the only beneficiary (in backup wallet scenario), could result in complete loss of fund access
No error message or event to indicate the failure
The contract state becomes inconsistent with the owner's intentions
The impact is rated as medium because:
It doesn't directly lead to immediate loss of funds
But it could result in fund distribution to wrong parties during inheritance
It fundamentally breaks a key contract mechanism
Manual code review and Foundry testing
Add the following test to InheritanceManager.t.sol
Run the test
Modify the removeBeneficiary
function to check if the address exists in the array:
Also implement utility functions to make the contract more user-friendly:
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.