Rikkei Finance Exploit — Permissionless `setOracleData()` Oracle Hijack on a Compound-style Money Market

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

Vulnerability classes: vuln/access-control/missing-auth · vuln/oracle/price-manipulation

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 all compile together, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: SimplePriceOracle, Cointroller (logic behind the Unitroller proxy), RBep20Delegate (rUSDC logic), RBinance (rBNB logic).

Key info#

TL;DR#

1. Rikkei Finance is a Compound V1 fork on BSC. Its Cointroller (risk engine) prices every market's collateral through a single SimplePriceOracle, which resolves each rToken's USD price by calling decimals() and latestRoundData() on whatever address is stored in oracleData[rToken] (contracts_SimplePriceOracle.sol:29-37).

2. The setter setOracleData(address rToken, oracleChainlink _oracle) writes that mapping with no access control at all — no onlyAdmin, no onlyOwner, no timelock (contracts_SimplePriceOracle.sol:29-31). Anyone can point any market's feed at any contract.

3. The attacker enters the rBNB market, mints a tiny 0.0001 BNB rBNB deposit (rbnb.mint{value: 100_000_000_000_000}(), output.txt:35), then calls simplePriceOracle.setOracleData(rbnb, address(this)) to make the attacker's own contract the rBNB price source (output.txt:61).

4. The attacker's fake feed returns decimals() = 8 (real Chainlink) but a latestRoundData().answer that is pre-multiplied by 1e10. The oracle then applies its own 10**(18-decimals) = 1e10 scaling again, so the on-chain rBNB price is inflated 10¹⁰× to ~4.162e30 (1e18-base) instead of the correct ~4.162e20 (output.txt:111-112).

5. With rBNB collateral booked at a fictitious ~4.16e12 USD/BNB, the attacker's 0.0001 BNB "covers" the entire rUSDC cash. The attacker calls rusdc.borrow(rusdc.getCash()) and borrows 346,199.78 USDC — every token in the market (output.txt:74-75, output.txt:157).

6. The attacker sweeps the borrowed rUSDC to the EOA (rusdc.transfer(...), output.txt:149-151), then resets the oracle to the legitimate Chainlink BNB/USD feed to cover its tracks (output.txt:238-240).

7. Net result: +346,199.780826500224370302 USDC for a 0.0001 BNB (~$0.04) outlay (output.txt:246). The rUSDC market is left with zero cash and an uncollateralized borrow.

Background — what Rikkei does#

Rikkei Finance is a fork of Compound V1 (the "Rifi" protocol family). Users supply an asset to an RBep20/RBinance (Compound "cToken") market, receive interest-bearing rTokens, and may then borrow other listed assets up to a collateral-factor limit enforced by the Cointroller. The Cointroller lives behind a Unitroller proxy (contracts_Unitroller.sol) that delegatecalls to the Cointroller logic (contracts_Cointroller.sol).

Every borrowing/liquidation decision flows through one function: SimplePriceOracle.getUnderlyingPrice(rToken), which returns the USD value of one unit of the underlying, scaled to 1e18. The Cointroller multiplies each account's supplied rToken balance by that price and by the market's collateral factor to derive borrowing power. If the oracle lies, the entire risk model lies with it.

At the fork block (16,956,474), read directly from the trace:

The prize is the rUSDC getCash() balance. With a correct oracle, 0.0001 BNB (~$0.04) of collateral could borrow at most a few cents of USDC. The exploit makes the oracle report that same 0.0001 BNB as worth ~4.16e12 USD.

The vulnerable code#

1. SimplePriceOracle.setOracleData — no access control#

contract SimplePriceOracle is PriceOracle {
    mapping(address => uint) prices;

    event PricePosted(address asset, uint previousPriceMantissa, uint requestedPriceMantissa, uint newPriceMantissa);

    mapping(address => oracleChainlink) public oracleData;

    constructor() public {
    }
    function setOracleData(address rToken, oracleChainlink _oracle) external {
        oracleData[rToken] = _oracle;
    }
    ...
}

(contracts_SimplePriceOracle.sol:20-31)

The setter is external with no modifier. The trace confirms a bare externally-owned account (the test contract) writes the mapping directly: the storage slot for oracleData[rBNB] flips from the Chainlink feed 0x0567f23... to the attacker 0x7FA938... in a single unprivileged call (output.txt:61-63).

2. getUnderlyingPrice trusts the configured feed blindly#

function getUnderlyingPrice(RToken rToken) public view returns (uint) {
    uint decimals = oracleData[address(rToken)].decimals();
    (uint80 roundId,int256 answer,uint256 startedAt,uint256 updatedAt,uint80 answeredInRound) =
        oracleData[address(rToken)].latestRoundData();
    return 10 ** (18 - decimals) * uint(answer);
}

(contracts_SimplePriceOracle.sol:33-37)

Two independent problems:

• It does not validate that oracleData[rToken] is a known, governance-pinned Chainlink aggregator — it just calls whatever address is stored there.
• It does not sanity-bound the returned answer (no deviation/staleness/heartbeat checks), so an attacker-controlled feed can return any value.

The decimal handling is also fragile. With a correct 8-decimal Chainlink answer of 41624753868, the formula 10**(18-8) * answer = 1e10 * 41624753868 = 4.162e20 yields the correct ~416.25 USD price in 1e18 base (output.txt:109). The attacker exploits the lack of input validation: its fake latestRoundData() returns an answer that is already pre-scaled by 1e10, so the oracle's own 1e10 factor double-counts the scaling and inflates the price 10¹⁰×.

3. The attacker's fake feed (from the PoC)#

function decimals() external view returns (uint8) {
    return chainlinkBNBUSDPriceFeed.decimals();   // 8 — keeps the oracle's 1e10 factor active
}

function latestRoundData()
    external
    view
    returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound)
{
    (roundId, answer, startedAt, updatedAt, answeredInRound) = chainlinkBNBUSDPriceFeed.latestRoundData();
    answer = answer * 1e10;                        // ⚠️ pre-scale so the oracle double-applies 1e10
}

(test/Rikkei_exp.sol:35-46)

The trace shows this contract returning answer = 416247538680000000000 (~4.162e20, output.txt:111); the oracle then computes 1e10 * 416247538680000000000 = 4162475386800000000000000000000 (~4.162e30, output.txt:112) — the inflated rBNB price the Cointroller uses for borrow-power.

4. The Compound-style borrow path that consumes the bad price#

The RBep20Delegate.borrow flow delegates into borrowAllowed on the Cointroller, which calls getUnderlyingPrice for both the collateral (rBNB) and the borrowed asset (rUSDC) to compute the account's liquidity:

0xD55f01B4B51B7F48912cD8Ca3CDD8070A1a9DBa5::getUnderlyingPrice(0x157822...rBNB)
  → 4162475386800000000000000000000   [4.162e30]   (inflated 1e10×)
0xD55f01B4B51B7F48912cD8Ca3CDD8070A1a9DBa5::getUnderlyingPrice(0x916e87...rUSDC)
  → 999951040000000000                [9.999e17]   (unchanged, correct)

(output.txt:99-112, output.txt:123-132)

Because rBNB's price is 10¹⁰× too high, the 0.0001 BNB deposit (mintTokens = 499553304430711102439309 rBNB, output.txt:51) registers as enough borrowing power to take the entire rUSDC cash in one borrow() call.

Root cause — why it was possible#

The root cause is a single missing access-control modifier on the most security-critical state-changing function in the system. A money market's price oracle is the input that every borrowing, liquidation, and collateral decision is derived from; making its setter user-writable turns borrowing into a self-authorized infinite-borrow.

Three compounding design flaws make the bug catastrophic rather than cosmetic:

1. No auth on setOracleData. Compare with Compound's PriceOracleProxy.setAdmin / setDirectPrice, which are onlyAdmin / onlyOwner. Rikkei's setter is bare external — a single transaction rewrites any market's price source.
2. No validation of the configured source. getUnderlyingPrice does not whitelist known Chainlink aggregators, does not check updatedAt for staleness, and does not bound the answer against a prior value or a heartbeat. Whatever oracleData[rToken] returns is trusted verbatim.
3. Decimal re-scaling is attacker-influenceable. Because the oracle derives the scale factor from the feed's own decimals(), and the attacker controls both decimals() and latestRoundData(), the attacker can engineer any price magnitude. Here it keeps decimals = 8 (so the 1e10 factor stays) and pre-multiplies the answer by 1e10, netting a 10¹⁰× inflation.

The attacker also resets the oracle to the legitimate Chainlink feed at the end (output.txt:238-240), which is why on-chain post-mortems can show "the oracle looks fine" — the malicious state only existed for the duration of the attack transaction.

Preconditions#

• The rUSDC market holds positive cash to borrow (getCash = 346199780826500224370302, output.txt:74).
• A tiny amount of BNB (0.0001 BNB, ~$0.04 at the fork block) to mint the rBNB collateral and pay gas. No flash loan is needed — the capital requirement is effectively zero.
• The SimplePriceOracle is the Cointroller's active oracle and its setOracleData is unguarded (verified from the on-chain verified source, contracts_SimplePriceOracle.sol:29-31).

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

All figures are read directly from the Logs and Traces sections of output.txt. Raw wei are shown with a human approximation in parentheses. USDC and rUSDC use 18 decimals on BSC; BNB/rBNB use 18.

Why the inflated price passes borrowAllowed#

The Cointroller computes account liquidity as Σ (supplyBalance × collateralFactor × price) − Σ (borrowBalance × price). With rBNB price inflated 1e10×, the attacker's 0.0001 BNB deposit contributes a fictitious borrowing power on the order of 499553 rBNB × 4.162e30 ≈ 2.08e36, which dwarfs the requested 346199 USDC × 1e18 debt. The liquidity check passes trivially (output.txt:84-143).

Profit / loss accounting (USDC, raw wei, 18 decimals)#

The PoC asserts the exact post-balance via log_named_uint: After exploit, USDC balance of attacker: 346199780826500224370302 (output.txt:7, output.txt:246). The market's getCash is drained to zero (the entire cash was borrowed and transferred out, output.txt:149-151).

Diagrams#

Sequence of the attack#

State evolution of the oracle and the rUSDC market#

The flaw inside getUnderlyingPrice / setOracleData#

Why each magic number#

• 100_000_000_000_000 wei (0.0001 BNB) — the mint deposit. It only needs to be non-zero so the market credits some rBNB collateral (mintTokens = 499553..., output.txt:51); after the 1e10× oracle inflation, even a single wei of BNB would technically suffice. 0.0001 BNB was chosen for tidiness. Total outlay ≈ $0.04.
• decimals() == 8 (returned by both the real Chainlink feed and the attacker fake feed, output.txt:101-105) — keeps the oracle's 10**(18-8) = 1e10 scale factor live. If the attacker returned a different decimal count, the inflation factor would change but the attack still works; 8 matches Chainlink so the pre-multiplication by 1e10 compounds cleanly into a 1e10× inflation.
• answer * 1e10 in the fake latestRoundData() (test/Rikkei_exp.sol:45) — converts the real 8-dec Chainlink answer (41624753868) into an 18-dec value (416247538680000000000, output.txt:111). The oracle then applies its own 1e10 factor again, producing 4.162e30 (output.txt:112) — 10¹⁰× the correct 4.162e20.
• rusdc.getCash() as the borrow amount (output.txt:74) — borrowing exactly the market's entire cash drains it to zero in one call. No need to compute a collateral-constrained maximum; the inflated oracle makes the limit effectively infinite.
• Final setOracleData(rBNB, chainlinkBNBUSDPriceFeed) (output.txt:238) — restores the legitimate feed so the protocol's post-attack monitoring sees a "normal" oracle, slowing detection. Cosmetic to the exploit itself.

Remediation#

1. Gate setOracleData behind admin/governance + a timelock. This is the primary fix. Add onlyAdmin (or onlyOwner) and route changes through the project's timelock so users can react. A money-market oracle setter must never be permissionless.
2. Whitelist oracle sources at deployment; never accept an arbitrary address. Store the canonical Chainlink aggregator per market in immutable/governance storage and have getUnderlyingPrice read only from those — eliminate the indirection mapping entirely.
3. Sanity-check oracle outputs. Enforce a maximum deviation per update, reject stale answers (updatedAt within a heartbeat), reject non-positive or absurdly large answers, and ideally cross-check against a secondary feed or a TWAP. A 1e10× jump should never be accepted silently.
4. Use canonical Chainlink feeds directly. Rikkei's indirection through a mapping(address => oracleChainlink) adds an attack surface (the setter) with no benefit over calling the known aggregator addresses directly.
5. Harden the decimal handling. Derive the scale from a per-market configured decimal constant, not from the feed's self-reported decimals(), so a malicious feed cannot manipulate the magnitude of the price via its decimals() return.
6. Add a circuit breaker on the money market. A per-market borrow cap and a global anomalous-withdrawal pause would bound the worst-case loss even if the oracle is compromised.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has unrelated PoCs that do not all compile under one forge build). It runs fully offline via the shared harness, which serves the fork from the bundled anvil_state.json; the test's createSelectFork points at the local anvil on port 8546 (test/Rikkei_exp.sol:18).

_shared/run_poc.sh 2022-04-Rikkei_exp --mt testExploit -vvvvv

• No public RPC is required: run_poc.sh boots anvil on the per-chain port with the project's anvil_state.json and the test forks http://127.0.0.1:8546 at block 16,956,474.
• evm_version = "cancun" in foundry.toml (the test itself is ^0.7.0-era Solidity and is compatible).
• The test function is testExploit (test/Rikkei_exp.sol:21).

Expected tail (verbatim from output.txt:3-7 and output.txt:249-251):

Ran 1 test for test/Rikkei_exp.sol:ContractTest
[PASS] testExploit() (gas: 736167)
Logs:
  Before exploit, USDC balance of attacker:: 0
  After exploit, USDC balance of attacker:: 346199780826500224370302

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.75s (17.68ms CPU time)

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

Reference: Rikkei Finance SimplePriceOracle.setOracleData access-control vulnerability, BSC, April 2022 (~$270K). PeckShield incident analysis — https://twitter.com/PeckShieldAlert/status/1514134374120165377 .

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

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