Makina Finance Exploit — Self-Referential AUM Oracle Manipulation via Permissionless Re-Accounting

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

Vulnerability classes: vuln/oracle/price-manipulation · vuln/governance/flash-loan-attack

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 all compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable sources: Caliber.sol, MachineShareOracle.sol, Machine.sol.

Key info#

TL;DR#

Makina is an on-chain asset-management vault. Users deposit USDC and receive DUSD (the MachineShare token). DUSD's "fair value" is the vault NAV per share: lastTotalAum / shareSupply, exposed by MachineShareOracle.getSharePrice(). A Curve StableSwap-NG DUSD/USDC pool uses that very oracle as DUSD's rate_oracle (_stored_rates()), so the Curve pool prices DUSD at exactly whatever NAV-per-share Makina reports.

The NAV (lastTotalAum) is built from the vault's positions. A position's value is computed by Caliber._accountForPosition(), which runs a Weiroll script that reads live, manipulable Curve pool reserves and get_virtual_price() (3Pool, MIM/3Crv) and prices them with no manipulation resistance. Both the re-accounting call (accountForPosition) and the NAV refresh (Machine.updateTotalAum) are permissionless.

So the attacker, in a single flash-loaned transaction:

1. Pumps the Curve pools that back the vault's positions (3Pool, MIM/3Crv) with ~280M USDC of borrowed liquidity, inflating the value the Caliber will attribute to its position.
2. Re-accounts the position (accountForPosition) and refreshes NAV (updateTotalAum). The position value jumps from 3.06T → 19.36T (accounting units), pushing lastTotalAum from 51.58T → 67.89T, i.e. DUSD NAV per share 1.011771 → 1.331577 (+31.6%).
3. Sells DUSD into the Curve pool at the now-inflated rate (the rate oracle returns the pumped NAV), receiving ~31% more USDC per DUSD than it paid moments earlier.
4. Unwinds the Curve manipulation and resets Makina state. Repeats once. Repays the flash loan.

Net: +$4,304,016 USDC in the PoC (two runs), draining the honest USDC liquidity from the DUSD/USDC pool.

Background — what Makina does#

Makina is a vault/asset-manager protocol with three relevant pieces:

• Machine (Machine.sol) — the hub vault. Holds the cached NAV _lastTotalAum, mints/redeems the MachineShare token (here symbol DUSD), and computes share price from _lastTotalAum / shareSupply.
• Caliber (Caliber.sol) — the strategy executor. It holds the vault's DeFi positions (Curve LP, Morpho, etc.). Each position's value is re-computed by running a merkle-allowlisted Weiroll instruction (accountForPosition) that reads on-chain state and caches the result in pos.value. getDetailedAum() sums all pos.values to report the hub Caliber's NAV.
• MachineShareOracle (MachineShareOracle.sol) — a price feed that returns getSharePrice() = lastTotalAum / shareSupply (scaled). This oracle is wired into the Curve DUSD/USDC StableSwap-NG pool as DUSD's rate oracle, so the pool's exchange rate tracks the reported NAV per share.

Key on-chain facts at the fork block (from the trace):

The ~$5.1M of USDC sitting in the DUSD/USDC Curve pool is the prize.

The vulnerable code#

1. The vault NAV oracle reads the cached lastTotalAum and feeds the Curve pool#

// MachineShareOracle.getSharePrice()  (post-migration branch)
function getSharePrice() external view override returns (uint256) {
    ...
    } else {
        address machine = $._isShareOwnerPdv ? IPreDepositVault($._shareOwner).machine() : $._shareOwner;
        uint256 aum = IMachine(machine).lastTotalAum();              // ← cached NAV
        sharePrice = MachineUtils.getSharePrice(aum, stSupply, $._shareTokenDecimalsOffset);
    }
    return $._scalingNumerator * sharePrice;
}

MachineShareOracle.sol:98-121 · getSharePrice = SHARE_UNIT × (aum+1) / (supply+offset) (MachineUtils.sol:138-144).

The Curve DUSD/USDC pool consumes this as DUSD's rate_oracle and bakes it straight into the swap math:

# CurveStableSwapNG._stored_rates()
if asset_types[i] == 1 and not rate_oracles[i] == 0:
    oracle_response: Bytes[32] = raw_call(
        convert(rate_oracles[i] % 2**160, address),
        _abi_encode(rate_oracles[i] & ORACLE_BIT_MASK),   # → MachineShareOracle.getSharePrice()
        max_outsize=32, is_static_call=True)
    fetched_rate: uint256 = convert(oracle_response, uint256)
    rates[i] = unsafe_div(rates[i] * fetched_rate, PRECISION)   # DUSD priced at NAV/share

CurveStableSwapNG.sol:433-468

2. The position value is computed from manipulable spot AMM state, with no guard#

function _accountForPosition(Instruction calldata instruction, bool checks) internal returns (uint256, int256) {
    if (checks) {
        if (instruction.instructionType != InstructionType.ACCOUNTING) revert Errors.InvalidInstructionType();
        _checkInstructionIsAllowed(instruction);          // only a merkle-root allowlist on the *script*
    }
    bytes[] memory returnedState = _execute(instruction.commands, instruction.state); // Weiroll: reads live pool state
    amounts = _decodeAccountingOutputState(returnedState);
    ...
    for (uint256 i; i < len; ++i) {
        currentValue += _accountingValueOf(token, amounts[i]);  // value derived from manipulated reserves
    }
    ...
    pos.value = currentValue;                              // ← cached, no TWAP / no sanity bound
    pos.lastAccountingTime = block.timestamp;
    return (currentValue, int256(currentValue) - int256(lastValue));
}

Caliber.sol:726-783

The Weiroll script (instruction.commands) reads, in the trace, the 3Pool balances(0..2) and get_virtual_price() and the DUSD pool totalSupply/virtual price — all flash-loan-manipulable — and multiplies them via mulDiv (the 0x836C9007 math helper). Prices for DAI/USDC/USDT come from Chainlink, so the manipulation rides on the quantities (pool reserves), which the allowlisted script trusts at spot.

3. Re-accounting and NAV refresh are both permissionless#

function accountForPosition(Instruction calldata instruction)
    external override nonReentrant returns (uint256, int256)       // ← NO access control
{ ... return _accountForPosition(instruction, true); }

Caliber.sol:331-345

function updateTotalAum() external override nonReentrant notRecoveryMode returns (uint256) {  // ← NO access control
    uint256 _lastTotalAum = MachineUtils.updateTotalAum($, IHubCoreRegistry(registry).oracleRegistry());
    ...
}

Machine.sol:392-403 · _getTotalAum sums getDetailedAum() from the hub Caliber (MachineUtils.sol:204-250).

Anyone can therefore (a) force the Caliber to re-value its position against manipulated reserves, and (b) snapshot that inflated number into lastTotalAum, which the Curve pool immediately trusts.

Root cause — why it was possible#

The protocol built a circular pricing dependency with no manipulation resistance:

Curve DUSD/USDC rate  ←  MachineShareOracle.getSharePrice  ←  Machine.lastTotalAum
        ↑                                                            ↑
   attacker sells DUSD here                            Caliber.pos.value  ←  spot Curve reserves (3Pool, MIM)
                                                                            ↑
                                                            attacker pumps these here

1. NAV is valued from spot AMM reserves. Caliber._accountForPosition runs a Weiroll script that reads balances() and get_virtual_price() of the very Curve pools an attacker can move with a flash loan. There is no TWAP, no min/max bound on the per-call value change, and no comparison against an independent reference. The merkle allowlist only constrains which script runs — not the values it reads.
2. The NAV is exposed as a tradeable price. Because the DUSD/USDC Curve pool uses getSharePrice() as DUSD's rate oracle, the inflated NAV is not just a reporting number — it becomes the exchange rate at which DUSD trades for real USDC. NAV inflation is directly monetizable.
3. Both refresh entry points are permissionless. accountForPosition and updateTotalAum have no access control, so the attacker controls when the inflated valuation is captured — immediately before selling. A keeper-only / cool-down design would have prevented attacker-timed snapshots.
4. The cache is read fresh, atomically. pos.value and lastTotalAum are plain cached values that the attacker re-writes in the same transaction; the staleness check in getDetailedAum (Caliber.sol:283-284) only requires fresh accounting — it does nothing to stop a maliciously fresh value.

The exploit is fully recoverable intra-transaction (the pump is unwound), so it is flash-loanable — the PoC simply deals 280M USDC as working capital.

Preconditions#

• The DUSD/USDC Curve pool is configured to use MachineShareOracle.getSharePrice() as DUSD's rate oracle (asset_type 1) — true at the fork block.
• The hub Caliber holds at least one position whose accounting script reads flash-loan-manipulable Curve pool state (3Pool, MIM/3Crv) — true (position 329781725403426819283923979544582973776).
• Working capital in USDC to move the backing Curve pools. Peak outlay was the 280M USDC flash loan, fully recovered intra-transaction → flash-loanable.
• No timelock / keeper restriction on accountForPosition or updateTotalAum — true (both permissionless).

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

Each runExploit() does steps 1–7 below; the PoC runs it twice. All figures are taken directly from output.txt (console.log lines and TokenExchange/return values).

Run 2 repeats: NAV pumped 51.58T → 68,217,264,462,913, NAV/share → 1.331577 again, DUSD swap of 9,235,449 DUSD, ending cumulative USDC 284,304,016,338,798.

Profit accounting (USDC)#

The PoC nets $4.3M; the live on-chain pool loss was ≈ $5.1M (different exact sizing on-chain and a MEV bot front-running part of the value). The profit is the honest USDC that real LPs had in the DUSD/USDC pool, plus DUSD redeemed at an artificially high rate.

Diagrams#

Sequence of the attack (one runExploit)#

NAV / share-price state evolution#

The flaw: self-referential valuation loop#

Why each magic number#

• 280M USDC flash loan — enough to move the 3Pool and MIM/3Crv reserves materially while leaving headroom to also buy ~9.2M DUSD in the DUSD/USDC pool; fully recovered intra-tx.
• 100M add_liquidity + 10M exchange in the DUSD pool — acquires 9.215M DUSD cheaply (at ~1.011) and pre-loads the pool with USDC so the later DUSD→USDC sell has liquidity to drain.
• 170M into 3Pool, 120M+30M into MIM/3Crv — skews the reserves that the Caliber's accounting Weiroll script reads, so the re-accounted position value jumps +16.30T, lifting NAV/share by +31.6%.
• Two runs — each run extracts the premium the pool can supply at that moment; repeating compounds the drain until the pool's honest USDC is exhausted.

Remediation#

1. Do not value NAV from spot AMM state. The Caliber accounting scripts must price Curve/AMM LP positions from manipulation-resistant sources (LP fair-value using external per-asset oracles and get_virtual_price bounded by a TWAP, not raw spot balances()), or cap the per-call position-value change.
2. Break the self-reference. A share-price oracle that feeds an external market (the Curve rate_oracle) must not be derivable, within the same block, from positions that trade against that same market. Use a smoothed/lagged NAV (TWAP of lastTotalAum, or a min-update interval) for the rate oracle so it cannot be moved and consumed atomically.
3. Gate the refresh entry points. Restrict accountForPosition and updateTotalAum to a trusted keeper/role, or enforce a cool-down so an attacker cannot snapshot a freshly-manipulated valuation and trade on it in the same transaction.
4. Add value sanity bounds. Reject a position re-accounting (or an AUM update) whose value change exceeds a configurable per-update threshold relative to the prior value; a +500% position jump in one call is a red flag.
5. Make the NAV path reentrancy/flash-loan aware. Even with a merkle-allowlisted script, the inputs it reads must be validated; allowlisting the script is not the same as validating the data the script trusts.

How to reproduce#

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

_shared/run_poc.sh 2026-01-makina_exp -vvvvv

• Mainnet archive RPC required — the fork is at block 24,273,361 (24_273_362 - 1). foundry.toml uses an Infura archive endpoint, which serves historical state at that block.
• evm_version = cancun is required (set in foundry.toml); the PoC header notes this.
• Result: [PASS] testMakinaExploitTest() with Final Profit in USDC: $ 4304016.

Expected tail:

Ran 1 test for test/makina_exp.sol:MakinaExploitTest
[PASS] testMakinaExploitTest() (gas: 4369450)
  USDC after repay 280M USDC: 4304016338798
  Final Profit in USDC: $ 4304016
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 4.68s

References: post-mortem — https://github.com/anon-cBE4/anon-cBE4/blob/main/writeups/makina_attack_analyze.md · QuillAudits — https://www.quillaudits.com/blog/hack-analysis/makina-4m-hack-explained · alerts — TenArmor / CertiK.

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

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