Aurum Finance (AUR) Exploit — Unprotected `changeRewardPerNode()` Drains the Node-Reward Pool

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-11-AUR_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/AUR_exp.sol.

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

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains several unrelated PoCs that do not compile under a whole-project build, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: AurumNodePool.sol.

Key info#

TL;DR#

AurumNodePool is a "node-as-a-yield" contract: users pay AUR to create "nodes," and each node accrues AUR rewards over time at a rate of rewardPerDay. The reward owed to a node is computed as

reward = rewardPerDay * (now - lastClaimTime) / 86400

The single fatal mistake is that the setter that controls rewardPerDay — changeRewardPerNode() — has no onlyOwner modifier (and neither does changeNodePrice()). Anyone can set the reward-per-day to any uint256.

The attacker:

1. Buys a tiny amount of AUR (0.01 BNB worth) so the transferFrom in createNode succeeds, then calls changeNodePrice(1000 AUR) and createNode(1) to register a node owned by the attacker.
2. Lets a few seconds of block time pass, then calls changeRewardPerNode(4.34e29) — a value chosen so that, for the elapsed seconds, the computed reward equals the entire AUR balance held by the pool.
3. Calls claimNodeReward(...), which does AURUM.transfer(attacker, reward) and ships every AUR token out of the pool to the attacker.
4. Dumps the stolen AUR into the AUR/WBNB PancakeSwap pair, walking away with 49.85 BNB.

There is no flash loan, no oracle manipulation, no math trick — just a public function that should have been onlyOwner.

Background — what AurumNodePool does#

AurumNodePool (source) is a small staking/yield contract paired with the AUR reflection token. Its model:

• Create a node (createNode): the caller pays nodePrice AUR per node (pulled via transferFrom), a teamFee slice is forwarded to teamWallet, and a NodeEntity{nodeId, creationTime, lastClaimTime} is pushed into the caller's node list. creationTime/lastClaimTime are set to block.timestamp.
• Accrue & claim rewards (getNodeReward, claimNodeReward): reward is linear in elapsed time, rewardPerDay * (now - lastClaimTime) / 86400, paid out of the pool's own AUR balance via AURUM.transfer.
• Owner-only admin (setTeamWallet, setTeamFees, setMaxNodes) — these three setters are correctly guarded with onlyOwner.

The two economic parameters that directly drive the reward formula — changeNodePrice and changeRewardPerNode — were left unprotected. The contract author clearly knew how onlyOwner works (it guards the other three setters) but forgot to apply it to the two most security-critical ones.

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

The vulnerable code#

1. The reward formula is unbounded in rewardPerDay#

// AurumNodePool.sol:500-502
function getNodeReward(NodeEntity memory node) internal view returns (uint256) {
    return rewardPerDay * (block.timestamp - node.lastClaimTime) / 86400;
}

reward scales linearly and without cap in rewardPerDay. If rewardPerDay can be set to an arbitrary attacker value, the reward for even a single node after a few seconds can be made to equal any number — including the pool's full balance.

2. The setter that controls rewardPerDay has NO access control#

// AurumNodePool.sol:570-576
function changeNodePrice(uint256 newNodePrice) external {   // ⚠️ no onlyOwner
    nodePrice = newNodePrice;
}

function changeRewardPerNode(uint256 _rewardPerDay) external {   // ⚠️ no onlyOwner — THE BUG
    rewardPerDay = _rewardPerDay;
}

Compare with the correctly guarded admin setters in the same contract:

// AurumNodePool.sol:586-596
function setTeamWallet(address _wallet) external onlyOwner { teamWallet = _wallet; }   // ✓ guarded
function setTeamFees(uint256 _teamFee) external onlyOwner { teamFee = _teamFee; }       // ✓ guarded
function setMaxNodes(uint256 _count) external onlyOwner { maxNodes = _count; }          // ✓ guarded

3. The claim pays straight out of the pool's balance#

// AurumNodePool.sol:504-517
function claimNodeReward(uint256 _creationTime) external {
    address account = msg.sender;
    require(_creationTime > 0, "NODE: CREATIME must be higher than zero");
    NodeEntity[] storage nodes = _nodesOfUser[account];
    uint256 numberOfNodes = nodes.length;
    require(numberOfNodes > 0, "CLAIM ERROR: You don't have nodes to claim");
    NodeEntity storage node = _getNodeWithCreatime(nodes, _creationTime);
    uint256 rewardNode = getNodeReward(node);
    node.lastClaimTime = block.timestamp;
    AURUM.transfer(account, rewardNode);    // ⚠️ ships rewardNode AUR out of the pool, no solvency check
}

There is no check that rewardNode <= AURUM.balanceOf(address(this)) beyond what the ERC20 transfer itself enforces, and crucially no bound that ties rewards to actual deposits. Whatever getNodeReward returns is paid out.

Root cause — why it was possible#

This is a textbook broken access control finding. The vulnerability is the composition of three facts, the first being decisive:

1. changeRewardPerNode() is external with no onlyOwner (or any) guard. An attacker controls the single most sensitive economic input of the contract.
2. The reward is rewardPerDay × elapsed / 86400, unbounded above. Because rewardPerDay is now attacker-controlled and there is no cap, the attacker can target any payout — in particular, exactly the pool's full AUR balance.
3. claimNodeReward transfers that computed amount directly from the pool with no reward-vs-stake invariant. Rewards are not bounded by what the user deposited, so a single freshly created node (deposit ≈ nodePrice) can legally "earn" the entire treasury in seconds.

The attacker only needs to own one node to have a claim handle. Creating that node requires paying nodePrice, which the attacker first lowers via the also-unprotected changeNodePrice() to a trivial amount and funds with a 0.01-BNB AUR buy. After that, setting rewardPerNode and claiming is the whole attack.

Preconditions#

• The node pool holds a non-trivial AUR balance to drain (it was the protocol's reward treasury). In the PoC this balance is provisioned with deal/setBalance so the chosen reward is satisfiable; on the live chain the attacker simply drained whatever AUR the pool actually held.
• The attacker owns at least one node (so claimNodeReward passes the numberOfNodes > 0 and node-search checks). Achieved with createNode(1) after a tiny AUR buy.
• At least a few seconds of block time between node creation and the claim, so (now - lastClaimTime) > 0. In the PoC this is forced with cheats.roll/cheats.warp (AUR_exp.sol:65-66).
• An AMM pair (AUR/WBNB) to convert the stolen AUR into BNB. The AUR token is fee-on-transfer, so the sell routes through swapExactTokensForETHSupportingFeeOnTransferTokens.

No capital beyond gas + a 0.01-BNB seed buy is required; the attack is self-funding.

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

All figures are taken directly from output.txt. The AUR token is token0, WBNB is token1 in the AUR/WBNB pair, so reserve0 = AUR, reserve1 = WBNB.

Reward-formula check (matches the trace to the wei): rewardPerDay × elapsed / 86400 = 434159898144856792986061626032 × 111 / 86400 = 557,774,869,144,434,074,322,370,838 — exactly the value transferred out in step 7.

Profit accounting (BNB)#

The profit equals the BNB value the attacker extracted by selling the entire pool's AUR into the AUR/WBNB pair (≈ 49.83 WBNB from the sale, plus minor dust), i.e. the protocol's reward treasury converted to BNB. The intermediate WBNB↔BNB unwraps (withdraw) in the trace are just the router returning native BNB to the attacker.

Diagrams#

Sequence of the attack#

State / control flow of the drain#

Access-control map (what was guarded vs. what was not)#

Why each magic number#

• changeNodePrice(1000 AUR) — lowers the per-node cost so createNode(1) only pulls 1,000 AUR, comfortably covered by the 0.01-BNB seed buy (27,122 AUR). Without this the attacker would need the current, larger nodePrice in AUR.
• changeRewardPerNode(434159898144856792986061626032) — reverse-engineered from the target payout: rewardPerDay = targetReward × 86400 / elapsed. With elapsed = 111 s and a target equal to the pool's AUR balance, this resolves to ≈ 4.3416e29. The PoC verifies the resulting reward (557,774,869 AUR) before claiming.
• 111 seconds elapsed — any positive elapsed time works; 111 s is just the gap produced by the roll/warp in the PoC. The attacker picks rewardPerDay to match whatever elapsed time they have.

Remediation#

1. Add onlyOwner to the parameter setters. The one-line fix that prevents the entire incident:
   SOLIDITYCopy

   function changeNodePrice(uint256 newNodePrice) external onlyOwner { ... }
   function changeRewardPerNode(uint256 _rewardPerDay) external onlyOwner { ... }
   

   These two setters are functionally identical in risk to setTeamFees/setMaxNodes, which already carry the modifier — the omission was the whole bug.
2. Bound rewards by actual stake / solvency. Even with a trusted owner, an unbounded rewardPerDay × elapsed is fragile. Cap the per-claim payout (e.g., to a function of the node's paid nodePrice and a maximum APR), and never let a claim exceed the pool's funded reward budget.
3. Sanity-check parameter ranges in setters. Reject absurd rewardPerDay values (e.g., enforce an upper bound or a timelocked change) so a single transaction cannot reprice the entire reward schedule.
4. Use a vetted access-control pattern. Prefer OpenZeppelin Ownable/AccessControl and a two-step/timelocked admin for economic parameters, with events on every change for off-chain monitoring.
5. Decouple reward accounting from raw balance. Track an explicit "rewards owed" accumulator funded by deposits/fees, and pay from that rather than from the pool's whole token balance, so a mispriced reward cannot reach principal/liquidity.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has several unrelated PoCs that fail a whole-project forge build):

_shared/run_poc.sh 2022-11-AUR_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required to fork block 23,282,134 (Nov 2022 state). Most public BSC RPCs prune state this old and fail with header not found / missing trie node.
• Result: [PASS] testExploit(). Attacker BNB goes from 0.01 to 49.856 → ~49.85 BNB profit.

Expected tail:

  [Start] Attacker BNB balance before exploit: 0.010000000000000000
  AurumNodePool Attacker reward:: 557774869144434074322370838
  [End] Attacker BNB balance after exploit: 49.856295163763834046

Suite result: ok. 1 passed; 0 failed; 0 skipped

References: AnciliaInc — https://twitter.com/AnciliaInc/status/1595142246570958848 ; BlockSec Phalcon traces for tx 0xb3bc6ca2…68e25d and 0x7f031e85…e279782 ; SlowMist Hacked (Aurum Finance, BSC, Nov 2022).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-11-AUR_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: AUR_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Aurum Finance (AUR) 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.