May 28 2025 Exploit Post-Mortem
4 June 2025
15 minute read
Overview
At 11:39 UTC on 28 May 2025, an exploit of the Cork Beta extracted 3,761 wstETH from the wstETH:weETH Liquidity Vault. The team immediately paused all Cork contracts and the remaining Cork markets. The protocol development process was guided by multiple audits and a full protocol audit prior to launch. However, an attacker identified a complex attack vector that they exploited. A is presented below (section 9). At this juncture, the team’s top priorities are the safe redeployment of the active Cork markets to enable withdrawals, and the recovery of stolen funds. We will take time to analyze the lessons learned from this exploit to design better, stronger risk infrastructure that we strongly believe this market needs.
1. Incident Summary
Cork Protocol launched its public Beta on 4 March 2025, introducing a novel set of risk management primitives to the DeFi ecosystem. The protocol features a simple core primitive, the Peg Stability Module, that generates expiring markets. Through the deployment of a "Liquidity Vault", Cork performs a complex set of automations including rollovers, liquidations and liquidity management built around a Uniswap custom hook implementation, enabling functional market and liquidity permanence. Over the following 2.5 months, capital in the Liquidity Vaults across 5 markets grew to $32 million.
On 28 May 2025, an exploiter performed a highly sophisticated set of attacks targeting edge cases in the wstETH:weETH Liquidity Vault automation and Cork Hook contract. This extracted 3,761 wstETH from this vault by combining two distinct vectors:
- The first involved exploiting an input to the rollover pricing logic shortly before expiry of the market, which enabled the attacker to purchase 3,761 Cover Tokens with 0.000002 wstETH post-rollover.
- The second was a novel and sophisticated attack vector, in which the attacker deploys a malicious contract operating like a hook that through a complex sequence of events manages to bypass authorization checks in the Cork Hook and FlashSwapRouter. This enabled the attacker to withdraw 3,761 Depeg Swaps. Cork’s implementation leveraged an existing Uniswap V4 periphery contract. A later upstream code change added a new feature to make an explicit authorization check on behalf of developers. This feature was not in the version Cork used.
Using the Cover Tokens and Depeg Swaps, the attacker was able to withdraw the wstETH from the Peg Stability Module, effectively draining the funds that were previously in the Liquidity Vault.
The stolen 3,761 wstETH was then exchanged to ETH through 1inch’s exchange aggregator. The funds are currently being held at this address and have not been moved at the time of publishing.
Approximately $20 million of assets are still locked in Cork Liquidity Vaults which were not impacted by this exploit. All protocol functions have been paused pending contract upgrades that will resolve the identified attack vectors to enable fund withdrawals. The Cork team is fully committed to pursuing efforts to recover stolen funds and ensuring safe withdrawal of remaining locked funds in collaboration with auditing experts.
2. Timeline of Events (UTC)
28 May 2025
- 11:39 — Exploit occurs
- 11:43 — Cork team receives notification from Hypernative about the exploit
- 11:52 — Message is acknowledged and an internal response begins
- 12:08 — Cork team contacts all multisig signers to prepare for pause transactions on all contracts
- 12:17 — War Room is initiated together with representatives from Hypernative, Spearbit Labs, Quantstamp, Certora, and Cork’s key technical advisors.
- 12:17 — Pause transaction for Liquidity Vault is posted. Shortly thereafter a second transaction for pausing all protocol functions is posted. All signers are called on private numbers to sign their respective transactions.
- 12:31 — X initial public communication
- 12:33 — Transaction is executed to pause the Liquidity Vault
- 12:35 — Transaction is executed to pause all other protocol functions
- 12:36 — Proactive outreach and update to affected liquidity providers
- 13:21 — X official statement announcing the incident
- 13:22 — Engage and onboard tracing firm and incident response partner
- 13:24 — Initial hypothesis around attack pathway is established
- 13:33 — Telegram official statement
- 13:57 — Discord official statement
- 14:00 — Website notice that Cork markets are currently paused
- 14:29 — dApp notice that Cork markets are currently paused
- 14.34 — Transaction is executed to pause the ability to issue new markets
- 16:04 — Expanded attack pathway is drafted including fund flows
- 18:37 — Message sent on chain to exploiter to establish contact
- 19:23 — X official follow up statement announcing the pause of additional markets
29 May 2025
- 17:30 — Initial POC completed reproducing the attack including parameterization
- 20:11 — Linkedin official statement
- 20:11 — X official follow up statement
30 May 2025
- 19:18 — X official follow up statement
- 22:25 — Cork contacts Uniswap Foundation with reference to hook and responsible disclosure
31 May 2025
- 17:28 — X official follow up statement
3 June 2025
- 19:30 — Cork engaged with Uniswap Foundation to address responsible disclosure
4 June 2025
- 18:00 — Cork finalizes post mortem after consolidating feedback.
Going Forward
- A full POC of the exploit pathway was written and tested
- A pull request has been drafted for the critical vulnerability that enabled the Depeg Swap extraction, currently under review
- A strategy to unlock frozen funds from paused contracts is under review
- There is an active fund recovery effort underway including attempts to engage the exploiter
3. Immediate Response & Mitigation
Immediately after being made aware of the exploit by Hypernative, the team reported the incident to the Security Alliance, and opened a war room with key security researchers, auditors, and team members from Spearbit, Quantstamp, Hypernative, Hexagate, zeroShadow, Certora and others to triage the breach and report all malicious wallets, funds, and transactions as malicious actors to support tracing and remediation.
Cork took immediate action to pause Cork’s four other remaining markets, and funds remain unaffected (transaction details). The ability to create new Cork markets was also disabled (transaction details).
4. Communication & Stakeholder Updates
Cork issued live communications publicly throughout the incident across all its channels and has continued to do so daily on X.
All Cork Protocol liquidity providers were immediately contacted through private channels to be made aware of the incident and the pausing of unaffected markets. The team has remained in daily close contact with key investors, technical advisors, and all liquidity providers since the exploit. This includes working with the Uniswap Foundation to proactively address whether similar integrations may have been developed by other builders.
Our top priority remains the secure redeployment of the remaining protocol funds. We are maintaining ongoing coordination with liquidity providers and partners to share progress on fund recovery and get feedback and buy-in from stakeholders on a safe withdrawal plan.
5. Lessons Learned
Cork’s status as a net-new protocol drove our decision to launch as a controlled Beta with upgradeable contracts and strict vault caps to limit market size. To manage potential risks, the protocol completed four independent security audits, ran two full testnet simulations with hundreds of participants, operated a $100K bug-bounty program through Cantina, and applied formal verification to its core components.
September - Sherlock Audit - Link - Full protocol audit of initial codebase
October - Quantstamp Audit - Link - Core contracts of initial codebase: Liquidity Vault, Peg Stability Module
October - Runtime Verification Audit - Link - Full protocol audit of initial codebase and setting up formal verification invariants for all major functions/components in the system.
December - Cantina Audit - Link - FlashSwapRouter, AMM hook and Hedged Unit contract
March - Cantina Bug Bounty Program - Link - Total reward $100,000
May - Cantina Audit - (Audit report not yet published) - Full protocol audit
While Cork’s base primitive, the Peg Stability Module, functioned as intended, certain downstream components – specifically the Uniswap V4 hooks integration was missing key authorization checks and related automation modules exhibited edge-case behaviors. Those conditions provided a pathway for the exploit.
Upon close examination of the attack vector that enabled the extraction of Cover Tokens, we determined it was the Rollover automation which created the economic vulnerability that enabled the exploit. The approach taken relied on historical price information to set the price post rollover. Analysis indicates that, if only minimal trading activity occurs immediately prior to expiry, the volume-weighted, historical-price-based rollover calculation can be skewed by a single trade. In such low-volume conditions, that calculation yields an outsized risk premium, which in turn produces an abnormally low post-rollover price.
The Depeg Swap extraction exploit pathway emerged through a vulnerability in the Cork Hook beforeSwap logic, which was manipulated in a complex sequence of events which ultimately managed to bypass authorization checks on the hookData. The attacker contract was itself a Uniswap Hook, designed in a very precise manner to exploit a vulnerability in this beforeSwap implementation. At launch on 30 January 2025, Cork’s implementation leveraged an existing Uniswap V4 periphery contract. An upstream code change on 6 February 2025, added a new feature to make an explicit authorization check on behalf of developers. This feature was not in the version Cork used.
6. Action Plan & Preventive Measures
The team is looking at the path forward in two steps: what we aim to solve immediately, and how we proceed moving forward to digest these lessons into building a more resilient protocol, product and business.
Immediate Actions
The team is working with Spearbit Labs, Quantstamp and additional senior technical advisors to develop a safe remediation plan to redeploy remaining protocol funds onchain. The team’s current priority is for the fix to undergo reviews by multiple past auditors to safely reactivate Cork Protocol’s paused markets to enable fund withdrawals. In the spirit of responsible disclosure, the Cork team has been proactively communicating with the Uniswap Foundation team to consider how the publishing of this post mortem may affect other live hooks.
Medium to Long-term Actions
Looking ahead, the team plans to take the time to digest the lessons learned from other world-class protocols that have recovered from exploits, prioritize security, and internalize these insights into a more secure product and operational plan. We remain confident in the core protocol functionality and the simplicity and robustness of the Peg Stability Module. All contract vulnerabilities were downstream of the core protocol functionality, and isolated to our rollover mechanism and custom Uniswap V4 hook implementations, which introduced complex automations, authorization control issues, and inadvertently rare edge cases.
As we move forward with further development and re-engineering of the protocol, we intend to expand our suite of security tooling and practices including:
- Expanded use of formal verification
- Having multiple full protocol audits on the version of the full codebase in production
- Larger bug bounties promoted more widely
- Adopting more sophisticated code analysis tooling as part of the development process
- Enhanced security monitoring and alerting systems - the Hypernative system worked very well, and we plan to build our own implementation that expands the scope of suspicious activities we are to monitor for
- Develop and prepare code and scripts to be better prepared for exploits, including pause scripts
- Adopt chaos engineering and enhanced rollover simulations
7. Conclusion
This exploit was the result of complex edge-case interactions in automated rollover logic and authorization issues despite Cork’s prior audits and formal verification. While Cork’s base primitive, the Peg Stability Module, was safe and secure, vulnerabilities arose in developing complex functionality that leveraged edge-case economic protocol logic combined with integration of Uniswap’s novel hook code. These automations, combined with the need for the protocol to handle extreme edge cases (depegs where the value of a Pegged Asset could be 0), introduced complexity to the protocol which opens attack vectors.
Exploits are the worst part of building at the frontier of DeFi, but we are confident this incident will shape a more resilient version of Cork. We’re prioritizing fund recovery, withdrawal access, and trust rebuilding. We remain committed to our mission: building the risk infrastructure DeFi needs. Going forward, Cork will double down on security, simplicity, and transparency—setting a higher bar for itself and the ecosystem.
We thank our partners and community for their support – this is just the beginning for Cork and will continue building.
8. Acknowledgments
In no particular order.
• Hypernative and their entire team, with a special shout-out to Dan Caspi
• Gal
• @rshyper
• Tomer Niv
• Hector Velez
• Rodrigo Seira
• Christian Peters
• Spearbit Labs and their team
• Hari
• Windhustler/Josip
• Mike
• Alex
• Jim
• Akshay
• Isaac
• Pablo
• Hrishi
• Mario
• a16z and their team
• Sam Broner
• Matt Gleason
• Eddy Lazzarin
• ZeroShadow and their team
• @patJoel
• Certora and their team
• Mooly Sagiv
• Tomer Ganor
• Quantstamp and their team
• Don Ho
• Martinet Lee
• Ruben Koch
• Jennifer Wu
• Ibrahim Abouzied
• Hamed Mohammadi
• Security Alliance and Seal911
• Immunefi and their team
• Michael O'Keefe
• Adrien Hetman
• Uniswap Foundation and their team
• Devin Walsh
• Erin Koen
• Sauce
• We want to specifically acknowledge the support and help provided by our partners at Ether.Fi, Galaxy, and Dialectic.
9. Detailed Root Cause Analysis
This exploit involved two separate attack vectors which will be described in further detail below:
- A Cover Token extraction leveraging a rollover pricing exploit
- A Depeg Swap extraction leveraging a Cork Hook access control vulnerability to exploit the FlashSwapRouter logic
By combining these two attack vectors the attacker managed to drain the funds from the targeted Liquidity Vault shortly after the rollover. The exploit was executed through two sophisticated smart contracts which atomically executed a complex set of interactions in 2 transactions.
Exploiter Contract - 1 : Used for skewing risk premium & HIYA values
https://etherscan.io/address/0x6e54115de254805365c2d9c8a2eeb9b52e54668f
Exploiter Contract - 2 : Used for gaining access of CT+DS maliciously and convert them to RA
https://etherscan.io/address/0x9af3dce0813fd7428c47f57a39da2f6dd7c9bb09
Simplified Flowchart (Excalidraw)
Full Flowchart (Excalidraw)
Supporting Diagrams (Excalidraw)
- Cover Token Extraction: Rollover Pricing Exploit
The core of the Cover Token Extraction involves a pricing mechanism tied to an automation that intends to determine the price of Cover Tokens/Depeg Swaps on the next issuance. In particular, automation was introduced as a way to address expiring markets. Market expirations are disruptive to liquidity permanence and the user experience both for capital providers and hedgers. It was therefore the aspiration to create a design which enabled continuity of both liquidity and coverage, which is why this function exists.
The mechanism computes the risk premium on DS trades (buy and sell) in the past expiry. The risk premium is a measure of how much it costs annually to hold a Depeg Swap, or how much yield annualized a Cover Token holder receives. For example, if a Depeg Swap is trading for 0.02 with 1 year to expiry, this implies a risk premium of 2%. Now if the time to expiry declines and price remains constant, the risk premium increases. For example 6 months to expiry, the same 0.02 price is now a 4% risk premium.
As a market progresses towards expiry the CT should gain in value: the shorter timeframe remaining poses less possibilities for disaster to strike, consequently the price should rise to keep the risk premium constant. The protocol calculates the actual risk premium given at trades and derives a so-called Historical Implied Yield Average (HIYA) value from this. One can think about this as an approximation of the real underlying risk of a CT as implied by the market.
However, this presents an edge case for the formula close to expiry. For example a 0.02 price one hour before the expiry causes a 17,520% risk premium.
This skyrocketed risk premium overshadows all prior trades and becomes the dominating factor for the HIYA calculation. As the markets are rolled over the protocol logic assumes that the CT was overpriced as the risk premium was so much higher than anticipated. Consequently the new expiry is kicked off with a very low CT price to adjust for the inflated risk premium.
The method compute the risk premium is as follows:
 1 1.avif)
where:
• rT is the risk premium
• pT is the price of CT
• F is 1 (the future value of CT + DS, since in our case 1 CT + 1 DS can be redeemed for 1 RA)
• T is the time to maturity normalized between 1-0 (1: at initialization, 0: when expired)
The risk premium is inserted into a volume weighted Historical Implied Yield Average (HIYA) equation:
 1.avif)
Since discount is set to 0 on our case, the formula becomes:
 1.avif)
where:
• ∑ is the sum of all trades
• vT is the amount of DS traded during the term
• ∑vT is the cumulative volume during the term
The HIYA approach was selected because the design aimed to not be opinionated on market price and as such the mechanism enabled rollover pricing to be driven by historical risk premiums. In normal market conditions, this approach should work well.
Edgecase Description
Due to the exponential nature of T in rT equation (1/T), if the T is very small then the risk premium will get exponentially larger. This is why the exploiter purchased 2.5 DS approximately 19 minutes prior to expiry with this transaction which resulted in a 1,779.7% quadrillion risk premium. This is significantly exacerbated because there had been only minimal additional volume in this market prior to expiry and as a result the primary input to the HIYA calculation was this 1,779 quadrillion risk premium swap. Consequently, the initialization price post rollover was highly skewed. Because the Liquidity Vault automatically rolls over all its liquidity into the market initialized at this price, the exploiter could convert 0.0000029 wstETH to 3760.8813 CT with this transaction, effectively draining the entire supply of Cover Tokens from the AMM.
Detailed Reproduction of the Exploit Parameters
uint256 startTime = 1740655823;(Attacker buys approximately 2.5 DS)
uint256 maturityTime = 1748431824;
uint256 currentTime = 1748431547;
uint256 amount = 2558207817043893953;
uint256 raProvided = 3407593947121416;
uint256 decayDiscountInDays = 0;
 1.avif)
t = 0.0000356224234 (Roughly 19 minutes before the expiry)
We can also get the price of ct(pT) using above parameters
 1.avif)
 1.avif)
pT = 0.9986679761
If we plug all of it to risk premium (rT) equation:
 1.avif)
 1.avif)
rT = 17796669800000000 (1,779.7 quadrillion percent risk premium)
If we translate that into the HIYA used to determine the price:
 1.avif)
HIYA = 444916745000000 (This is what is being used to initialize the new market AMM)
To initialize the AMM, the Liquidity Vault uses:
 1.avif)
f = 1t = 1 rate = HIYA
 1.avif)
From that ratio the Liquidity Vault calculates the amount of CT:RA to deposit into AMM:
 1.avif)
 1.avif)
If we fetch the AMM reserves at the time of the exploit they are: RA : 0.000000000296488645CT : 3761.257491693078379366
All RA from the Liquidity Vault is converted into CT using that ratio and deposited into the AMM.
If we get the spot price of CT using (RA/CT)t (t is 1 due to recent initialization)
As a result the price in RA per CT is 0.000000000000078832397. This is why the exploiter could convert 0.0000029 wstETH to 3760.8813 CT.
Skewing risk-premium and HIYA values was performed through this transaction with help of the first exploiter contract deployed by the attacker.
- Depeg Swap Extraction: Cork Hook and Router Exploit
The Depeg Swap extraction involved a complex series of contract interactions that took place after the rollover of the wstETH:weETH market. At the core of the exploit was a flaw in the Cork Hook’s access control, which ultimately granted the attacker unauthorized access to privileged functions within the FlashSwapRouter.
Modern smart contract protocols like Uniswap V4 use hooks to enhance expressivity and modularity. Hooks act as extension points to the core protocol logic—similar to how plugins function in Web2 platforms like WordPress. Essentially, hooks enable the protocol’s core components to yield control to external smart contracts (the “hook” contract controlled by other parties) to inject custom logic. In the case of Uniswap V4, this mechanism allows builders to execute custom logic before a swap occurs. The hook functions using a Uniswap V4 periphery contract from 30 January 2024, which in a code commit on 6 February 2025 added a new feature to make an explicit authorization check on behalf of developers.
Set Up
As an initial step the attacker deposits 0.004 wstETH to the Peg Stability Module to get augCT + augDS. Hereinafter we will refer to the CT and DS tokens in the second expiry, of the legitimate Low-activity Cork Market, as augCT and augDS.
Thereafter, the attacker creates a new Cork market with the following parameters:
Redemption Asset: augDS
Pegged Asset: wstETH
We will refer to this market as the “Exploiter’s Proxy Market” where the tokens are pDS and pCT. Note, the attacker uses the augDS token (of the legitimate Low-Activity Cork Market) as the Redemption Asset. Market creation in Cork is permissionless - anyone can deploy their own markets with any parameters, which will start as an unlisted untrusted market until they apply to get listed on the Cork dApp, which is akin to many other DeFi protocols such as Morpho or Uniswap. The subsequent contracts surrounding the Peg Stability Module were adequately designed to deal with a market where a Cover Token or Depeg Swap from one market is used as a Redemption Asset in another. This design took into consideration use cases such as reinsurance and swap derivatives, where such a feature would be necessary.
However, the FlashSwapRouter could be subverted into transferring its unsold augDS token balance—originally belonging to a different market—into the exploiter’s proxy market. This was not due to a flaw in the router itself, but rather because the attacker exploited an access control vulnerability in the Cork Hook, which none of our audits flagged. Automation of the liquidation of Depeg Swaps generated through the rollover, requires mechanisms to programmatically enable the sale of such Depeg Swaps without being opinionated on price. This was solved through the deployment of a reserve in the FlashSwapRouter that was used to sell Depeg Swaps to fill a portion of Depeg Swap purchase orders. This was why the FlashSwapRouter held these augDS tokens. Also, there could have been stronger guidance from auditors on fundamental smart contract security principles—for example, flagging that FlashSwapRouter which was acting as a dispatcher should not hold balances (unless they are temporary).
In hindsight, executing this attack required an obscure or novel spoofing technique that leveraged the low-level nuances of how the Uniswap V4 protocol interacts with custom hooks, making it an unexpectedly viable attack vector as detailed below.
The Extraction
A key component of the extraction was the attacker’s contract, which was itself implemented as a Uniswap V4 Hook. For the exploit to succeed, it was critical that the Cork Hook did not revert. To achieve this, the attacker’s contract had to carefully manage execution flow—acting as a man-in-the-middle to simulate and patch deviations from a standard Uniswap V4 hook call sequence.
The attack began with the attacker’s contract invoking the unlock function on the PoolManager, passing benign data. This triggered a callback from the official Uniswap V4 PoolManager back into the unlockCallback function of the attacker’s contract, allowing it to establish an execution context that mimicked a legitimate Uniswap V4 environment. This context was sufficient to deceive the Cork Hook into proceeding without reverting, while allowing the attacker to replace callback data with its own malicious data.
Although the FlashSwapRouter includes validation logic within its CorkCall function—intended to verify that callbacks originate from the Cork Hook—the attacker bypassed these downstream checks by passing malicious parameters via the upstream Cork Hook’s beforeSwap function. These spoofed parameters included the original caller’s address, the RA amount supposedly provided by that caller, the CT amount ostensibly borrowed from the Uniswap V4 pool, and the market ID used for minting CT & DS (i.e.depositPsm). These values were then propagated into the CorkCall function of the FlashSwapRouter. The attacker was able to inject these forged values and successfully carry out the exploit by using the Cork Hook’s missing access control feature.
1 ➔ CALL Uniswap V4: Pool Manager.unlock calldata (data=(long param)) ▶ (result="")
2 ➔ CALL [Receiver] 0x9af3dce0813fd7428c47f57a39da2f6dd7c9bb09.unlockCallback calldata (data=(long param)) ▶ ("")
In the first call to beforeSwap function of the Cork Hook, the attacker deceives the FlashSwapRouter into thinking that the attacker provided DS-2 which is the RA of the Exploiter's Proxy Market, in an equal amount to the unsold DS-2 reserves in the Liquidity Vault which are held for sale in the FlashSwapRouter. Because the FlashSwapRouter already holds these DS-2 tokens and malicious parameters are passed and accepted because of the previously explained method of bypassing checks, the result is that the FlashSwapRouter takes the entire DS-2 reserves and deposits these into the Peg Stability Module of the Exploiter's Proxy Market to mint pDS and pCT. The pDS tokens are sent to the attacker since they pretended to purchase these in the call.
In the same invocation, the attacker also extracted the pCT tokens minted by the FlashSwapRouter. Within the router, there’s a built-in mechanism to refund any unused CT that was over-borrowed during the flash swap process. By manipulating the AMM pricing and tricking the router, the attacker ensured that the amount of pCT owed to the AMM was significantly less than the pCT amount minted. As a result, the router held excess pCT, which it then refunded to the caller address—maliciously set by the attacker in the hook callback data.As a cautionary note, “caller” is a parameter distinct from “sender”, introduced in the Cork Hooks architecture due to the use of the hook forwarder design pattern—adapted from other Uniswap V4 hook implementations. So with this malicious BeforeSwap call they tricked FlashSwap Router to send 3761 pCT and 3761 pDS to the attacker contract whilst the entire DS-2 reserve was deposited into the Exploiter's Proxy Market to mint these pCT and pDS tokens.
3 ➔ CALL CorkHook.beforeSwap calldata (sender=0x55b9_ERC1967Proxy, key=[currency0=wstETH5CT-3,currency1=weETH8DS-2, fee=0, tickSpacing=1, hooks=[Receiver]0x9af3dce0813fd7428c47f57a39da2f6dd7c9bb09], params=[zeroForOne=true, amountSpecified=100,000,000,000,000, sqrtPriceLimitX96=79,228,162,514,264,337,593,543,950,336], hookData=(long param) ▶ (0x575e24b4, delta=(long param), 0)
4 ➔ STATICCALL weETH8DS-2.decimals calldata () ▶ (18)
4 ➔ STATICCALL wstETH5CT-3.decimals calldata () ▶ (18)
4 ➔ STATICCALL weETH8DS-2.decimals calldata () ▶ (18)
4 ➔ STATICCALL wstETH5CT-3.decimals calldata () ▶ (18)
4 ➔ STATICCALL weETH8DS-2.decimals calldata () ▶ (18)
4 ➔ STATICCALL weETH8DS-2.decimals calldata () ▶ (18)
4 ➔ STATICCALL weETH8DS-2.decimals calldata () ▶ (18)
4 ➔ CALL Uniswap V4: Pool Manager.burn calldata (from=CorkHook, id=722,909,428,178,081,328,432,987,333,243,012,657,688,755,274,917, amount=100,000,000,000,000) ▶ ()
4 ➔ CALL (Reverted: execution reverted) 0x47e42e361a51ca3c68e60a0e19a3350dbeae3de1.forwardTokenUnchecked calldata (out=weETH8DS-2, amountOut=100,000,000,000,000) ▶ ()
4 ➔ STATICCALL wstETH5CT-3.decimals calldata () ▶ (18)
4 ➔ CALL Uniswap V4: Pool Manager.take calldata (currency=wstETH5CT-3, to=0x55b9_ERC1967Proxy, amount=110,987,905,101,460) ▶ ()
4 ➔ STATICCALL wstETH5CT-3.decimals calldata () ▶ (18)
4 ➔ CALL 0x55b9_ERC1967Proxy.CorkCall calldata (sender=0x55b9_ERC1967Proxy, data=(long param), paymentAmount=110,987,905,101,460, paymentToken=wstETH5CT-3, poolManager=Uniswap V4: Pool Manager) ▶
5 ➔ DELEGATECALL RouterState.CorkCall calldata (sender=0x55b9_ERC1967Proxy, data=(long param), paymentAmount=110,987,905,101,460, paymentToken=wstETH5CT-3, poolManager=Uniswap V4: Pool Manager) ▶
6 ➔ STATICCALL weETH8DS-2.allowance calldata (owner=0x55b9_ERC1967Proxy, spender=0xccd9_ERC1967Proxy) ▶ (0)
6 ➔ CALL weETH8DS-2.approve calldata (spender=0xccd9_ERC1967Proxy, amount=3,761,257,491,693,078,379,366) ▶ (true)
6 ➔ CALL 0xccd9_ERC1967Proxy.depositPsm calldata (id=0xc67cae5b35ca2fdf6564b38dc5332c88ad608d1c5b3595dd9ad781f5a340cb9d, amount=3,761,257,491,693,078,379,366) ▶ (received=3,761,257,491,693,078,379,366, _exchangeRate=1)
6 ➔ CALL wstETH5CT-3.transfer calldata (recipient=[Receiver]0x9af3dce0813fd7428c47f57a39da2f6dd7c9bb09, amount=3,761,257,380,705,173,277,906) ▶ (true)
6 ➔ CALL wstETH5DS-3.transfer calldata (recipient=[Receiver]0x9af3dce0813fd7428c47f57a39da2f6dd7c9bb09, amount=3,761,257,491,693,078,379,366) ▶ (true)
6 ➔ CALL wstETH5CT-3.transfer calldata (recipient=Uniswap V4: Pool Manager, amount=110,987,905,101,460) ▶ (true)
The Final Step
Now the attacker’s contract holds 3761 pCT and 3761 pDS which are used to call the returnRaWithCtDS function on the Peg Stability Module. As a result, the attacker contract receives 3761 DS-2.
3 ➔ CALL 0xccd9_ERC1967Proxy.returnRaWithCtDs Calldata ( id=0xc67cae5b35ca2fdf6564b38dc5332c88ad608d1c5b3595dd9ad781f5a340cb9d, amount=3,761,257,269,717,268,176,446) ▶ (ra=3,761,257,269,717,268,176,446)
4 ➔ DELEGATECALL ModuleCore.returnRaWithCtDs Calldata ( id=0xc67cae5b35ca2fdf6564b38dc5332c88ad608d1c5b3595dd9ad781f5a340cb9d, amount=3,761,257,269,717,268,176,446 ) ▶ (ra=3,761,257,269,717,268,176,446)
5 ➔ DELEGATECALL PsmLibrary.0x16ca3bc5 (raw data) ▶ (raw data)
5 ➔ EVENT 0xccd9_ERC1967Proxy.Cancelled Calldata ( Id=0xc67cae5b35ca2fdf6564b38dc5332c88ad608d1c5b3595dd9ad781f5a340cb9d, dsId=1, redeemer=[Receiver]0x9af3dce0813fd7428c47f57a39da2f6dd7c9bb09, raAmount=3,761,257,269,717,268,176,446, swapAmount=3,761,257,269,717,268,176,446)
As a result, the attacker now has 3,760.88 CT-2 received from the Cover Token extraction and 3,761.25 DS-2 received as described above. They then call the returnRaWithCtDS using these tokens to burn 3760 DS-2 and 3760 CT-2 to receive 3760 wstETH. As a result, they have drained the wstETH:weETH Liquidity Vault.
.png)