Back to Blog

How the Mirror Protocol got Exploited

Code Auditing
May 31, 2022

The Mirror Protocol was reported by @FatMan to have been exploited. The blog has a good report on this. In this short article, we will use the attack transaction to elaborate how this happened.

Disclaimer: This article is based on the public transaction and our understanding of the Mirror protocol and the Terra ecosystem. Please let us know if there is anything inaccurate. Any comments about this blog are welcome.

1 Attack

1.1 Preparation

The transaction is used to prepare the attacks.

STEP 1: In this transaction, the attacker first sent 100,000 USTC to the lock contract. This is not necessary to open a position, but it's critial for the attack.

STEP 2: After that, the attacker opened a position by depositing 10 USTC as the collateral and specifing the collateral_ratio as 2.5.

The short_params is specified so that the mint contract will sell the minted mAssets (i.e., mETH) and add the obtained USTC to the position's locked amount.

STEP 2.1: Let's walk through the transaction step by step. First, the function open_position will be invoked to open a short position whose ID is 43186.

STEP 2.2: Since the optional short_params is added, the contract will first mint 0.001208 mETH (based on the current price of ETH) and then sell it by swapping in the mETH-UST Pair.

STEP 2.3: The 0.001208 mETH will be swapped into 4.06582 USTC, the swapped USTC will be sent to the lock contract after removing the related fees (e.g., tax). That's because the opened position can only be unlocked after a certain time period.

STEP 2.4: Then lock_position_funds_hook will be invoked. In this function, position_locked_amount will be calculated by querying the current_balance and comparing the current_balance with the locked_funds.

However, as we have seen in Step 1, 100,000 USTC has been directly transferred into lock contract, the locked_amount will be around 100,004 USTC instead of 4 USTC.

STEP 2.5: Finally, increase_short_token will be invoked to record the sLP tokens.

Till this end, the attacker opened a position by sending 100,000 USTC to the lock contract directly and 10 USTC as collateral. The position's locked amount is around 100,004 USTC and can be unlocked after a time period. The attacker opened many such kinds of positions by sending 1,000 to 100,000 USTC.

1.2. Attack

The Mirror Protocol does not check the duplication of the position ID. In this case, the attacker can feed many duplicate position IDs to unlock the locked amount in one position over and over again.

The transaction is the attack transaction.  For instance, for the position ID 43186, the attacker duplicated 437 times.

Since the original contract code does not check the duplication, about 43.7M437 * 0.1M)USTC has been unlocked (in this single function call.)

Note that, the other positions have been unlocked with the same mechanism.

2. Bug Fix

The vulnerability was fixed in this commit.

Specifically, the unlockable_positions is a vector containing the position IDs to be unlocked. In the original code, there is no check on whether there are duplicate IDs in unlockable_positions. The patched code adds a check for the duplication of the position IDs.

3. Conclusion

As pointed out by @FatMan and other community members, this bug existed for a couple months and has been exploited in the wild. We believe that silently patching a vulnerability which has already been exploited in the wild is not a good security practice. Besides, we also think the high-profile DeFi projects should deploy some gate keepers to actively monitor the status of their apps and get alerted when something unusual happened.

Sign up for the latest updates
~$800K Lost: Hinkal Double-Spend | BlockSec Weekly
Security Insights

~$800K Lost: Hinkal Double-Spend | BlockSec Weekly

This weekly security report covers 1 notable incident from June 29 to July 5, 2026, with approximately $800K in total losses on Ethereum. The Hinkal shielded-pool protocol was drained through a double-spend attack that likely exploited a flaw in the legacy note format, allowing the attacker to derive multiple nullifiers from a single deposit. The report analyzes the probable circuit-level vulnerability, the attack flow, and broader implications for nullifier-based privacy protocols.

Newsletter - June 2026
Security Insights

Newsletter - June 2026

This monthly report covers the three largest security incidents in June 2026, totaling approximately $22M in confirmed losses. A sophisticated honeypot attack drained ~$15M from JaredFromSubway's MEV bot by exploiting unchecked token allowances. Two legacy Aztec rollup deployments lost ~$4.35M through proof-settlement boundary gaps. SecondFi's Ed25519 implementation flaw exposed wallet private keys, resulting in ~$2.4M drained from 374 wallets. All three incidents share a common pattern: security guarantees that appeared intact on the surface but were never actually enforced.

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly
Security Insights

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly

This weekly blockchain security report covers two notable incidents from June 22-28, 2026, with approximately $4.1M in confirmed losses across Ethereum and Cardano. The Taiko bridge exploit combined an exposed SGX enclave signing key with an incomplete attestation policy that failed to reject debug enclaves, allowing the attacker to register a malicious prover and forge L2 state proofs on Ethereum. The SecondFi wallet vulnerability stemmed from a cryptographic implementation flaw in Ed25519 nonce derivation that removed the secret input, enabling offline private key recovery from public Cardano transaction data.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit