Split (Kub) Exploit — Self-Doubling Balance via Manipulable On-Chain "Token Price" Oracle

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

Vulnerability classes: vuln/oracle/price-manipulation · vuln/oracle/spot-price · vuln/logic/state-update

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

Key info#

TL;DR#

Split is a "reflection"-style deflationary token. On every token transfer its _beforeTokenTransfer hook calls setSplit() (Split.sol:1231-1237). When an internal price reading getTokenPrice() exceeds 100 ether, setSplit() bumps a counter split and invokes two internal "rebase" routines that literally double numbers in storage:

• _total(split) doubles _totalSupply (Split.sol:731-741), and
• _balance(to, split) doubles each touched account's _balances[to] (Split.sol:742-752).

getTokenPrice() is computed live from the spot reserves of a pool the attacker controls (KUB.balanceOf(fistLP) and Split.balanceOf(fistLP), Split.sol:1238-1246). So the attacker first force-feeds that pool until the reading clears 100 ether, then triggers the hook repeatedly with zero-value, self-directed transfers. Each call doubles their Split balance held inside the AMM pairs. Pair balances are then harvested with skim(), the inflated Split is routed through a fresh attacker-owned fakeUSDC/Split pair and through the StakingRewards sell() path back into BUSDT and KUB, and finally five DODO/DPP flash loans (~1.87M BUSDT borrowed) are repaid. The attacker keeps the difference: 22,049.48 BUSDT + 126.38 KUB.

Background — what the contracts do#

Split (Split.sol:1125-1255) inherits a modified OpenZeppelin ERC20. Two non-standard pieces are bolted into the base ERC20:

1. A hidden "rebase" pair _total() / _balance() (Split.sol:731-752) that doubles supply and per-account balances sp - <last> times.
2. A balanceOf override (Split.sol:1212-1216) that returns a floor of _initialBalance (= 1) for any account whose real balance is zero. This "phantom dust" is what gives the doubling something to multiply.

The StakingRewards contract (StakingRewards.sol:414-862) is a yield/referral farm with a permissionless sell() (StakingRewards.sol:767-782) that buys back token (Split/KUB) for token1 (KUB/BUSDT) at a spot price and, if it is short on inventory, pulls it out of the LP via removeLiquidity(). This is the path the attacker uses to convert inflated Split into real value.

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

The vulnerable code#

1. Every transfer can trigger a balance "rebase"#

// Split._beforeTokenTransfer  (Split.sol:1164-1173)
function _beforeTokenTransfer(address from,address to,uint amount) internal override trading{
    if(LP != address(0) && from !=LP){
       setSplit();                 // ⚠️ called on (almost) every transfer
    }
    _balance(from,split);          // ⚠️ doubles from's balance `split-spr[from]` times
    _balance(to,split);            // ⚠️ doubles to's balance `split-spr[to]` times
    ...
}

2. setSplit() keys off a spot-reserve "price" and increments the rebase counter#

// Split.sol:1231-1246
function setSplit() public {
    if(getTokenPrice() > 100 ether){    // ⚠️ attacker-controllable threshold
        split++;                        // bump rebase counter
        _total(split);                  // double _totalSupply
        IFactory(LP).sync();
    }
}
function getTokenPrice() view private returns(uint){
    // price = (KUB held by fistLP × KUB/USDT price) / (Split held by fistLP)
    uint kubPrice = IRouter(KUBDEX).getAmountsOut(1 ether, [KUB, USDT])[1];
    uint kubUSDT  = IERC20(KUB).balanceOf(fistLP) * kubPrice / 1 ether;
    uint fistlpToken = kubUSDT * 1 ether / IERC20(address(this)).balanceOf(fistLP);
    return fistlpToken;                 // ⚠️ pure spot read of a pool the attacker fills
}

3. The doubling primitives#

// Split.sol:731-752  (added to the modified ERC20 base)
function _total(uint sp) internal {
    if(sp > spss){
        uint a = sp - spss;
        for(uint i=0;i<a;i++){ _totalSupply = _totalSupply*2; }   // ⚠️ supply ×2 per step
        spss = sp;
    }
}
function _balance(address to,uint sp) internal {
    if(sp > spr[to]){
        uint a = sp - spr[to];
        for(uint i=0;i<a;i++){ _balances[to] = _balances[to]*2; } // ⚠️ balance ×2 per step
        spr[to] = sp;
    }
}

4. The phantom-dust balanceOf override that makes the doubling productive#

// Split.sol:1212-1216
function balanceOf(address account) public view virtual override returns (uint) {
    uint balance = super.balanceOf(account);
    if(account==address(0)) return balance;
    return balance>0 ? balance : _initialBalance;   // ⚠️ zero-balance accounts read as 1 wei
}

The interaction is the whole bug: an account that has never held Split still reports 1 wei. The first time the rebase counter catches up with it, _balance doubles its real stored balance — and the per-account spr[to] is many steps behind split, so a single touch can multiply that seed by 2^(split - spr[to]), an astronomically large factor.

Root cause — why it was possible#

Split derives a security-relevant decision (whether to inflate everyone's balances) from getTokenPrice(), which is nothing more than an instantaneous read of AMM pool reserves the attacker can fill at will. There is no TWAP, no admin gate, no rate-limit, and the inflation is unbounded — _total/_balance multiply by 2 once per unit the lagging counter is behind.

Concretely, four design faults compose into a critical exploit:

1. Spot-price-driven control flow. setSplit() flips inflation on whenever getTokenPrice() > 100 ether. The price is (KUB reserve × KUB-price) / Split reserve of the fistLP pool. By cornering KUB into that pool and starving it of Split, the attacker drives the reading above the threshold deterministically.
2. Per-account doubling with a lagging counter. _balance(to, split) doubles _balances[to] split - spr[to] times. Because spr[to] starts at 0 while split has been advanced many steps, the first touch of an account multiplies its seed by a huge power of two.
3. Phantom-dust floor. balanceOf returns _initialBalance = 1 for zero-balance accounts, so even fresh addresses (and the pair contracts) carry a non-zero seed for the doubling to act on.
4. Permissionless harvest paths. Uniswap-V2 skim() lets anyone sweep a pair's surplus token balance to themselves; StakingRewards.sell() (StakingRewards.sol:767-782) permissionlessly buys back the inflated Split for KUB/BUSDT and even withdraws pool liquidity to fund the payout. Together they convert "doubled storage numbers" into real, withdrawable assets.

Preconditions#

• The attacker can move the fistLP (KUB/Split) reserves so that getTokenPrice() > 100 ether. In the live attack this is done by swapping BUSDT→KUB and dumping the KUB into the KUB/Split pair, then sync()ing (output.txt:235-251).
• The Split rebase counter split is allowed to advance freely via repeated transfers — there is no cooldown, so the attacker can fire dozens of transfer(self, 0) calls in one transaction (Kub_Split_exp.sol:122-126).
• Working capital in BUSDT to seed the swaps. The attack borrows it via five chained DODO/DPP flash loans (~1.87M BUSDT, fully repaid intra-tx), so the only real cost is gas — i.e. it is effectively capital-free.

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

All figures are taken directly from the output.txt trace.

Why "doubling a 1-wei seed" produces 3.165e31 Split#

The per-account routine _balances[to] = _balances[to]*2 runs split - spr[to] times. Because the pair/attacker accounts start with spr=0 (or far behind) while split has been advanced ~30+ times in step 5, the first touch multiplies the seed by 2^k for a large k. The trace shows the BUSDT/Split pair's reported Split balance leaping from ~27.55 (real LP) to 5.916e28 (1478) and then 1.775e29 (1675) across two rebase touches — exactly the geometric blow-up the doubling loops predict. skim() then realizes that phantom surplus as a transferable balance.

Profit / loss accounting (net of flash loans)#

All five flash loans (~1,874,170 BUSDT) are repaid in full (output.txt:16634-16704); the DODO DODOFlashLoan events at the tail confirm no shortfall. The realized profit — 22,049.48 BUSDT + 126.38 KUB (≈ $22.2K at the BUSDT≈$1, KUB price implied by the trace) — is value siphoned out of the KUB/Split, BUSDT/Split, and (via StakingRewards) BUSDT/KUB liquidity pools.

Diagrams#

Sequence of the attack#

The flaw inside setSplit() / _balance()#

Balance blow-up (BUSDT/Split pair's reported Split balance)#

Remediation#

1. Never gate state mutations on a spot AMM price. getTokenPrice() reads live pool reserves the attacker can fill. If a price signal is genuinely needed, use a manipulation-resistant TWAP/oracle, or an admin-set value — not an instantaneous getAmountsOut / balanceOf(pair) reading.
2. Remove the doubling rebase entirely. _total() and _balance() (Split.sol:731-752) multiply supply and balances by 2 with no cap and no invariant tying balances to a fixed total supply. Any legitimate rebase must preserve Σ balances == totalSupply and be bounded / permissioned.
3. Delete the phantom-dust balanceOf floor. Returning _initialBalance for zero-balance accounts (Split.sol:1212-1216) manufactures value out of nothing and is what gives the doubling something to multiply.
4. Don't run unbounded logic in the transfer hook. _beforeTokenTransfer calling a public, externally-influenced setSplit() on every transfer turns a no-op transfer(self, 0) into a state-mutating weapon. Hooks should be side-effect-free with respect to global supply.
5. Harden the StakingRewards sell() path. It permissionlessly buys back tokens at a spot price and withdraws pool liquidity to fund the payout (StakingRewards.sol:767-788). It should validate token solvency against a manipulation-resistant price and never pull LP reserves to satisfy a spot-priced redemption.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo does not whole-compile under a single forge build):

_shared/run_poc.sh 2023-09-Kub_Split_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 32,021,099). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block; most public BSC RPCs prune it and fail with header not found / missing trie node.
• Result: [PASS] testExploit().

Expected tail (from output.txt):

  Attacker BUSDT balance after attack: 22049.483174547645804689
  Attacker KUB balance after attack:   126.379336484940877783
  Attacker Split balance after attack: 31651945174745.793911796322504040
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 49.12s

References: CertiK Alert — https://twitter.com/CertiKAlert/status/1705966214319612092 (Split / Kub, BSC, ~$22K). SlowMist Hacked archive — https://hacked.slowmist.io/.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-09-Kub_Split_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Kub_Split_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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