Counterfeit Tokens Let Attacker Siphon $12M From Cork Protocol's wstETH Market

An attacker used self-deployed counterfeit tokens to manipulate how Cork Protocol calculated exchange rates, walking away with roughly $12 million drawn from the project's wstETH market. The scheme exploited fallback logic and missing validation checks rather than any cryptographic weakness, and by the time Cork's team had paused its contracts and issued a public statement, thousands of wstETH had already been converted and moved out.

How the morning unfolded

The incident began on the morning of Wednesday, May 28. Blockaid's monitoring system flagged the activity first, identifying that an attacker had deployed fake token contracts specifically to distort Cork Protocol's exchange-rate logic.

Cyvers' analysis traced the malicious contract to a deployer address that appeared to have been funded by a third-party service provider:

Funding wallet: 0x47713cb34fabd63b39d7c5c6f675dca39d22762b

MistTrack subsequently identified the exploiter's wallet and traced the associated gas fees to Swapuz, which the funding source described as a "service provider."

Cork co-founder Phil Fogel confirmed the incident publicly not long after, posting: "We are investigating a potential exploit on Cork Protocol and are pausing all contracts. We will report back with more information."

Cork's official account followed up shortly after, confirming that roughly $12 million in wstETH had been drained and converted into ETH. In total, the attacker's sequence broke down to: deploying a malicious contract, using fake tokens to distort the exchange-rate math, extracting 3,761 wstETH, and converting the proceeds to ETH.

Dissecting the exploit mechanism

Security researchers who reviewed the transactions described a straightforward, if carefully engineered, logic flaw rather than any advanced cryptographic attack.

Dedaub's assessment identified the underlying issue: Cork's exchange-rate computation included fallback logic that reverted to a default value under certain conditions, and the attacker manipulated this behavior by introducing fake tokens into the calculation.

BlockSec researcher Lei Wu narrowed the flaw down further, noting that the protocol failed to properly validate arguments passed into its CorkCall function — allowing an attacker to specify an arbitrary, fake paymentToken and profit from doing so.

William Li's write-up laid out the mechanics in more detail. Cork's CorkConfig contract let users create markets using arbitrary redemption assets (RA). The attacker abused this by designating DS tokens — legitimately belonging to an existing market — as the RA for a newly created, fake market.

Two design flaws made this possible: Cork's CorkHook contract exposed a beforeSwap function that any user could call without authorization checks, and that function accepted arbitrary custom hook data for CorkCall operations.

Per William Li's breakdown, the attacker set up a fake market in which a genuine DS token — borrowed from the original, legitimate market — was accepted as the base redemption asset without question. By depositing valid DS tokens from the legitimate market into this new fake market as RA, the attacker received corresponding DS and CT tokens in return.

Armed with these freshly minted tokens, the attacker then routed them back through Cork's legitimate PSM (Peg Stability Module) for redemption, extracting genuine wstETH in exchange for tokens that had cost nothing to produce. In effect, a protocol designed to insure against depegs was undone by a logic flaw that let the attacker manufacture collateral out of thin air.

Tracing the funds

The onchain trail from the exploit includes the following addresses and transactions:

Attacker address: 0xEA6f30e360192bae715599E15e2F765B49E4da98

Attacker's malicious callback contract: 0x9Af3dCE0813FD7428c47F57A39da2F6Dd7C9bb09

Victim contract: 0xccd90f6435dd78c4ecced1fa4db0d7242548a2a9

Exploit transaction 1: 0xfd89cdd0be468a564dd525b222b728386d7c6780cf7b2f90d2b54493be09f64d

Exploit transaction 2 (main theft): 0x605e653fb580a19f26dfa0a6f1366fac053044ac5004e1b10e7901b058150c50

A full transaction trace is available via MetaSleuth.

All 3,761 stolen wstETH were converted into ETH through a series of rapid transactions shortly after the theft. As of the most recent check, the funds remained held in the attacker's wallet, with the roughly $12 million in ETH not yet moved further.

Audits that missed the mark

Cork Protocol was not an unaudited project. According to its published audit history, the protocol had been reviewed by four separate firms — Quantstamp, Cantina, Sherlock, and Runtime Verification — and had run a bug bounty program through Cantina.

Despite that coverage, the vulnerable CorkHook contract fell outside the defined scope of at least three of the four audits — Sherlock, Runtime Verification, and Quantstamp. Cantina's exact scope boundaries are less clear, but the core input-validation flaw in the hook mechanism nonetheless passed through all four reviews undetected.

Sherlock stated directly: "The exploit involves the CorkHook contract which we didn't audit."

A breakdown published by Three Sigma quoted Runtime Verification explaining the constraints of its engagement: "This was a time-constrained verification effort, which means we had to make assumptions to handle the desired scope. Creating markets was a permissioned process at the time of verification. Verification of hook functions was out of scope, again due to time constraints."

Cantina's review, for its part, had specifically targeted input-validation issues and had already flagged multiple instances where Cork failed to verify tokens correctly — yet the flaw that was ultimately exploited still went unnoticed.

The takeaway

The exploit required no novel cryptography or zero-day discovery — just counterfeit token contracts and a hook function willing to process them without verification. Four independent security reviews, plus a live bug bounty, all missed the one component that mattered: a beforeSwap function in CorkHook that accepted unauthorized calls with unchecked custom data. For a protocol built to insure users against depegging events, the incident is a reminder that institutional backing and audit paperwork offer no protection when core functions don't verify what they're actually processing.