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
~$5.98M Lost: Aztec, Raydium & More | BlockSec Weekly
Security Insights

~$5.98M Lost: Aztec, Raydium & More | BlockSec Weekly

This weekly blockchain security report covers the period of June 8 to June 14, 2026, analyzing 4 notable incidents across Ethereum and Solana with total losses of approximately $5.98M. The highlighted events include Aztec Connect, where a missing input validation allowed the rollup's proof path and L1 settlement to reach inconsistent states, and Raydium, where a missing validation check on the legacy AMM v3 program allowed an attacker to manipulate the LP token redemption calculation and drain four pools. Both vulnerabilities had been live for years before exploitation. The report examines attack types including lack of input validation, integer overflow, and governance capture.

Zcash Orchard Soundness Bug Analysis | BlockSec Weekly
Security Insights

Zcash Orchard Soundness Bug Analysis | BlockSec Weekly

During the week of June 1, 2026, a critical soundness vulnerability was publicly disclosed in Zcash's Orchard shielded pool circuit, caused by a missing equality constraint in the halo2 ECC scalar multiplication gadget that could have enabled undetectable counterfeiting of ZEC within the Orchard pool through double-spending. The vulnerability, which existed for over four years since Orchard's activation in May 2022, was discovered by an AI-assisted security audit and patched through an emergency network upgrade (NU6.2). This single-event report covers the technical root cause (under-constrained ZK circuit relation), the AI-assisted discovery by researcher Taylor Hornby using Anthropic's Opus 4.8 model, the emergency response timeline, and the broader implications for the ZKP ecosystem.

Newsletter - May 2026
Security Insights

Newsletter - May 2026

In May 2026, the DeFi ecosystem experienced three major security incidents. Echo Protocol lost ~$76.7M due to an administrator key compromise that enabled unauthorized minting of unbacked eBTC on Monad, StablR suffered ~$12.8M from a multisig governance breach leading to unauthorized stablecoin issuance, and the Verus-Ethereum Bridge incurred ~$11.7M following a type-validation failure that allowed a crafted supplemental export to be misclassified as a valid primary export.

Best Security Auditor for Web3

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

BlockSec Audit