CVE-2026-40093 nimiq-blockchain is missing a wall-clock upper bound on block timestamps

nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. In 1.3.0 and earlier, block timestamp validation enforces that timestamp = parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MINPRODUCERTIMEOUT for skip blocks, but there is no visible upper...

Allocation of Resources Without Limits or Throttling

Overview Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the EndBlocker process. An attacker can cause the system to halt by triggering an integer overflow during the cumulative reward ratio calculation. Remediation Upgrade...

buggy reward calculation

Lines of code Vulnerability details Impact This is very similar to an inflation attack. Rewards increase whenever splitFees is being called which is anywhere buy/sell/mint/burn. The calculation is done like this: shareDataid.shareHolderRewardsPerTokenScaled += shareHolderFee 1e18 / tokenCount;...

The user has the ability to bypass a fee claim protection for their own benefit while purchasing tokens

Lines of code Vulnerability details Impact User can bypass a fee claim protection for his own benefit by making multiple purchases instead of one, and as the result claim a fee part by part. Due to code documentation: The reward calculation has to use the old rewards value pre fee-split to not...

There is potential underflow and overflow issues in arithmetic operations in the _getRewardsSinceLastClaim function

Lines of code Vulnerability details Impact There are potential underflow and overflow issues in arithmetic operations. Not being able to verify that subtracting lastClaimedValue from shareDataid.shareHolderRewardsPerTokenScaled would result in a negative value. This could lead to affecting the...

M-04 Unmitigated

Lines of code Vulnerability details Impact The previously identified vulnerability of potential rounding issues during reward calculations has not been fully mitigated. The current strategy to keep remainders and use them in subsequent claimAndSyncRewards calls does not adequately address the iss...

Calculating the previous pool's 'cumulativeRewardFactor' from the current pool incorrectly calculates the reward.

Lines of code Vulnerability details Impact When we updated a transcoder with rewards and then try to update a transcoder with fees, it incorrectly calculates the reward generated in the current round for that transcoder, which also incorrectly calculates the previous pool's cumulativeRewardFactor...

preBorrowHook and preRepayHook can call updateRewardTokenBorrowIndex with old borrowIndex

Lines of code Vulnerability details Impact Under normal circumstances, the user calls VToken.borrow, further calls accrueInterest to update borrowIndex, and then calls preBorrowHook to trigger updateRewardTokenBorrowIndex. But since preBorrowHook is an externl function, an attacker can directly...

An expired parameter is required because there may be slippage in the calculation.

Lines of code Vulnerability details Impact Due to changes in interest rates, failure to process transactions in a timely manner may result in missing out on ideal rewards. Proof of Concept The calculation of the clainRewards function involves interest rates, which are variable. If...

Huge over calculating user rewards

Lines of code Vulnerability details Impact Huge over calculating user rewards When user claim rewards for the first time rewards over calculated Proof of Concept getPoolReward function uses ''uint256 timeSinceReward = block.timestamp - lastRewardTime'' formula to calculate period of time that...

Flawed calculation in getPoolReward leads to permanent loss of rewards

Lines of code Vulnerability details In NeoTokyoStaker.getPoolReward, a users reward is calculated as follows: 1388: uint256 share = points PRECISION / pool.totalPoints totalReward; 1390: share /= PRECISION; points represents the users total points in the pool over a specific potentially long time...

User can claim high rewards than he eligible

Lines of code Vulnerability details Impact User will receive rewards more than he should receive calculation of rewards for user can be continued even after withdraw Proof of Concept when a user claim rewards, the lastRewardTime will be set to block.timestamp , now consider a scenario that user...

Wrong accounting of share leading to incorrect amount of BYTES be minted per second

Lines of code Vulnerability details Impact In NeoTokyoStaker, staker is a competitive system where stakers compete for a fixed emission rate in each of the S1 Citizen, S2 Citizen, and LP token staking pools. For each staking pool, there are some reward windows. Each reward window has different...

Rewards for the Staking.sol contract may be stolen via the first staker

Lines of code Vulnerability details Impact The return amount of the function rewardPerToken may be inflated for the first in the Staking.sol contract. Proof of Concept The Staking.sol contract is designed for the LOT token holders to be able to stake their native tokens. Thus, the token holders...

fee loss in AutoPxGmx and AutoPxGlp and reward loss in AutoPxGlp by calling PirexRewards.claim(pxGmx/pxGpl, AutoPx*) directly which transfers rewards to AutoPx* pool without compound logic get executed and fee calculation logic and pxGmx wouldn't be executed for those rewards

Lines of code Vulnerability details Impact Function compound in AutoPxGmx and AutoPxGlp contracts is for compounding pxGLP and additionally pxGMX rewards. it works by calling PirexGmx.claimpx, this to collect the rewards of the vault and then swap the received amount to calculate the reward,...

_writeCheckpoint() in Gauge use wrong index to get prevVoteStatus

Lines of code Vulnerability details Impact All the Voting values calculated by writeCheckpoint when it's not first checkpoint is going to set to False instead of account's last vote and because vote has been used in earned and reward calculation so reward distribution is going to be wrong too...

AuraLocker kick reward only takes last locked amount into consideration, instead of whole balance

Lines of code Vulnerability details The issue occurs in AuraLocker, when expired locks are processed via kicking, and if all the user locks have expired. In this scenario, to calculate the kick reward, processExpiredLocks multiplies the last locked amount by the number of epochs between the last...

ConvexMasterChef: When _lpToken is duplicated, reward calculation is incorrect

Lines of code Vulnerability details Impact Same as IDX-002 in In the ConvexMasterChef contract, a new staking pool can be added using the add function. The staking token for the new pool is defined using the lpToken variable. However, there is no additional checking whether the lpToken is already...

Reward and base token decimals difference isn't accounted for in LiquidityFarming

Lines of code Vulnerability details Impact Reward and base token decimals can differ, while this difference isn't accounted for in the reward amount calculations, which will lead to either missing rewards or sending the whole rewards balance to the first eligible user. For example: If reward is...

ConvexStakingWrapper does not update rewards state before transferring tokens

Handle kenzo Vulnerability details ConvexStakingWrapper saves data for reward calculation in dedicated variables for each user, such as reward.rewardintegralforaccount. These variables are not updated when transferring wrapped staked tokens. Please note that Convex's original ConvexStakingWrapper...