How a Critical Bug in Cork Protocol Led to a $12M Exploit: Full Hack Analysis

The Cork Protocol is an on-chain insurance platform that enables users to tokenize risks associated with the depeg events of stablecoins, liquid staking, and restaking assets.

On May 28, 2025, at 11:39:47 UTC, the protocol was compromised by an exploit, resulting in a loss of $12m. The issue is associated with the protocol logic. The analysis covers the hack details, how it happened, the attack flow, and the funds lost.
 

Protocol Background

To understand the core issue behind the hack, it is important to analyze what the protocol does. Most of this section comes from the protocol docs, which can be checked out here.

A Cork Protocol market is represented by two assets, one is a Redemption Asset (RA) and the other is a Pegged Asset (PA). There are other assets involved, which are Depeg Swap (DS) and Cover Token (CT). All of these assets and their use cases are abstracted in a Peg Stability Module (PSM). Here’s what each of these terms means:
 

Pegged Asset (PA): A PA is the asset that is pegged to some other asset value and tracks its price. Assets that come under this category are stETH, USDC, USDT, LBTC, and more, as these assets are pegged to certain different assets like ETH, BTC, US dollar.
 

Redemption Asset (RA): A RA is the asset on whose price a certain asset is pegged. So let’s say stETH is a Pegged Asset so the asset it is pegged to is ETH in this case. So, ETH becomes a Redemption Asset here.
 

Depeg Swaps (DS): DS can be compared with a Put Option (A financial instrument to hedge against a price decline in an asset). DS is a tokenized derivative instrument that gives the holder the right to sell the Pegged Asset for a Redemption Asset.
 

Cover Tokens (CT): CT can be compared with a Call Option (A financial instrument to gain from a price increase) and can be used to earn a fixed yield as long as their is no depeg event. They are on the opposite side of the trade from DS. They earn a risk premium from DS buyers.

Both DS and CT are liquid and are available to trade in secondary markets. The price of DS increases in case a Depeg event occurs, offsetting the potential loss from such an event, while the price of CT would reduce.
 

Peg Stability Module (PSM)

As mentioned above, PSM is the core mechanism of the protocol. Whenever a user deposits Redemption Asset (RA) to a pool, the pool mints two assets, which are Cover Token (CT) and Depeg Swap (DS).

At any time before expiry, a DS allows to get the RA to be obtained through PA and DS (PA + DS = RA). Moreover, CT combined with DS can also be converted to RA (CT + DS = RA) as the initial swap done through locking RA and minting CT and DS. Remember this as it unfolds to be the reason for the hack.
 

Hack Analysis and Its Impact

The root cause of the attack stems from the protocol allowing the usage of fake tokens and considering them real. The protocol had 4 different markets operating at the time of the exploit. The attack occurred on the Etherfi wstETH:weETH market or PSM.

Redemption Asset (RA): wstETH

Pegged Asset (PA): weETH

Depeg Swap (DS): weETH8DS-2 [root cause]

Cover Token (CT): weETH8CT-2

Initially attacker got hold of weETH8CT-2 tokens (CT tokens of wstETH:weETH market) using a flash swap from a Uniswap pool. The swap got them 3760.88 CT tokens. Remember from above how CT with DS can get RA at a 1:1 rate (CT + DS = RA). This is brewing for the same.

After that, the attacker proceeded with the creation of a new market or PSM with the following attributes:

Redemption Asset (RA): weETH8DS-2 [root cause - common asset between markets]

Pegged Asset (PA): wstETH

Depeg Swap (DS): wstETH5DS-3 [fake DS]

Cover Token (CT): wstETH5CT-3 [fake CT]

exchangeRateProvider is set as the attacker’s contract while calling initializeModuleCore. Exchange Rate Provider is the source of price and has Uniswap v4 hook logic. Cork allows for custom exchange rate providers.

The CT and DS of the above market can be seen in the following data when the attacker called getDeployedSwapAssets as mentioned above. CT and DS tokens are wstETH5CT-3 and wstETH5DS-3, respectively.

After successfully creating the new market, the attacker added the liquidity in RA (weETH8DS-2) for the amount of 0.002. This step is important to initialize the pool.

Once the Uniswap pool manager was unlocked, and attacker called beforeSwap with the fake currency0 parameter wstETH5CT-3 in this case.

The attacker markets calldata while calling unlockCallback on the pool manager, which contains RA, DS, and CT assets of their fake market.

Following this, corkCall is invoked in the real market with the paymentToken set to the CT token of the attacker’s fake market (wstETH5CT-3), which is called by the router contract at 0x55b9 (this contract holds DS tokens). At this point, this contract already has the CT token with it from the swap above.

The Corkcall function in the original contract didn’t have any checks on the callData provided and allowed the attacker to transfer weETH8DS-2 tokens to their market as RA. PSM does it work, and deposits an equivalent amount of DS and CT tokens in the pool. Remember, DS + CT = RA. That’s also true for the fake market, but in this case, the DS and CT tokens are not legit.

Now the router contract sends the funds to the attacker’s contract, this is still the DS and CT tokens minted by the Cork Contract, but now the pool got RA, weETH8DS-2.

Now, since the attacker got CT and DS tokens, they redeem them for RA, weETH8DS-2, using the PSM logic. The CT and DS tokens get burned.

The attacker also acquired weETH8CT-2 tokens at the beginning, combining them with the DS tokens weETH8DS-2 they got from above, they redeemed the RA token wstETH from the original market.

Once the attacker had 3760.88 wstETH, they converted it to 4530.59 ETH.

Root Cause Analysis

The CorkCall had lack of validation for the callback data. So the attacker called it with custom callbackData when the pool got unlocked with their malicious market, which gave the pool allowance to spend 3761.25 weETH8DS-2 tokens from the router contract at 0x55b9. This contract holds the DS tokens.

There was a lack of validation, and an attacker could use a DS from any existing market as an RA in a new market, which fails the protocol logic.
 

Attack Flow

Fund Flow Post Attack

The attacker didn’t move the funds yet, which were swapped to ETH.

Cork Protocol message to the signer, there is no respond yet.

Tx: https://etherscan.io/tx/0xc54284c8cd62687b1271b485737f9751cbc92ca307d37f5ca7cc76516c329b86
 

Relevant Addresses and Transactions

Attacker Wallet: 0xEA6f30e360192bae715599E15e2F765B49E4da98

Attacker Contract: 0x9Af3dCE0813FD7428c47F57A39da2F6Dd7C9bb09

Exploit tx: https://etherscan.io/tx/0xfd89cdd0be468a564dd525b222b728386d7c6780cf7b2f90d2b54493be09f64d

Attacker CT token: 0x51f70fe94e7ccd9f2efe45a4f2ea3a7ae0c62f8c

Attacker DS token: 0x1d2724ca345e1889cecddefa5f8f83666a442c86

Victim Contract: 0xCCd90F6435dd78C4ECCED1FA4db0D7242548a2a9

Router Contract: 0x55B90B37416DC0Bd936045A8110d1aF3B6Bf0fc3

Uniswap v4 pool manager: 0x000000000004444c5dc75cb358380d2e3de08a90
 

How the Hack Could Have Been Prevented?

The root cause of the attack is the lack of validation and the implementation of the logic. The protocol should not have allowed any existing DS tokens to be used as an RA in a new market as the protocol logic itself implements that the RA is redeemable with CT and DS tokens.

The validation of the callback data where attacker attested their malicious market in the CorkCall function is missing. The protocol's permissionless nature to create markets didn’t have any checks in place that led to such exploitation.

The protocol uses a complex methodology is an insurance protocol having a lot of dependency on multiple functions and tokens. The design of PSM itself is complex, the developers should have considered different edge cases while designing the smart contracts.

Moreover, the protocol went through a series of private audits and public contests, which wasn’t able to catch the issue.
 

Conclusion

Cork Protocol, an insurance protocol on Ethereum, got exploited due to a lack of validation and checks in the protocol logic. The protocol allowed the use of legit market assets into the fake market which created a discrepancy in the logic and allowed the attacker to siphon real funds through their malicious market. Moreover, the protocol didn’t perform proper checks on the user-provided callback data.

At QuillAudits, we perform checks like these and follow a multi-layered auditing framework, focusing on different edge cases possible and ensuring that exploits like these can be avoided.