Notional Update #5 — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Notional Update #5, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 16
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 16 closed, publicly disclosed Notional Update #5 reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Oracle manipulation, Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Oracle manipulation findings disclosed against Notional Update #5
- Logic error findings disclosed against Notional Update #5
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Notional Update #5: The use of spot data when discounting is subjected to manipulation
Notional's wfCash redemption path calls a view function that prices the cash owed to the user off live spot market data (utilization and the resulting two-kink interest rate). Because the rate curve is steep just below Kink 1, an attacker who deposits enough prime cash to depress utilization in that window can make the discounting rate fall sharply and receive materially more cash than a non-manipulated redemption would yield. The contest judges upheld the finding at medium severity, reasoning that an attacker cannot directly profit from the manipulation and would lose money, so the harm is borne by regular users; the protocol's fix added a slippage check against the user-submitted maxImpliedRate rather than removing spot-data dependence, and it was signed off by the Lead Senior Watson.
Notional Update #5: Malicious users could block liquidation or perform DOS
Notional's SecondaryRewarder uses a push model: whenever reward balances update, the accumulated incentive token is transferred out inside the same transaction via safeTransferOut. Because the reward token can be any ERC20 (e.g., ARB today, arbitrary tokens later), a token whose transfer can revert on demand — via blacklist, transfer hooks, or a coded revert — gives the account holder a lever over the surrounding call. The reward path feeds BalancerHandler._finalize, which underlies deposits, withdrawals, and liquidations. A user who expects to be liquidated can deliberately force that transfer to revert, causing the entire liquidation transaction to fail and leaving bad debt on the protocol; if repeated across accounts this could accumulate toward insolvency. The protocol fixed it by wrapping the reward distribution in a try/catch so only the blacklisted account loses its pending rewards, rather than reverting the caller's transaction.
Notional Update #5: recover() using the standard transfer may not be able to retrieve some tokens
Notional's SecondaryRewarder exposes an onlyOwner-guarded recover() used to sweep tokens sent to the contract or leftover reward tokens back to the owner. For non-ETH tokens the function invokes the standard IERC20.transfer(), which reverts for tokens such as USDT that do not return a boolean on success — behavior the contest README explicitly flagged as expected. Consequently every recovery attempt for such a token fails and the tokens remain permanently trapped, with no alternative withdrawal path in the code. After a contested escalation the finding was upheld as Medium severity, and Notional fixed it by routing recoveries through GenericToken.safeTransferOut.
Notional Update #5: getTargetExternalLendingAmount() when targetUtilization == 0 no check whether enough externalUnderlyingAvailableForWithdraw
Notional Update #5's external lending rebalancing contains a logic error in getTargetExternalLendingAmount(): when targetUtilization is set to zero, the function short-circuits and returns a target amount of 0, bypassing the normal check that caps the redemption target against externalUnderlyingAvailableForWithdraw. When governance zeroes the rebalancing targets to exit Aave quickly, the downstream withdraw attempts to redeem more than is currently available and reverts, so setRebalancingTargets() fails and the protocol cannot pull funds from the lending pool. The impact is denial of the emergency exit path rather than theft of user funds. The issue was judged a valid medium (duplicate of 052) and fixed by removing the short-circuit so the normal withdrawal-cap logic applies.
Notional Update #5: getTargetExternalLendingAmount() targetAmount may far less than the correct value
Notional's external-lending rebalancer computes a target external lending amount by capping the desired position against oracleData.maxExternalDeposit, but that cap already includes the protocol's current external deposit. When the desired target is at or below the current position, the cap incorrectly drives the returned target toward zero, causing the rebalancer to withdraw external liquidity that should remain deployed. The finding was upheld as a valid medium by the Sherlock judge, fixed via a Notional PR, and signed off by the Lead Senior Watson.
Notional Update #5: Unexpected behavior when calling certain ERC4626 functions
Notional's wrapped-fCash contract implements an ERC4626 interface whose valuation depends on the global settlement state of matured fCash positions. Because settlement is only triggered when the first account settles, there is a window after maturity where `pr.supplyFactor` is still zero. In that window `_getMaturedCashValue` returns zero, so `totalAssets()` collapses to zero, which propagates to `convertToAssets`, `previewRedeem`, `maxWithdraw`, `convertToShares` and `previewWithdraw`, causing either misleading zero valuations or reverts for any integrator. The finding was upheld as Medium; the maintainers fixed it so the affected functions revert while the settlement rate is unset rather than returning zero.
All reports in this group
- Notional Update #5: Low precision is used when checking spot price deviationLogic error$0
- Notional Update #5: getOracleData() maxExternalDeposit not accurateLogic error$0
- Notional Update #5: Lender transactions can be front-run, leading to lost fundsLogic error$0
- Notional Update #5: Residual ETH not sent back when `batchBalanceAndTradeAction` executedLogic error$0
- Notional Update #5: `ExternalLending`Logic error$0
- Notional Update #5: Rebalance will be delayed due to revertLogic error$0
- Notional Update #5: _isExternalLendingUnhealthy() using stale factorsLogic error$0
- Notional Update #5: `wfCashERC4626`Logic error$0
- Notional Update #5: Residual ETH will not be sent back to users during the minting of wfCashLogic error$0
- Notional Update #5: Rebalance might be skipped even if the external lending is unhealthyLogic error$0