Cork Protocol Exploit Analysis

On May 28, 2025, the Cork Protocol was exploited, resulting in a loss of approximately $12M.

Cork Protocol operates as an on-chain insurance platform that creates markets for hedging against depeg events. The protocol introduces a novel financial primitive called Depeg Swaps, which function similarly to Credit Default Swaps (CDS) in traditional finance.

Cork Market

Each Cork market consists of 4 primary token types:

• RA (Redemption Asset): The target asset that serves as the peg reference (e.g., ETH, USDC)

• PA (Pegged Asset): The asset being pegged to RA (e.g., stETH, USDe)

• DS (Depeg Swap): Tokens that grant the right to exchange PA for RA at a pegged rate in case of token depeg.

• CT (Cover Token): Holders of CT earn yield if no depeg occurs and absorb the risk if it does.

Peg Stability Module (PSM)

This is the Pegged Stability Module (PSM) - a core component of the Cork Protocol that manages price stability and asset conversion between different token types. Some of the important functions that are used in the attack are:

• depositPsm(): Users deposit RA and receive CT + DS tokens.

• returnRaWithCtDs(): Users can redeem RA back from CT + DS tokens.

Key information

• Attacker: https://etherscan.io/address/0xea6f30e360192bae715599e15e2f765b49e4da98

• Attack Tx: https://etherscan.io/tx/0xfd89cdd0be468a564dd525b222b728386d7c6780cf7b2f90d2b54493be09f64d

Exploit Analysis

In the normal flow, users can do the following steps with the Cork protocol:

• Create Cork market, which is a pair of PA and RA (e.g. stETH:ETH)

• Users deposit RA to the PSM, which mints DS and CT tokens

• Trading and Hedging

  • DS holders: can redeem PA for RA in case of depeg.

  • CT holders: earn yield if no depeg occurs.

• DS and CT tokens can be traded on AMM.

Back to the attack transaction, the attacker interacted with a legitimate market with the following tokens:

• RA: wstETH

• PA: weETH

• DS: weETH8DS-2

• CT: weETH8CT-2

At the very first step of the attack transaction, the attacker tried to swap a small amount of wstETH to get an exact amount of 3760.88 weETH8CT-2 tokens. Why did he do that?

After looking at the end of the attack transaction, we can see that the attacker tried to call the Psm.returnRaWithCtDs() function to get a large amount of 3760.88 wstETH (the RA tokens) by providing equal amounts of 3760.88 weETH8CT-2 and weETH8DS-2 tokens.

So, how did he get the remaining of 3760.88 weETH8DS-2 tokens?

After going through all the calls in the attack transaction, we notice that the RouterState contract contained approximately 3761.26 weETH8DS-2 tokens before the attack. This router state contract should not hold any DS tokens or CT tokens.

So, the entire exploit involved the attacker's attempt to extract that amount of DS tokens from the RouterState contract and combine it with the CT tokens to get the RA tokens back. The method used was sophisticated.

First, the attacker created a fake market using the weETH8DS-2 as the RA token. So the new market tokens would be like:

• RA: weETH8DS-2

• PA: wstETH

• DS: wstETH5DS-3

• CT: wstETH5CT-3

After creating the fake market and adding a small amount of liquidity to the Uniswap v4 pair (RA, CT) = (weETH8DS-2, wstETH5CT-3), the attacker triggered the CorkHook.beforeSwap() hook function. CorkHook is a hook contract for the Uniswap v4 pool for the fake market (RA, CT) pair.

Normally, the beforeSwap() function should only be called by the Uniswap v4 PoolManager contract. However, in this case, due to improper authorization of this function, the attacker was able to manipulate it and managed to extract the DS tokens inside the RouterState contract.

In these nested calls, we can see a flow that triggers the Psm.depositPsm() function. This function mistakenly minted 3761.26 (DS=wstETH5DS-3, CT=wstETH5CT-3) tokens for the attacker since it mistakenly thought the large amount of weETH8DS-2 in the RouterState contract was the attacker's RA token input.

By converting the minted DS and CT tokens back to RA, the attacker successfully drained all 3761.26 weETH8DS-2 tokens from the RouterState contract. The attack was completed.

Conclusion

The Cork Protocol exploit demonstrates a sophisticated attack that exploited multiple vulnerabilities in the protocol's design:

1. Improper Authorization: The CorkHook.beforeSwap() function lacked proper access controls, allowing direct manipulation by external actors instead of restricting access to the Uniswap v4 PoolManager.

2. Market Creation Abuse: The protocol allowed the creation of fake markets using existing DS tokens as RA tokens, enabling the manipulation of the deposit mechanism.

3. Logic Flaws in PSM: The depositPsm() function incorrectly interpreted tokens held in the RouterState contract as user deposits, leading to unauthorized token minting.

This attack highlights the importance of proper access controls, careful state management, and thorough testing of edge cases in DeFi protocols. The $12M loss could have been prevented through better validation of function callers, stricter controls on market creation parameters, and more robust accounting of token balances across different contracts in the protocol ecosystem.