Cowrie Research

mirror-protocol-lock-contract-duplicate-unlock-2021-10-08

13 min read

Mirror Protocol lock contract duplicate unlock (2021-10-08)

  • Name: Mirror Protocol lock contract duplicate unlock
  • Date: 2021-10-08
  • Protocol: Mirror Protocol
  • Chain: Terra Classic
  • Category: balance-delta provenance failure / duplicate claim / idempotency failure / replayable unlock / lock-contract accounting injection
  • Loss: about $89.7M in UST / USTC, widely reported as roughly $90M
  • Summary: Mirror’s mirror_lock contract let one economic right be consumed many times. First, the attacker directly transferred large amounts of USTC into the lock contract before opening short positions. Because lock_position_funds_hook inferred a position’s locked_amount from the lock contract’s live balance delta, each prepared position could end up with a recorded locked amount around 100,004 USTC even though only about 4 USTC came from the short sale itself and the formal collateral deposit was just 10 USTC. After the lock period expired, the attacker called unlock_positions_funds() with the same position_idx repeated hundreds of times. The function summed the same locked amount over and over, so one prepared position could release tens of millions of USTC in a single call.
  • Trigger / entry point:
    • Mirror’s short-position flow routed sold proceeds into the mirror_lock contract and then invoked lock_position_funds_hook() to determine how much value belonged to the newly opened position.
    • In the onchain contract, lock_position_funds_hook() computed position_locked_amount as current_balance.checked_sub(locked_funds)?, so unsolicited USTC already sitting in the contract could be misattributed to the new position.
    • Later, unlock_positions_funds() accepted a caller-supplied array of position_idx values and, in the vulnerable version, effectively iterated that vector and summed every matching locked_amount without rejecting duplicates first.
  • Root cause:
    • Mirror violated the consume once invariant on locked positions: the batch unlock path treated repeated copies of the same position as distinct unlockable entitlements.
    • The blast radius was amplified by another accounting flaw: lock_position_funds_hook trusted ambient contract balance changes to size one position’s locked amount.
    • Together, those two mistakes created a clean two-stage drain: first inflate the amount attached to one lock record, then replay that same record hundreds of times inside the unlock batch.
  • Exploit path:
    1. The attacker sent 100,000 USTC directly to Mirror’s lock contract in a preparation transaction.
    2. In the same preparation flow, they opened a short position with only 10 USTC of formal collateral and short_params enabled, causing the mint contract to mint a tiny amount of mETH, sell it into the mETH-UST pair, and send about 4.06582 USTC of swap proceeds into the lock contract.
    3. When lock_position_funds_hook ran for position 43186, it compared the lock contract’s live balance to tracked locked funds and concluded that this new position had roughly 100,004 USTC locked, not merely the few USTC actually produced by the short sale.
    4. The attacker repeated this setup pattern across many positions, using direct transfers from roughly 1,000 to 100,000 USTC to create oversized locked_amount records.
    5. Once positions had passed the unlock delay, the attacker called unlock_positions_funds() with duplicate IDs. In the representative exploit transaction, position 43186 appeared 437 times.
    6. Because the contract did not check for duplicate position_idx values, it summed the same roughly 0.1M USTC locked amount for each repeated copy and released about 43.7M USTC from that one prepared position in a single call.
    7. The attacker repeated the same mechanism across other prepared positions until the cumulative drain reached about $89.7M.
  • What the attacker needed to be true:
    • The lock contract had to treat unsolicited token transfers as part of the next position’s locked funds.
    • The unlock path had to accept caller-supplied duplicate position IDs without deduplication or explicit rejection.
    • The lock period had to expire before the replayable unlock could be exercised.
    • The contract had to hold enough USTC liquidity for inflated unlock accounting to settle into real withdrawals.
  • Technical anatomy worth remembering:
    • This was not just a duplicate IDs bug in isolation. The duplicate-unlock primitive became protocol-scale because Mirror also sized per-position locked funds from ambient balance differences instead of a tighter accounting source.
    • The exploit is a good reminder that batch payout code and helper accounting code compose: a replay bug that would otherwise be moderate can become catastrophic when one claimable record can first be overfilled.
    • The patch diff is a useful forensic artifact: Mirror replaced a simple iter().map(...).sum()-style accumulation over unlockable_positions with an explicit loop that tracked unlocked_positions, reverted on Duplicate position_idx, and only then accumulated unlock_amount.
    • Community criticism later centered not only on the bug itself, but on the fact that Mirror developers quietly patched the issue before public disclosure that it had already been exploited in the wild.
  • Representative transactions and artifacts:
    • Preparation transaction highlighted by BlockSec: 29C9CFBBC9562100A5DB19D705E440CE24768D3BDE399507FA1C2EC2424413C4
    • Representative unlock transaction: 08DD2B70F6C2335D966342C20C1E495FD7A8872310B80BAF3450B942F79EBC1F
    • Patch commit: 56cc6946b9457293ede6aa0feb296ee1d16f6974 (Short reward cap to 80% + bugfix (#98))
    • Key affected module: contracts/mirror_lock/src/contract.rs
  • Response / mitigation:
    • Mirror patched the lock contract in commit 56cc6946b9457293ede6aa0feb296ee1d16f6974, replacing the old aggregate-sum path in unlock_positions_funds() with an explicit duplicate check over unlockable_positions that aborts on Duplicate position_idx.
    • Reporting after the public discovery indicated the bug had been fixed quietly in May 2022 before the wider community realized the exploit had been active since October 2021.
    • The narrower code fix stopped the replay path, but the incident also highlights the need to avoid inferring entitlement size from ambient token balances when unsolicited transfers are possible; the duplicate guard alone did not erase that broader accounting smell.

Three lock-and-exit promotions this incident collapsed

  1. Ambient USTC was present in mirror_lock

    • The contract wallet really did hold the attacker’s prefunded USTC plus the tiny short-sale proceeds.
    • That was only a raw balance fact. It did not yet prove that the newly opened short position had earned that whole amount as its own locked proceeds.

  2. Mirror promoted that ambient balance into one position’s canonical locked_amount truth

    • lock_position_funds_hook() treated current_balance - locked_funds as if it were exact provenance for the just-opened position, so one position record inherited roughly 100,004 USTC of locked value even though the short sale itself produced only about 4.06582 USTC and the formal collateral deposit was just 10 USTC.
    • This was the decisive accounting publication step: contract-level balance presence became position-level entitlement truth.

  3. That published lock record still inherited live unlock authority, repeatedly

    • unlock_positions_funds() then accepted duplicate position_idx values and summed the same oversized lock record over and over before releasing funds.
    • The protocol therefore promoted one attacker-shaped lock record into immediate cash-out authority many times, not once.

The reusable review split is: tokens were sitting in the lock contract, those tokens were published as this exact position's locked claim, and that published claim was then allowed to spend real USTC on every repeated exercise. Mirror collapsed all three.

Pattern tags

  • duplicate-claim-idempotency-failure
  • balance-delta-provenance-failure
  • lock_position_funds_hook() treated ambient USTC already sitting in mirror_lock as if it were the newly opened short position’s own locked proceeds, so one future unlock record could be preloaded with someone else’s prefunded balance
  • unlock_positions_funds() then let the same position_idx appear hundreds of times in one batch, turning one oversized lock record into repeated cash-out rights instead of one consumed entitlement
  • The exploit therefore composed two reusable accounting mistakes: who does this balance delta belong to? failed first, and how many times can this exit right be exercised? failed second

Why the exploit worked

  • Mirror’s lock helper was already publishing ownership fiction before the replay started. lock_position_funds_hook() sized one position’s locked_amount from current_balance - locked_funds, which only proved that USTC was present in the lock contract, not that the just-opened short position had actually produced that much sale proceeds. Once the attacker parked 100,000 USTC in the contract first, the next position inherited that ambient balance as if it were its own.
  • The later unlock bug then monetized that false record almost perfectly. unlock_positions_funds() trusted the caller-supplied positions_idx batch, accumulated each matching locked_amount, and only afterward transferred the aggregate amount. Repeating 43186 437 times therefore turned one roughly 100,004 USTC record into about 43.7M USTC of payout in a single transaction.
  • The two issues mattered more together than alone. A duplicate-unlock bug against tiny short-sale proceeds would have been annoying but smaller; ambient-balance attribution without replay would have overpaid one exit once. Mirror made both mistakes in sequence, so one fabricated large entitlement could be exercised many times.
  • The patch history is part of the preserved lesson. Mirror eventually replaced the blind summation path with explicit duplicate detection, but public reporting later argued that the protocol had already patched quietly months before broad disclosure that the exploit had been active. Review discipline failed at both the code and communication layers.

Detection and audit pivots

  • Treat lock-accounting helpers like solvency code. If a contract derives one user’s locked_amount, claim size, or reserve credit from balanceAfter - balanceBefore, ask what stops prefunds, donations, or unrelated transfers from being attributed to that user.
  • For every batched exit path, force the reviewer question what exact storage key makes the second exercise of this entitlement worth zero? In Mirror, the dangerous answer was none until after the batch sum had already grown.
  • Compare batch behavior to repeated single-item execution. If [id, id, id] can pay more than three serial calls after the first one should have consumed the record, the exit path is publishing replayable value.
  • Trace the full composition, not just each bug in isolation. Mirror is a strong reminder to ask whether an upstream accounting helper can inflate the value attached to one entitlement before a downstream replay or unlock routine multiplies it.
  • Review disclosure and patch timing as part of protocol safety. Quietly fixing an exploit path without promptly surfacing that it was live leaves users and downstream integrators pricing stale risk while the protocol already knows the trust boundary was broken.

Failure-prevention checklist

  • Derive one position’s locked_amount from a position-local receipt object, not from ambient contract balance deltas. Direct transfers, prefunds, fee rebates, or unrelated unlock returns should never be able to masquerade as the next short position’s own locked proceeds.
  • Quarantine unsolicited token inflows until an explicit operator or accounting path recognizes them. tokens are sitting in the lock contract is not the same fact as this position earned those tokens as locked value.
  • Make unlock_positions_funds() economically equivalent to repeated single-position unlock execution against one shared consumed-state machine. A batch helper should not create a second replay story for the same lock record.
  • Reject duplicate position_idx values before any unlock amount is accumulated. The entitlement set has to be canonicalized first; payout math comes second.
  • Mark lock records consumed, reduced, or otherwise made economically inert before later loop iterations or sibling helper paths can still observe them as live exit rights.
  • Property-test the composition, not just each helper in isolation: prefund the contract, create a new short position, wait for unlock, and then fuzz [id], [id, id], and mixed-order batches to ensure one inflated record cannot compound into protocol-scale loss.
  • Bound helper-path blast radius. Even if one lock record is mis-sized, per-position payout caps, queue-based releases, or manual review thresholds can stop one bad record from draining the full contract balance in one call.
  • Treat disclosure and patch operations as part of the control surface. If a live exploit path is found, user-facing warning, pause, and remediation sequencing should move as deliberately as the code fix.

Audit prompts

  • What exact evidence proves that one short position, and not ambient balance already in mirror_lock, earned the locked_amount being recorded right now?
  • Can unsolicited USTC sitting in the contract before lock_position_funds_hook() runs be attributed to the next position through current_balance - locked_funds or any similar balance-difference shortcut?
  • If I submit [position_idx, position_idx] to unlock_positions_funds(), where exactly does the second copy collapse to zero additional value?
  • Do batch unlock helpers and single-position unlock helpers consume the same entitlement object, or can one path still see a lock record as live after another path has already priced it into payout?
  • Is consumed-state mutation happening before payout aggregation, or does the contract first build a large unlock_amount and only later try to reason about uniqueness?
  • Could a single mis-sized lock record, once created, cash out more than a bounded per-position amount or more than one release window in a single transaction?
  • What monitoring would have flagged one position ID repeated hundreds of times or one newly opened short suddenly owns ~100,000 USTC of locked value as impossible state rather than business-as-usual activity?
  • If the team patches a replay path after exploitation has already begun, what exact process ensures users, integrators, and governance learn that the historical accounting surface was compromised?

Lessons that should already be standard

  • Ambient balance is not provenance. A contract seeing tokens in its wallet does not prove who earned them or which accounting object they belong to.
  • One-time exits need one-time state. If a lock record can appear twice in a batch and still add value twice, the protocol has not actually defined an exit entitlement strongly enough.
  • Small helper assumptions compose into large losses. Mirror did not need an exotic oracle break or governance capture; one misattributed balance delta plus one replayable unlock loop was enough.
  • Batch convenience code deserves treasury-grade review. Helper functions that just sum a vector often become the real custody boundary once they can move pooled funds.
  • Silent fixes are not neutral operations when exploitation may already be live. Security posture includes how quickly a protocol warns users that a previously trusted accounting surface was already broken.
  • The clean reviewer invariant is simple: one lock record should be attributable once, unlockable once, and economically worthless on every attempted second exercise.

Why this incident matters

  • Mirror is a strong exemplar for the corpus because it preserves a mechanically distinct failure mode: batch unlock replay, not oracle manipulation, not reentrancy, and not governance abuse.
  • It also shows how two seemingly modest issues can multiply: balance-difference accounting made one lock record huge, and missing idempotency let that record be cashed out repeatedly.
  • It is also a good accounting-composition case study: the most dangerous bug was not any single line, but the fact that one helper published an oversized entitlement and another helper later treated that entitlement as replay-safe.
  • For design review, it is a useful warning that one-time release invariants deserve the same rigor as borrow, liquidation, and swap logic.

Internal linkages

  • Core recurring patterns: duplicate-claim-idempotency-failure and balance-delta-provenance-failure.
  • Positive-design companion: exit-right-consumed-state-binding — the sharper question is what one lock entitlement unlock_positions_funds() should have been forced to consume exactly once before any batch payout was accumulated.
  • Positive-design companion: reserve-backed-claim-truth-security-object — useful when the sharper question is what exact receipt object should have proved that one short position, and not ambient USTC already sitting in mirror_lock, had earned the right to record that locked amount in the first place.
  • Adjacent accounting lens: balance-delta-provenance-failure — Mirror is the ambient-balance-attribution cousin: unsolicited USTC already sitting in mirror_lock was misassigned to the next short position because lock_position_funds_hook() treated a live contract-balance delta as proof of that position’s own locked proceeds.
  • Routing shorthand inside that sibling pattern: Penpie is the reward-accounting / semantic-source-confusion cousin, Akropolis is the clean one outer unwind remint cousin, Grim is the repeated checkpoint-reset remints vault cousin, and Origin Dollar is the explicit mint first, later rebasing reread of the same backing cousin.
  • Adjacent protocol-accounting lens: solvency-check-bypass.

Control surface

Graph View

Backlinks