NOVO Exploit — `transferFrom` Skips Allowance Check, Pool Reserve Drained

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2022-05-Novo_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/Novo_exp.sol.

Vulnerability classes: vuln/logic/missing-check · vuln/access-control/missing-auth

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source: sources/NOVO_a0787D/NOVO.sol (the NOVO token; the deployed 0x6Fb2020C… is a TransparentUpgradeableProxy whose logic is NOVO, called via delegatecall).

Key info#

TL;DR#

NOVO is a reflection/anti-whale BEP20 listed in a vanilla PancakeSwap NOVO/WBNB pair. Its transferFrom(sender, recipient, amount) overrides the inherited ERC20 but, in a fatal editing mistake, the block that was supposed to enforce the allowance[sender][msg.sender] was commented out (sources/NOVO_a0787D/NOVO.sol:2953-2960):

// _approve(
//     sender,
//     _msgSender(),
//     _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")
// );

As a result transferFrom becomes a free transfer(sender → recipient) for any caller — no allowance required, no allowance consumed. The _isRouter(_msgSender()) modifier on _transfer (:3524) is a no-op (it only sets an internal tier, never reverts), so it does not stop the abuse.

The attacker weaponises this in a single flash swap:

1. Flash-borrow 17.2 WBNB from the PancakeSwap NOVO/WBNB pair via pair.swap(0, 17.2e18, this, data) (output.txt:31).
2. Buy NOVO with the borrowed WBNB through the router — receives 4,749,070.146640911 NOVO (output.txt:9). The pool's NOVO reserve now reads 115,091,130.91 NOVO (output.txt:10).
3. Pull 113,951,614.762 NOVO straight out of the pair's balance with novo.transferFrom(address(novoLP), address(novo), 113_951_614_762_384_370) — no approval, because the check is gone (output.txt:110-118). The pair's NOVO balance collapses from 115,091,130 → 1,139,516.15 NOVO (output.txt:128).
4. Call novoLP.sync() — PancakeSwap accepts the crippled balance as its new reserve0, so the pair now believes NOVO is ~100× scarcer than reality while its WBNB reserve is unchanged (output.txt:129-136).
5. Sell the attacker's own 4,749,070 NOVO into the now-skewed pool. At the manipulated price this is enormously more WBNB than the 17.2 borrowed — the trace shows the attacker receiving 275.771339366198266632 WBNB before repaying (output.txt:365).
6. Repay the flash swap 17.2 WBNB + 0.25% fee = 17.6472 WBNB (output.txt:369-374) and keep the surplus.

Net WBNB balance: 10 (seed) + 258.124139… − 10 = +248.124139366198266632 WBNB profit (output.txt:389).

Background — what NOVO does#

NOVO (sources/NOVO_a0787D/NOVO.sol, contract decl at :2647) is a deflationary/reflection BEP20 (Initializable, OwnableUpgradeable) deployed behind a TransparentUpgradeableProxy. Beyond a standard ERC20 it adds:

• Reflection accounting — dual _rOwned / _tOwned ledgers and a fee that redistributes to holders (_transferStandard, :3701).
• Taxed transfers — buy/sell fees routed through the PancakeSwap pair/router.
• Anti-whale cap — antiWhaleEnabled limits per-transfer size (_transfer, :3530-3534).
• Staking lock — getLockedAmount(sender) blocks stakers from moving their locked NOVO (:2850-2852). It returned 0 for both the pair and the attacker here, so it was no obstacle (output.txt:64-67, output.txt:112-115).
• _isRouter(_msgSender()) modifier on _transfer (:3524) — sounds like an access gate but is actually a passive "tier bookkeeping" hook that never reverts (:2767-2786).

The on-chain state at the fork block (read directly from the trace):

NOVO uses 9 decimals (the PoC logs novo.balanceOf at decimals: 9, output.txt:64); WBNB uses 18 decimals.

The vulnerable code#

1. transferFrom does not enforce allowance (the root cause)#

function transferFrom(
    address sender,
    address recipient,
    uint256 amount
) public override returns (bool) {
    // locked the NOVO of staking holders
    uint256 lockedAmount = getLockedAmount(sender);
    if (lockedAmount > 0) {
        require(
            (balanceOf(sender) - amount) >= lockedAmount,
            "Your balance was locked"
        );
    }

    _transfer(sender, recipient, amount);

    // _approve(
    //     sender,
    //     _msgSender(),
    //     _allowances[sender][_msgSender()].sub(
    //         amount,
    //         "BEP20: transfer amount exceeds allowance"
    //     )
    // );

    if (recipient == address(uniswapV2Router)) {
        // airdrop the staking rewards
        uint256 rewards = _novoNFT.getReward(sender);
        if (rewards > 0) {
            _transfer(_stakingPoolAddress, sender, rewards);
        }
    }

    return true;
}

(sources/NOVO_a0787D/NOVO.sol:2937-2971)

The sender is moved straight into recipient with no check that msg.sender was ever approved by sender, and no allowance is ever decremented. For contrast, the sibling decreaseAllowance function still subtracts under the standard "decreased allowance below zero" guard (:2986-2999) — so the developer clearly knew the ERC20 pattern; they simply left it disabled in transferFrom.

2. _transfer's isRouter guard is a paper tiger#

function _transfer(
    address from,
    address to,
    uint256 amount
)
    private
    preventBlacklisted(_msgSender(), "NOVO: Address is blacklisted")
    preventBlacklisted(from, "NOVO: From address is blacklisted")
    preventBlacklisted(to, "NOVO: To address is blacklisted")
    isRouter(_msgSender())
{
    require(from != address(0), "BEP20: transfer from the zero address");
    require(to != address(0), "BEP20: transfer to the zero address");
    require(amount > 0, "Transfer amount must be greater than zero");
    ...
}

(sources/NOVO_a0787D/NOVO.sol:3515-3528)

modifier isRouter(address _sender) {
    {
        uint32 size;
        assembly {
            size := extcodesize(_sender)
        }
        if (size > 0) {
            uint256 senderTier = _accountsTier[_sender];
            if (senderTier == 0) {
                IUniswapV2Router02 _routerCheck = IUniswapV2Router02(_sender);
                try _routerCheck.factory() returns (address factory) {
                    _accountsTier[_sender] = 2;
                } catch {}
            }
        }
    }

    _;
}

(sources/NOVO_a0787D/NOVO.sol:2767-2786)

Despite the name, isRouter only records a tier when it thinks the caller looks like a router; it never reverts, so the attacker (an EOA-driven contract) sails through _transfer.

3. The attacker's one-line weaponisation#

// Manipulate the LP of NOVO/WBNB => Manipulate the NOVO/WBNB price
novo.transferFrom(address(novoLP), address(novo), 113_951_614_762_384_370); // 113,951,614.76238437 NOVO Token

(test/Novo_exp.sol:67-69)

from = novoLP (the PancakeSwap pair), to = address(novo) (the token contract itself, chosen simply to take the tokens out of circulation). No approval was ever set by the pair in favour of the attacker — none was needed.

Root cause — why it was possible#

A Uniswap-V2/PancakeSwap pair prices NOVO/WBNB purely from (reserve0, reserve1), and reserve0 is taken to be balanceOf(pair) at the last _update (after a swap, mint, burn, or sync). The pair's security model assumes token balances only change through code paths the pair initiated (its own _safeTransfer during swap, or LP mint/burn).

By commenting the allowance check out of transferFrom, NOVO turns that assumption into a one-way valve: any external caller can move NOVO out of the pair's balance, and a follow-up pair.sync() then forces the pair to accept the reduced balance as its new reserve. Because WBNB moves out of the pair only inside swap() under the K-invariant check, the attacker can:

1. Remove NOVO from the pair for free → reserve0 is now understated relative to actual value.
2. Call sync() → the pair believes NOVO is scarce.
3. Sell their own NOVO through the router → the pair's getAmountOut quotes a wildly inflated WBNB payout, the K-check passes (because the attacker really is depositing NOVO), and a huge WBNB amount flows to the attacker.

The flash-swap simply front-loads the working capital so no outside funding is needed — the borrowed 17.2 WBNB are repaid (with the 0.25% fee) from the proceeds inside the same transaction.

This is structurally the same class as the classic "token whose transfer/transferFrom is non-compliant inside an AMM" family — but here the non-compliance is extreme: not a fee-on-transfer quirk, but a total absence of the approval authorisation.

Preconditions#

• The attacker needs a way to call NOVO.transferFrom(pair, …). Because the allowance check is commented out and _isRouter never reverts, anyone can — no role, no approval, no setup. Verified in the trace: the call originates from ContractTest (the attacker contract, 0x7FA9385b…) with no prior approve from the pair (output.txt:110-123).
• getLockedAmount(pair) == 0, so the staking-lock guard in transferFrom does not block the pair's balance. Confirmed: the getLockedAmountByAddress(novoLP) call returns 0 (output.txt:112-115).
• Neither the pair nor the attacker is on the blacklist (the preventBlacklisted modifier does not trip — no revert anywhere in the trace).
• A flash-swap source for the initial WBNB. The PoC uses the same NOVO/WBNB PancakeSwap pair (PancakePair.swap(0, 17.2e18, this, data), test/Novo_exp.sol:38), repaid in the pancakeCall callback. No external capital beyond the 10 WBNB msg.value seed is required.

Attack walkthrough (with on-chain numbers from the trace)#

token0 = NOVO (9 decimals), token1 = WBNB (18 decimals), so reserve0 = NOVO, reserve1 = WBNB. All figures are taken directly from the Sync / Swap / Transfer events and getReserves returns in output.txt. Raw wei are shown with a human approximation in parentheses (NOVO ÷ 1e9, WBNB ÷ 1e18).

Why the sell at step 5 mints so much WBNB: after sync(), reserve0 ≈ 1.14 M NOVO and reserve1 ≈ 412 WBNB. PancakeSwap's getAmountOut(amountIn, reserveIn, reserveOut) with the 0.25 % fee (amountIn·9975) pays roughly (amountIn·9975 · reserveOut) / (reserveIn·10000 + amountIn·9975). Pushing ~4.5 M NOVO into a pool whose priced-in NOVO reserve is only ~1.14 M (plus the small amounts the router re-injects during its own internal swapAndLiquify/re-liquidity steps) yields a WBNB payout that dwarfs the 17.2 WBNB borrowed.

Profit / loss accounting (WBNB)#

The profit is denominated purely in WBNB; the USD equivalent is not recorded in the trace and is omitted here (WBNB's BSC price on the attack day is out of scope of the on-chain evidence).

Diagrams#

Sequence of the attack#

Pool state evolution#

The flaw inside transferFrom#

Why the drain is theft: constant-product before vs. after sync()#

Why each magic number#

• 10 * 1e18 WBNB seed (test/Novo_exp.sol:33): the attacker's only external capital. It is never spent — it just sits as WBNB while the flash-swap funds the buy. Equivalently the attack is ~capital-free; the 10 WBNB could be 0 if the buy were also sourced from the flash loan.
• 172 * 1e17 (= 17.2 WBNB) flash-swap amount (test/Novo_exp.sol:37-38): the WBNB used to purchase the attacker's NOVO bag. It is repaid as 17.2 WBNB + 0.25 % fee.
• 113_951_614_762_384_370 wei (= 113,951,614.76238437 NOVO) transferFrom amount (test/Novo_exp.sol:69): chosen to be just under the pair's NOVO balance (115,091,130.91 NOVO at that moment, output.txt:10) so the call does not revert on the safe-transfer inside NOVO's _transfer. It strips ~98.99 % of the pair's NOVO, leaving 1,139,516.15 NOVO — small enough that the subsequent sell dominates reserve0.
• 4472 * 10e13 (= 44,720,000,000,000,000 wei = 0.04472 WBNB) flash-swap fee (test/Novo_exp.sol:86): exactly 17.2 WBNB × 0.25 % = 0.043 WBNB rounded up to 0.04472 WBNB. Combined with the principal it gives the 17.6472 WBNB repay seen at output.txt:369.
• swap(0, amount1Out, …) and amount0Out/amount1Out = 0 patterns: token0 = NOVO, token1 = WBNB, so "borrow WBNB" is swap(0, 17.2e18, …) and "sell NOVO for WBNB" produces a swap(0, wbnbOut, …) from the pair's perspective.

Remediation#

1. Restore the allowance check in transferFrom. Uncomment the _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")) block (sources/NOVO_a0787D/NOVO.sol:2953-2960). This is the single fix that eliminates the bug. Use OpenZeppelin's _spendAllowance for the canonical behaviour (revert on insufficient, support infinite allowance, decrement).
2. Make isRouter actually gate. If the intent was to restrict _transfer to a known router, the modifier must require rather than silently tier-record. As written (:2767-2786) it is decorative.
3. Don't store AMM pricing authority in a token that has arbitrary transferFrom. Even with the allowance restored, listing reflection/tax tokens in a vanilla Uniswap-V2 pair is fragile; prefer an oracle-priced or fee-aware pair, and never let a non-pair code path move tokens out of the pair's balance.
4. Add a re-entrancy/style invariant test for transferFrom. A property test asserting "transferFrom reverts when allowance[from][msg.sender] < amount" would have caught this instantly.
5. Re-audit after disabling code. The commented block is a classic "disabled during testing, never re-enabled" defect; a CI gate that fails on // _approve inside transferFrom (or any commented-out security check) would prevent recurrence.

How to reproduce#

The PoC is run offline through the shared harness; the fork is served from the local anvil_state.json (the createSelectFork("http://127.0.0.1:8546", 18_225_002) call in test/Novo_exp.sol:29 points at a local Anvil port, not a public RPC).

_shared/run_poc.sh 2022-05-Novo_exp --mt testExploit -vvvvv

• EVM: foundry.toml sets evm_version = "cancun".
• Test function: testExploit in test/Novo_exp.sol (the ContractTest contract).
• Fork block: 18,225,002 on BSC.
• Expected tail (from output.txt:392-394):

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 27.78s (26.68s CPU time)

Ran 1 test suite in 32.74s (27.78s CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

with the attacker-balance log lines:

[Start] Attacker WBNB balance before exploit: 10.000000000000000000
[*] Attacker flashswap Borrow WBNB: 17.200000000000000000
[End] After repay, WBNB balance of attacker: 258.124139366198266632

Reference: Panews exploit alert — https://www.panewslab.com/zh_hk/articledetails/f40t9xb4.html (NOVO, BSC, May 2022).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-05-Novo_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Novo_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "NOVO Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.