Active Boosts

#59728 [SC-Low] underflow issue leading to a periodattimestamp dos

Submitted on Nov 15th 2025 at 09:13:54 UTC by @sol_4th05 for Audit Comp | Firelight

  • Report ID: #59728

  • Report Type: Smart Contract

  • Report severity: Low

  • Target: https://github.com/firelight-protocol/firelight-core/blob/main/contracts/FirelightVault.sol

  • Impacts:

    • Contract fails to deliver promised returns, but doesn't lose value

Description

Brief/Intro

Using the FirelightVault::periodAtTimestamp with an input Timestamp corresponding to a configuration period Config so that Config.epoch > block.timestamp the function reverts instead of returning the period number that it should return for the given input value.

Vulnerability Details

The FirelightVault::periodAtTimestamp reverts when called using timestamps that correspond to a configuration period not yet started.

@>    function periodAtTimestamp(uint48 timestamp) public view returns (uint256) {
        PeriodConfiguration memory periodConfiguration = periodConfigurationAtTimestamp(timestamp);
        // solhint-disable-next-line max-line-length
@>        return periodConfiguration.startingPeriod + _sinceEpoch(periodConfiguration.epoch) / periodConfiguration.duration;
    }

This, because of the function _sinceEpoch that takes the value provided in input by the users and without making any check, it uses it to compute its return value. If the value provided is in the future the result will underflow thus, reverting the call to the _sinceEpoch which will in turn revert the periodAtTimestamp function.

Impact Details

The function does not do what it should but there is no loss of money.

So the severity is low.

Although within the FirelightVault contract the periodAtTimestamp function is called just once by the FirelightVault::currentPeriod using always Time.timestamp() as argument, it is still public meaning that any user could call it.

This function should return the period number for a given timestamp input. However, because of the underflow issue above, if the periodConfiguration.epoch > block.timestamp it revert without returning the period number to the user.

References

https://github.com/firelight-protocol/firelight-core/blob/main/contracts/FirelightVault.sol#L246C4-L250

https://github.com/firelight-protocol/firelight-core/blob/main/contracts/FirelightVault.sol#L264-L266

Mitigation action

Link to Proof of Concept

https://gist.github.com/0x4th05/44d0057b29bad5c28607c6c107c6f1e5

Proof of Concept

Proof of Concept

Create a new foundry test file FirelightVault.t.sol like the one below and run forge test --mt testPeriodAtTimestamp -vvvvv.

To pass the test the FirelightVault::periodAtTimestamp should revert because of an underflow.

The result of the test below:

Previous59740 [SC-Low] periodattimestamp provides period of current timestamp even for different timestampsNext#59715 [SC-Low] periodattimestamp will return different period for the same timestamp input

Was this helpful?