SantasList::checkList() Allowing Anyone to Manipulate the Naughty/Nice ListThe SantasList::checkList() function is intended to be exclusively callable by Santa, as clearly stated in the protocol documentation:
"Only Santa to take the following actions:
checkList: A function that changes an address to a new Status"
However, the function is missing the onlySanta modifier that has already been defined in the codebase, making it publicly callable by any address without any restriction. This completely breaks the trust model of the protocol, as the entire system relies on Santa being the sole authority to determine who is naughty or nice.
Compare this to checkTwice() which correctly implements the modifier:
This inconsistency suggests the onlySanta modifier was simply forgotten during development.
Likelihood: HIGH
The function is publicly exposed with no access restriction whatsoever
Any address can call this function at any time with zero cost beyond gas fees
No special knowledge, role, or privilege is required to exploit this
The attack is trivially executable by anyone with basic Solidity knowledge
Impact: HIGH
Completely undermines the core purpose of the protocol, Santa's authority over the list is entirely bypassed
Attackers can freely register any address, including their own, with EXTRA_NICE status to maximize rewards
Since checkTwice() validates that s_theListCheckedOnce[person] matches the given status, an attacker who sets themselves as EXTRA_NICE in checkList() can then also manipulate checkTwice() indirectly, because now the validation in checkTwice() will pass when called by Santa with EXTRA_NICE
Attackers can drain the protocol by collecting both NFTs and SantaToken with an unlimited number of addresses
Legitimate users could also be maliciously marked as NAUGHTY by attackers, denying them their rightful presents
The following test demonstrates that any arbitrary user can call checkList() and set their own status to EXTRA_NICE without any Santa privileges, then proceed to collect both an NFT and SantaToken:
This can be repeated across unlimited attacker-controlled addresses to drain all protocol rewards.
The fix is straightforward — add the onlySanta modifier that already exists in the codebase to the checkList() function:
This ensures that only the trusted Santa address, set at deployment, retains exclusive authority over who gets marked on the list — preserving the intended trust model of the entire protocol.
## Description With the current design of the protocol, anyone is able to call `checkList` function in SantasList contract, while documentation says only Santa should be able to call it. This can be considered as an access control vulnerability, because not only santa is allowed to make the first check. ## Vulnerability Details An attacker could simply call the external `checkList` function, passing as parameter the address of someone else and the enum Status `NAUGHTY`(or `NOT_CHECKED_TWICE`, which should actually be `UNKNOWN` given documentation). By doing that, Santa will not be able to execute `checkTwice` function correctly for `NICE` and `EXTRA_NICE` people. Indeed, if Santa first checked a user and assigned the status `NICE` or `EXTRA_NICE`, anyone is able to call `checkList` function again, and by doing so modify the status. This could result in Santa unable to execute the second check. Moreover, any malicious actor could check the mempool and front run Santa just before calling `checkTwice` function to check users. This would result in a major denial of service issue. ## Impact The impact of this vulnerability is HIGH as it results in a broken mechanism of the check list system. Any user could be declared `NAUGHTY` for the first check at any time, preventing present collecting by users although Santa considered the user as `NICE` or `EXTRA_NICE`. Santa could still call `checkList` function again to reassigned the status to `NICE` or `EXTRA_NICE` before calling `checkTwice` function, but any malicious actor could front run the call to `checkTwice` function. In this scenario, it would be impossible for Santa to actually double check a `NICE` or `EXTRA_NICE` user. ## Proof of Concept Just copy paste this test in SantasListTest contract : ``` function testDosAttack() external { vm.startPrank(makeAddr("attacker")); // any user can checList any address and assigned status to naughty // an attacker could front run Santa before the second check santasList.checkList(makeAddr("user"), SantasList.Status.NAUGHTY); vm.stopPrank(); vm.startPrank(santa); vm.expectRevert(); // Santa is unable to check twice the user santasList.checkTwice(makeAddr("user"), SantasList.Status.NICE); vm.stopPrank(); } ``` ## Recommendations I suggest to add the `onlySanta` modifier to `checkList` function. This will ensure the first check can only be done by Santa, and prevent DOS attack on the contract. With this modifier, specification will be respected : "In this contract Only Santa to take the following actions: - checkList: A function that changes an address to a new Status of NICE, EXTRA_NICE, NAUGHTY, or UNKNOWN on the original s_theListCheckedOnce list." The following code will resolve this access control issue, simply by adding `onlySanta` modifier: ``` function checkList(address person, Status status) external onlySanta { s_theListCheckedOnce[person] = status; emit CheckedOnce(person, status); } ``` No malicious actor is now able to front run Santa before `checkTwice` function call. The following tests shows that doing the first check for another user is impossible after adding `onlySanta` modifier: ``` function testDosResolved() external { vm.startPrank(makeAddr("attacker")); // checklist function call will revert if a user tries to execute the first check for another user vm.expectRevert(SantasList.SantasList__NotSanta.selector); santasList.checkList(makeAddr("user"), SantasList.Status.NAUGHTY); vm.stopPrank(); } ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.