SushiMaker — Bridgeless `convert()` Lets an Attacker Insert a Fake Pair and Steal Onsen Fee Liquidity (Badger DIGG)

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

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

Reproduction status: the PoC in this folder does not pass — it reverts with BentoBox: Transfer failed. This is a harness bug, not a defense: the PoC's local ISushiMaker interface mis-declares convert(...) as a view function (test/Sushi_Badger_Digg_exp.sol:179), so Foundry issues it as a [staticcall]; the real convert() mutates state (pair.transfer) and the EVM rejects the state change inside a static context. The original DeFiHackLabs author even flagged this at the top of the file: "PoC is incomplete… Hardhat and JS gave me a severe headache." The attack itself is the real, on-chain January 2021 SushiMaker exploit. The trace below documents exactly how far execution got and why it stopped. Full verbose trace: output.txt. Verified vulnerable source: contracts_SushiMaker.sol.

Key info#

TL;DR#

SushiMaker.convert(token0, token1) (:85) takes the LP tokens the SushiMaker has accrued as protocol fees for a given pair, burns them to get the two underlying tokens, and then routes those tokens back through SushiSwap pairs to end up as SUSHI for xSUSHI stakers. To route a non-WETH token it needs a "bridge": a token it can swap through. When no bridge is configured, bridgeFor() (:52-57) silently defaults the bridge to WETH and _swap() then trades on whatever pair factory.getPair(from, bridge) returns (:170-191) with zero slippage protection (amountOutMin = 0, see the // TODO: Add maximum slippage? left in the code).

When SushiSwap's "Onsen" program added non-ETH pairs (including WBTC/DIGG) but no bridge was set for DIGG/WBTC, an attacker could:

1. Create their own pair for DIGG↔WETH (a factory.createPair) and seed it with a tiny, attacker-chosen amount of liquidity — the SushiMaker will happily use it because bridgeFor(DIGG) returns WETH and getPair(DIGG, WETH) now points at the attacker's pair.
2. Call convert(WBTC, DIGG) as an EOA (the onlyEOA modifier is the only gate, and it does not stop a fresh EOA). The SushiMaker burns its WBTC/DIGG fee LP, then dumps the DIGG side into the attacker's thin, manipulable pair at a price the attacker dictates — with no minimum out. The "converted" value lands in the attacker's pool.
3. Pull the liquidity back out of the attacker's pair (removeLiquidity), recovering the protocol's WBTC/DIGG value as WETH.

The bug is the combination of (a) a silent WETH default for missing bridges, (b) the swap venue being any getPair the attacker can populate, and (c) no slippage / min-out check.

Background — what the SushiMaker does#

The SushiMaker is "MasterChef's left hand": it is the recipient of the 0.05% LP protocol fee on every SushiSwap pair (it is the factory's feeTo, confirmed in the trace where UniswapV2Factory::feeTo() returns SushiMaker: 0xE11fc0…df50, output.txt:1659-1660). Periodically anyone can call convert/convertMultiple to turn those accumulated LP positions into SUSHI for xSUSHI stakers.

_convert (:102-116) does:

1. pair = factory.getPair(token0, token1) — find the fee-LP pair.
2. Transfer the SushiMaker's LP balance to the pair and pair.burn(this) — redeem the two underlying tokens.
3. Hand off to _convertStep, which walks a small decision tree to collapse (token0, token1) down to SUSHI, swapping through "bridge" pairs as needed.

The contract's own comments brag about its safety review (// C1 - C24: OK, // X1 - X5: OK), and even acknowledge one known exploit (// F6: There is an exploit to add lots of SUSHI to the bar…) which onlyEOA is meant to block. The bridge-defaulting hole is not among the cases those comments cover.

On-chain state at the fork block (read from the trace)#

That LP balance — 528,628,937 LP tokens of the WBTC/DIGG pool — is the prize. It represents the SUSHI fees that had accrued for the WBTC/DIGG Onsen pair and were sitting un-converted in the SushiMaker because nobody had set up a bridge to convert them safely.

The vulnerable code#

1. bridgeFor() silently defaults a missing bridge to WETH#

function bridgeFor(address token) public view returns (address bridge) {
    bridge = _bridges[token];
    if (bridge == address(0)) {
        bridge = weth;              // ← missing bridge ⇒ silently use WETH
    }
}

contracts_SushiMaker.sol:52-57

For DIGG, no bridge was configured, so bridgeFor(DIGG) == WETH. There is no "unset bridge ⇒ revert" path: an unconfigured token is treated identically to one explicitly bridged through WETH.

2. _convertStep picks the swap path from the (forgeable) bridge#

In the else { // eg. MIC - USDT } branch (:145-164), when neither token is SUSHI or WETH, the SushiMaker resolves bridge0 = bridgeFor(token0) and bridge1 = bridgeFor(token1) and swaps each token toward its bridge. For convert(WBTC, DIGG) this drives DIGG → bridgeFor(DIGG) = WETH via _swap.

3. _swap uses any getPair, with no min-out — and a precedence bug in the math#

function _swap(address fromToken, address toToken, uint256 amountIn, address to) internal returns (uint256 amountOut) {
    IUniswapV2Pair pair = IUniswapV2Pair(factory.getPair(fromToken, toToken));
    require(address(pair) != address(0), "SushiMaker: Cannot convert");

    (uint256 reserve0, uint256 reserve1,) = pair.getReserves();
    uint256 amountInWithFee = amountIn.mul(997);
    if (fromToken == pair.token0()) {
        amountOut = amountIn.mul(997).mul(reserve1) / reserve0.mul(1000).add(amountInWithFee);
        IERC20(fromToken).safeTransfer(address(pair), amountIn);
        pair.swap(0, amountOut, to, new bytes(0));
        // TODO: Add maximum slippage?        ← no slippage / min-out protection
    } else {
        amountOut = amountIn.mul(997).mul(reserve0) / reserve1.mul(1000).add(amountInWithFee);
        IERC20(fromToken).safeTransfer(address(pair), amountIn);
        pair.swap(amountOut, 0, to, new bytes(0));
        // TODO: Add maximum slippage?
    }
}

contracts_SushiMaker.sol:170-191

Two problems live here:

• The swap executes against factory.getPair(fromToken, WETH) — i.e. whatever pair address the public factory returns for (DIGG, WETH). The attacker freely creates that pair (createPair(DIGG, WETH)) and decides its reserves, so the SushiMaker is trading into a venue the attacker fully controls.
• No amountOutMin. The getReserves() snapshot is read from the attacker's pair and the swap is sent with zero protection, so the price is whatever the attacker pre-arranged. (The precedence in the amountOut formula — … / reserve0.mul(1000).add(amountInWithFee) resolves to [(amountIn·997·reserve1)/(reserve0·1000)] + amountInWithFee rather than the intended /(reserve0·1000 + amountInWithFee) — is a separate latent rounding/accounting defect, but the exploit does not need it: controlling the pool is sufficient.)

4. The only access gate is onlyEOA, which does not help here#

modifier onlyEOA() {
    // Try to make flash-loan exploit harder to do.
    require(msg.sender == tx.origin, "SushiMaker: must use EOA");
    _;
}

function convert(address token0, address token1) external onlyEOA() {
    _convert(token0, token1);
}

contracts_SushiMaker.sol:73-87

onlyEOA was added to defend the known "stuff the SushiBar with SUSHI then convert" trick (the // F6 comment). It only requires that the caller be an externally-owned account — a plain attacker EOA satisfies it. It provides no protection against the bridge-injection attack.

Root cause — why it was possible#

The SushiMaker conflates two very different situations:

"This token has no bridge configured" is treated exactly like "swap this token through WETH on the public pair getPair(token, WETH)" — and that pair can be created and stocked by anyone.

When Onsen added the WBTC/DIGG pair without an operator setting setBridge(DIGG, WBTC) (or any safe bridge), the conversion path for DIGG fell through to WETH. Because:

1. getPair(DIGG, WETH) is attacker-creatable. The factory's createPair is permissionless, so an attacker can make the canonical DIGG/WETH pair point at a pool they seeded.
2. _swap reads the live reserves of that pool and applies no amountOutMin. The SushiMaker sells the protocol's DIGG at a price the attacker dictates.
3. onlyEOA is the sole gate and is trivially satisfied.

So the protocol-owned fee LP is burned, and its DIGG leg is dumped into the attacker's pool at a manipulated rate; the attacker then withdraws their pool's liquidity to capture the value. No admin key, no flash loan (the onlyEOA gate even forces a non-contract caller), and no exotic math — just a missing bridge configuration that opened a forgeable price source.

Preconditions#

• A SushiSwap pair whose fees accrue to the SushiMaker, where at least one side has no bridge set (DIGG here). The Onsen launch created exactly this for WBTC/DIGG.
• The SushiMaker is holding a non-trivial LP balance for that pair (here 528,628,937 LP of WBTC/DIGG, output.txt:1681).
• An attacker EOA (to pass onlyEOA) and a small amount of the underlying tokens to seed the fake DIGG/WETH pool — recoverable at the end, so net cost is just gas + dust.

Attack walkthrough (mapped to the trace)#

The PoC reconstructs the attack at fork block 11,720,049. Because convert is mis-declared view in the harness, execution proceeds correctly up to the convert call and then reverts inside it; the steps below note exactly where each one appears in output.txt.

Why the PoC fails (and how to fix the harness)#

The local interface declares:

interface ISushiMaker {
    function convert(address x, address y) external view returns (uint256);  // ← WRONG: not view
}

test/Sushi_Badger_Digg_exp.sol:178-180

The real convert is external and state-mutating (it calls pair.transfer, pair.burn, pair.swap). Marking it view makes Solidity emit a STATICCALL; the first state write (pair.transfer) trips StateChangeDuringStaticCall, surfaced by the proxy token as BentoBox: Transfer failed. Changing the interface to function convert(address x, address y) external; (and removing the vm.prank(tx.origin) / onlyEOA mismatch if needed) is what the original author was missing.

Profit / loss accounting#

• Protocol loss: the SushiMaker's accrued WBTC/DIGG fee LP = 528,628,937 LP tokens (output.txt:1681). Burned, its DIGG leg is sold into the attacker's pool at a rate the attacker chose; the attacker then removes liquidity to capture it. In the real January 2021 incident this drained the fee buffer that had built up for the WBTC/DIGG Onsen pool (publicly reported on the order of tens of WBTC-equivalent + DIGG).
• Attacker cost: dust to seed the fake DIGG/WETH pool (here ~0.0005 WETH + 8590 DIGG, :1631) plus gas — recovered via removeLiquidity at the end. The onlyEOA gate forces the call from an EOA, so this is not flash-loanable, but the seed capital is trivially small.
• PoC-measured value: the test reverted before settlement, so no on-chain profit number was produced (Profit log never reached, :1684-1687). The numbers above are the ground-truth balances captured up to the revert.

Diagrams#

Sequence of the attack#

Decision flow inside _convert → _swap#

PoC state machine (why the local test halts)#

Remediation#

1. Never default a missing bridge to a permissionless pair. bridgeFor() should revert when _bridges[token] == address(0) (or restrict conversion to an explicit allow-list of bridges), so an unconfigured token cannot be silently routed through an attacker-creatable getPair(token, WETH).
2. Add slippage / min-out to _swap. Resolve the // TODO: Add maximum slippage? by passing an amountOutMin derived from a manipulation-resistant price (TWAP/oracle), and revert if the pool is too shallow or the post-swap price moves beyond a tolerance.
3. Validate the swap venue. Require the pair used by _swap to be a known, sufficiently-liquid protocol pair (e.g., minimum reserve / minimum age), not just any address getPair returns.
4. Fix the precedence bug. Rewrite the constant-product formula with explicit parentheses: amountOut = (amountIn*997*reserveOut) / (reserveIn*1000 + amountInWithFee); so the fee-adjusted input is part of the denominator, not added to the quotient.
5. Operational: when listing new Onsen pairs, set bridges (setBridge) for every new token before fees can accrue, and consider pausing convert for tokens without a configured bridge.

(SushiSwap's actual fix moved bridge handling into a guarded path and the team began setting bridges for all Onsen tokens; modern Maker/MakerLike rewrites add min-out + trusted bridge lists.)

How to reproduce#

The PoC is in this standalone Foundry project:

_shared/run_poc.sh 2021-01-Sushi_Badger_Digg_exp --mt testHack -vvvvv

• RPC: an Ethereum archive endpoint is required (fork block 11,720,049 is from January 2021; foundry.toml points mainnet at an Infura archive URL). Most pruned/public RPCs will fail with header not found / missing trie node.
• Current result: [FAIL: BentoBox: Transfer failed] testHack() — see output.txt:1700. Execution succeeds through fake-pair creation/seeding and halts inside convert (mapped above).

Expected tail (as-is, failing):

Ran 1 test for test/Sushi_Badger_Digg_exp.sol:Exploit
[FAIL: BentoBox: Transfer failed] testHack() (gas: 1040507767)
...
  at UniswapV2Pair.transfer
  at SushiMaker.convert
  at Exploit.testHack (test/Sushi_Badger_Digg_exp.sol:41:38)

To make it pass, change the PoC's ISushiMaker.convert from external view returns (uint256) (test/Sushi_Badger_Digg_exp.sol:179) to a plain non-view external function so Foundry issues a CALL (not a STATICCALL), allowing the state-mutating conversion — and thus the rug — to execute.

References (from the PoC header):

• cmichel — "Replaying Ethereum hacks: SushiSwap / Badger DAO / DIGG" — https://cmichel.io/replaying-ethereum-hacks-sushiswap-badger-dao-digg/
• SlowMist — "SushiSwap was attacked for the second time" — https://slowmist.medium.com/slow-mist-sushiswap-was-attacked-for-the-second-time-a47f2d110a84
• rekt.news — "Badgers, DIGG & Sushi" — https://www.rekt.news/badgers-digg-sushi/
• SushiMaker source: https://github.com/sushiswap/sushiswap/blob/64b75815/contracts/SushiMaker.sol

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2021-01-Sushi_Badger_Digg_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Sushi_Badger_Digg_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "SushiMaker".
• 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.