## Merge 01 — 15 DeFi Exploit Incident Notes (2025–2026)

Combined from 15 item results. Each section preserves the incident's reported loss, root cause,
general pattern, the check that would have caught it before deployment, and every source URL.

No incident note is missing. All 15 items produced substantive findings with source citations.
Where sources disagree on a fact, the disagreement is recorded.

---

## 1. zkLend (February 2025, Starknet)

**What happened.** On February 11–12, 2025, the Starknet lending protocol zkLend was exploited for
approximately $9.5 million (~$9.57M per rekt.news and Halborn, ~$10M per BlockSec, ~$9.5M per
SolidityScan and Verichains). The attacker bridged ~1,801 ETH to Ethereum L1 and attempted to
launder ~706.4 ETH through Railgun, which rejected the funds. On-chain evidence linked the attacker
to the July 2023 EraLend exploit. A 10% white-hat bounty went unanswered.

**Root cause.** A rounding/precision-loss bug in the zToken contract's `burn` (withdraw) path.
Three conditions combined: (1) accepting deposits into empty markets, (2) treating flash-loan
over-repayments as donations that inflated the global `lending_accumulator`, and (3) integer
division with downward rounding in the scaled-balance calculation. The attacker deposited 1 wei
into an empty market, inflated the accumulator via flash loans, then withdrew far more than the
single share unit represented. Repeating this cycle drained the pool.

**Pattern.** Rounding/precision loss in accumulator-based lending math. The vulnerable shape:
`scaledDown = amount * SCALE / accumulator` using truncating integer division. When `accumulator`
is enormous, `scaledDown` equals 1 (passing the non-zero guard) while the user receives a
withdrawal far larger than their shares. This is a pure math bug, not a reentrancy, oracle, or
access-control issue.

**Check.** (1) Fuzz test with extreme accumulator values: invariant that a user's withdrawable
amount never exceeds deposits plus interest. (2) Review rule: every integer division in
share-to-asset conversion must round against the caller (ceil on withdrawal, floor on deposit).

**Sources.**
- https://rekt.news/zklend-rekt/
- https://blocksec.com/zh/blog/zklend
- https://www.halborn.com/blog/post/explained-the-zklend-hack-february-2025
- https://blog.solidityscan.com/zklend-hack-analysis/
- https://blog.verichains.io/p/zklend-finance-incident-analysis

---

## 2. Four.meme (February & March 2025, BNB Chain)

**What happened.** Four.meme was exploited twice at its graduation/migration step.
Feb 11, 2025: ~$183,000 taken (sources disagree: ~$15,000 for a single demonstrated token per one
source, ~$183k per PeckShield, Verichains, and others). Mar 18, 2025: second migration attack for
~$120,000–$130,000 (~$174k per Decrypt). In both cases, the attacker pre-initialized the
deterministic PancakeSwap V3 pool at a manipulated price before the launchpad's `addLiquidity`
call, causing the LP mint to deposit the full BNB against nearly zero meme tokens. Launch function
was paused and resumed each time; LP launches were suspended during investigation.

**Root cause.** On-chain logic flaws, not a stolen key. February: `createAndInitializePoolIfNecessary`
no-ops when the pool already exists, so the launch reused an attacker-set price; the LP mint then
deposited 1 wei of meme against ~23.5 BNB. March: the attacker used the pre-launch buy path to
move untransferable tokens to the not-yet-created pair address, created the pool, and fixed the
price. Both exploits: the migration trusted attacker-controllable external pool state and minted
with zero slippage guards.

**Pattern.** Unvalidated external state — price/oracle manipulation of the launch pool
(pool-init front-run) plus unchecked slippage on the LP mint.

**Check.** (1) Post-migration price assertion: after `createAndInitializePoolIfNecessary`, verify
`pool.slot0().sqrtPriceX96` equals the intended price. (2) Invariant/fuzz test: the graduation
mint must consume the intended liquidity; a 1-wei outcome fails loudly. (3) Use non-zero
`amount0Min`/`amount1Min` slippage guards. (4) Transfer-restriction review: pre-launch tokens must
be untransferable to the future pair/LP address.

**Sources.**
- https://www.chaincatcher.com/en/article/2167296
- https://blog.verichains.io/p/fourmeme-hack-analysis
- https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2025-02/FourMeme_exp.sol
- https://www.coinspect.com/learn-evm-attacks/cases/four-meme/
- https://crypto.training/hacks/2025-02-FourMeme/
- https://cointelegraph.com/news/bnb-chain-memecoin-fourmeme-hacked-183k
- https://crypto.news/four-meme-hit-by-malicious-attack-leading-to-183k-loss/
- https://protos.com/binances-memecoin-platform-loses-almost-200k-in-hack/
- https://x.com/four_meme_/status/1889198796695044138
- https://x.com/PeckShieldAlert/status/1889210001220423765
- https://www.quillaudits.com/blog/hack-analysis/four-meme-attack-analysis
- https://www.chaincatcher.com/en/article/2173046
- https://x.com/SlowMist_Team/status/1901845958767657072
- https://cointelegraph.com/news/four-meme-resumes-operation-sandwich-exploit
- https://cryptoslate.com/four-meme-handles-second-exploit-in-months-reinstates-launch-service/
- https://cointab.com/hackers-four-meme-token-steals-130k-in-bnb/
- https://x.com/four_meme_/status/1901857145995587851
- https://decrypt.co/310388/meme-coin-launchpad-four-meme-falls-victim-to-another-exploit
- https://smartcontractshacking.com/hacks/four-meme-hack-2025

---

## 3. Bybit (February 2025, Ethereum)

**What happened.** On February 21, 2025, Bybit's Ethereum cold wallet (a Safe multisig) was
drained for approximately $1.43 billion: 401,346 ETH (~$1.11B), 90,375 stETH (~$250.8M), 15,000
cmETH (~$44M), and 8,000 mETH (~$23.5M). The Lazarus Group (North Korea) was identified as the
attacker.

**Root cause.** Not a smart-contract bug. A Safe{Wallet} developer's MacOS workstation was
compromised via social engineering (a malicious Docker project). The attackers hijacked AWS session
tokens, injected malicious JavaScript into the Safe{Wallet} frontend, and when Bybit signers
approved what appeared to be a routine cold-to-warm transfer, the JS substituted a `delegatecall`
to an attacker-controlled contract that upgraded the Safe's implementation with a `sweepERC20()`
backdoor.

**Pattern.** Key/signer compromise via frontend supply-chain attack / blind signing. The signing
UI displayed one transaction while the on-chain calldata executed another.

**Check.** (1) Operational: every multisig signer must decode and inspect raw transaction calldata
on a separate, air-gapped device before signing. (2) Frontend integrity monitoring: a canary script
that loads the signing frontend, simulates a transaction, and verifies calldata matches the
displayed intent, alerting on any divergence.

**Sources.**
- https://rekt.news/bybit-rekt/
- https://rekt.news/not-so-safe/
- https://x.com/Bybit_Official/status/1892965292931702929
- https://x.com/benbybit/status/1892963530422505586
- https://x.com/safe/status/1897663514975649938
- https://x.com/SlowMist_Team/status/1892963250385592345
- https://x.com/benbybit/status/1894768736084885929

Note: CertiK, Halborn, Verichains, and QuillAudits analyses were unreachable during research; only
their X alerts were readable.

---

## 4. Infini (February 2025, Ethereum)

**What happened.** On February 24, 2025, approximately $49.5 million in USDC was drained from
Infini's Earn vault (some sources round to ~$50M). The attacker swapped USDC to DAI, then to about
17,696 ETH.

**Root cause.** Not a smart-contract logic bug; compromised privileged access. The vault was an
unverified contract with a special role (`0x8e0b` per QuillAudits/Decrypt; `0x8e9b` per rekt.news
— a factual disagreement on the role hex) that could withdraw all funds. Sources disagree on the
mechanism: QuillAudits/Decrypt describe a private key breach of the privileged account; Halborn/rekt
describe a rogue former developer who retained the role and waited 114 days. All agree funds were
moved through an admin/withdraw privilege rather than by breaking contract logic.

**Pattern.** Key/signer compromise combined with excessive, retained privileged access (centralized
admin authority). A single EOA held a withdraw-to-reserve role with no cap, no timelock, and no
revocation after handover, and the contract was unverified.

**Check.** (1) Pre-launch role inventory: assert no plain EOA holds any privileged role; every
holder must be a multisig or timelock. Revoke deployer roles immediately after launch. (2) Invariant
test on the withdraw path: no single signer can reduce vault token balance; fuzz the withdraw entry
point with arbitrary `msg.sender` and assert every non-multisig caller reverts.

**Sources.**
- https://rekt.news/infini-rekt/
- https://www.halborn.com/blog/post/explained-the-infini-hack-february-2025
- https://www.quillaudits.com/blog/hack-analysis/how-infini-lost-49-million-in-a-defi-hack
- https://decrypt.co/307513/crypto-neo-bank-infini-50-million-exploit
- https://x.com/lookonchain/status/1893869666717585756
- https://x.com/Infini_Global/status/1893973307596435871
- https://x.com/Christianeth/status/1893885666557411712

---

## 5. 1inch Fusion v1 Resolver (March 2025, Ethereum)

**What happened.** On March 5, 2025, an attacker exploited an integer-underflow vulnerability in
the obsolete 1inch Fusion v1 resolver settlement contracts, draining approximately $5 million (~2.4M
USDC and 1,276 WETH) from market makers. The attacker returned most funds after on-chain
negotiations, keeping ~$450,000 (~10%) as an informal bounty. Net loss per DeFiHackLabs: $4.5M.

**Root cause.** Integer underflow in Yul assembly in `_settleOrder`. When copying calldata and
appending suffix data, supplying `interactionLength = 0xffff...fe00` (effectively -512) caused the
write pointer to underflow, landing at attacker-controlled calldata. A second overflow made the
patched interaction length appear clean. The redirect hijacked the resolver, transferring victim
funds to the attacker. Nine audit teams had reviewed the codebase over two years without finding
the bug, introduced when the function was refactored from Solidity to Yul in November 2022.

**Pattern.** Integer overflow/underflow leading to calldata/memory corruption in inline assembly
(Yul). Solidity 0.8.x safe-math does not apply inside assembly.

**Check.** (1) Fuzz/invariant test: supply `_settleOrder` with arbitrary `interactionLength` values
and assert the computed write offset never underflows (`add(add(ptr, interactionOffset),
interactionLength) >= add(ptr, interactionOffset)`). (2) Review rule: every Yul assembly block
using a user-supplied unsigned integer in pointer arithmetic must explicitly validate it against
overflow before the addition.

**Sources.**
- https://rekt.news/1inch-rekt/
- https://rekt.news/leaderboard/
- https://blog.decurity.io/yul-calldata-corruption-1inch-postmortem-a7ea7a53bfd9
- https://x.com/DecurityHQ/status/1898069385199153610
- https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/past/2025/README.md
- https://github.com/1inch/fusion-protocol/blob/934a8e7db4b98258c4c734566e8fcbc15b818ab5/contracts/Settlement.sol

---

## 6. SIR.trading (March 2025, Ethereum)

**What happened.** On March 30, 2025, SIR.trading's Ethereum Vault was drained for $355,000 (its
entire TVL; sources agree). Assets taken: 17,814.86 USDC, 1.4085 WBTC, and 119.871 WETH. Blockscope
reports "over $360,000" but has an internal date discrepancy (labels events January 30, 2025);
March 30 is supported by the project and other analyses.

**Root cause.** Smart-contract authorization bug involving EIP-1153 transient storage. Transient
slot 1 was used to authenticate the Uniswap V3 callback caller, but was also reused to store a
minted amount. Because transient storage survives function returns until the transaction ends, a
later callback interpreted the numeric amount as an authorized caller address. An attacker-controlled
amount could masquerade as an address and bypass authorization.

**Pattern.** Callback validation failure through transient-storage aliasing and stale authorization
state. One slot held an `expectedPool` address; after the callback it held a `mintedAmount`; a
second callback still treated it as authority. Data crossed a trust boundary because its meaning
changed without invalidating its authorization role.

**Check.** (1) Same-transaction regression/invariant test: complete a legitimate mint, then attempt
another callback before the transaction ends, varying amounts and unauthorized callers. Assert only
the original swap's pool can trigger a callback. (2) Transient-slot lifecycle review: enumerate
every `TSTORE`/`TLOAD`, reject sharing a callback-authority slot with a numeric return value, use
distinct slots, and clear authority on swap completion.

**Sources.**
- https://docs.sir.trading/protocol-overview/user-risks/exploit-and-relaunch.md
- https://blog.verichains.io/p/eip-1153-transient-storage-save-gas
- https://slowmist.medium.com/fatal-residue-an-on-chain-heist-triggered-by-transient-storage-10909e4a255a
- https://research.blockscope.co/sir-protocol-exploit
- https://rekt.news/sirtrading-rekt

---

## 7. Abracadabra (March 2025, Arbitrum)

**What happened.** On March 25, 2025 (March 26 per rekt.news publication date), Abracadabra's GMX
v2 cauldrons were exploited for approximately $13 million (~6,262 ETH). This was the second exploit
of Abracadabra, following a $6.5M theft in January 2024. The attacker used flash loans to exploit
a liquidation loophole, draining MIM and other assets from the cauldrons.

**Root cause.** Smart-contract logic bug: after a position was liquidated, the cauldron's internal
accounting failed to properly invalidate the collateral record. The attacker borrowed against these
already-liquidated "phantom collateral" positions by manipulating the liquidation-and-borrow flow
within a single atomic transaction.

**Pattern.** Liquidation state-accounting desynchronization / stale state after liquidation. A
liquidated position's fields were zeroed but the record persisted; the borrow path did not re-check
that `collateral > 0`.

**Check.** (1) Invariant test: after every `liquidate()` call, a liquidated position cannot pass
`borrow()` and return a non-zero amount. (2) Review rule: every state-mutating function that empties
a record must set an explicit `isActive` flag, and every function reading that record must revert
if the flag is false.

**Sources.**
- https://rekt.news/ (March 26, 2025 snapshot, via web.archive.org)
- https://www.web3isgoinggreat.com/?id=abracadabra-exploit-2 (via web.archive.org)
- https://hacked.slowmist.io/ (via web.archive.org)
- https://defillama.com/hacks (via web.archive.org)

Note: Abracadabra's own post-mortem was not capturable (Vue.js SPA). No separate analyses from
BlockSec, CertiK, Halborn, Verichains, or QuillAudits specific to this exploit were found.

---

## 8. KiloEx (April 2025, multi-chain)

**What happened.** On April 14, 2025 (labeled April 15 by some sources), KiloEx's perps DEX was
exploited across Base, BNB Chain, opBNB, Taiko, Manta, and B2. Loss estimates disagree: ~$7.49M
(rekt.news), ~$8.44M (SlowMist/Blockscope), ~$7.4M (SolidityScan), ~$7M (crypto.news). All funds
were recovered under a 10% white-hat bounty after ~3.5 days.

**Root cause.** Smart-contract access-control flaw. KiloEx's `TrustedForwarder` inherited
OpenZeppelin's `MinimalForwarderUpgradeable` but never overrode its `execute()` method, leaving
that meta-transaction entry point publicly callable. Downstream, `PositionKeeper` only checked
`msg.sender == trustedForwarder` without verifying that the signer was an authorized Keeper. The
attacker set prices low, opened a leveraged long, set them high, and closed it in one transaction.

**Pattern.** Missing access control / unvalidated input in a meta-transaction forwarder flow.
Inheriting a meta-tx base without overriding or guarding `execute()` creates a permissionless relay.

**Check.** (1) Invariant/fuzz test: no state-changing path reaches `setPrices()` or `PositionKeeper`
privileged setters unless the recovered signer is a whitelisted Keeper. (2) Review rule: when
inheriting a meta-tx base, require an explicit `onlyOwner`/`AccessControl` guard on `execute()`;
never let `msg.sender == forwarder` alone substitute for checking the recovered signer against an
allow-list.

**Sources.**
- https://rekt.news/kiloex-rekt
- https://slowmist.medium.com/slowmist-assists-kiloex-in-recovering-all-stolen-funds-incident-recap-273d10f6d466
- https://medium.com/@KiloEx/kiloex-security-incident-root-cause-analysis-post-mortem-3d899caac08c
- https://blog.solidityscan.com/kiloex-vault-hack-analysis-123a086ccae3/
- https://research.blockscope.co/kiloex-exploit-analysis
- https://crypto.news/kiloex-reveals-7m-smart-contract-exploit-in-post-mortem-report/
- https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts-upgradeable/v4.8.3/contracts/metatx/MinimalForwarderUpgradeable.sol

Note: No KiloEx-specific public analysis from BlockSec, Halborn, Verichains, or CertiK was found.

---

## 9. ZKsync Airdrop (April 2025, ZKsync Era)

**What happened.** On April 15, 2025, an attacker compromised an admin account tied to ZKsync
Era's airdrop distribution contracts and minted approximately 111 million unclaimed ZK tokens,
worth roughly $5 million. The ZK token price dropped 15–20%. The attacker later accepted a 10%
bounty and returned 90% of the assets (~$5.7M including recovered ETH). No user funds or core
protocol contracts were compromised.

**Root cause.** A compromised admin private key, not a smart-contract vulnerability. Address
`0x84282...58DA7D` held privileged access to three airdrop distribution contracts and called
`sweepUnclaimed()` — a function left accessible post-airdrop — to mint unclaimed allocation directly
to the attacker's wallet. The function served a legitimate purpose but was callable at any time by
a single key, with no timelock or multisig requirement.

**Pattern.** Key/signer compromise combined with unvalidated privileged function access on
post-airdrop contracts. A single-key `onlyAdmin` mint path survived the claim window with no
timelock, multi-signature requirement, or cleanup.

**Check.** (1) Review rule: after an airdrop claim window closes, audit every privileged function
on distribution contracts; any mint/transfer/burn path must be timelock-gated, multisig-gated, or
permanently disabled. (2) Operational: require multi-signature approval for any call to
`sweepUnclaimed` or equivalent.

**Sources.**
- https://cointelegraph.com/news/zksync-hacker-steals-5m-airdrop-tokens
- https://cointelegraph.com/news/zk-sync-recovers-5-million-stolen-tokens-hacker-accepts-bounty
- https://www.theblock.co/post/350839/zksync-discloses-5-million-attack-compromised-airdrop-contract-admin-account
- https://coinmarketcap.com/academy/article/zksync-confirms-dollar5-million-token-theft-after-admin-wallet-compromised-zk-price-falls-20percent
- https://crypto.news/zk-token-crashes-after-5m-airdrop-exploit-confirmed-by-zksync/
- https://crypto.news/zksync-recovers-funds-stolen-in-5m-exploit-after-hacker-claims-bounty/
- https://www.halborn.com/blog/post/explained-the-zksync-hack-april-2025
- https://web3exploit.com/case-research/zksync-2025-airdrop-admin-compromise-case-research
- https://zksync.mirror.xyz/W5vPDZqEqf2NuwQ5x7SyFnIxqqpE1szAFD69iaaBFnI
- https://blockonomi.com/zksync-recovers-5-7-million-in-stolen-crypto-after-bounty-negotiation/
- https://blockchainreporter.net/zksync-hit-by-5-million-exploit-from-compromised-airdrop-admin-account/

---

## 10. Loopscale (April 2025, Solana)

**What happened.** On April 26, 2025, Loopscale's USDC/SOL Genesis Vaults were exploited for
5,726,724.97 USDC and 1,211.4 SOL (~$5.8M, roughly 12% of TVL). All funds were returned by April 29.

**Root cause.** Missing account/program-identity validation on a price source. Loopscale valued
RateX principal-token (PT) collateral by CPI-calling a program's `get_pt_price`. Program-ID
validation existed for some RateX PT tokens but was not extended to non-Loop borrows collateralized
by RateX tokens. The attacker deployed an impostor program that returned an artificially inflated
PT exchange rate, passing health checks and enabling undercollateralized loans. A prior OShield
audit (Jan–Feb 2025) had flagged the missing `oracle_account` validation as critical; the March
upgrade introduced a new path without that check. Some sources (CryptoNinjas, AuditOne) described
flash-loan/pool-manipulation instead, conflicting with the post-mortem; no evidence for that version
was found.

**Pattern.** Unvalidated input — missing account/program-identity validation on a price source
(oracle spoofing via a substituted program, not a manipulated price feed).

**Check.** (1) Invariant test with a hostile source: every instruction that reads a collateral
price must use a program derived from the on-chain registry — fuzz `remaining_accounts` with
attacker-owned accounts and executables, requiring the instruction to fail. (2) Review rule: route
all collateral pricing through one `verify_price_source(program_id, market)` helper; require any
PR touching a collateral integration to prove the check sits on every path. No unaudited code ships.

**Sources.**
- https://blog.loopscale.com/posts/postmortem
- https://rekt.news/loopscale-rekt
- https://www.halborn.com/blog/post/explained-the-loopscale-hack-april-2025
- https://www.quillaudits.com/blog/hack-analysis/loopscale-lost-5-8m-in-price-manipulation-attack
- https://github.com/oshieldio/Publications/blob/main/Loopscale/loopscale-v1.md
- https://auditone.io/blog-posts/the-loopscale-incident-a-case-study-in-oracle-exploitation
- https://helius.dev/blog/solana-hacks
- https://www.theblock.co/news/ecosystems/2025-04-26-solana-defi-protocol-loopscale-hit-with-5-8-million-exploit-two-weeks-after-launch-352083

---

## 11. MobiusDAO (May 2025, BNB Chain)

**What happened.** On May 11, 2025, MobiusDAO's MBU token was exploited for approximately $2.15
million, three days after launch. The attacker deposited 0.001 WBNB (~$0.67) and minted 9.73
quadrillion MBU tokens through a decimal-handling bug, then dumped them on PancakeSwap and routed
proceeds through Tornado Cash in 21 transfers of 100 BNB each. The code was not open-source and had
no public audit.

**Root cause.** A double multiplication of decimals in the deposit/mint function.
`getBNBPriceInUSDT` returned an 18-decimal value (~$656 represented as `656 * 10^18`), but the
deposit function multiplied this by `10^18` again before computing the mint amount, inflating the
deposited value by 10^18. No mint cap and no validation of the resulting token quantity.

**Pattern.** Precision/decimal-scaling error (missing decimal-place validation).

**Check.** (1) Unit test with real input values: deposit a known WBNB amount and assert the minted
amount equals the expected value within a 1% tolerance. (2) Invariant: `mintedAmount <=
(depositedAmount * bnbPrice) / 1e18 * (1 + maxSlippage)` for any deposit size.

**Sources.**
- https://web.archive.org/web/20250514000000/https://rekt.news/mobiusdao-rekt/ (primary; quotes
  Quill Audits, Blockaid, Cyvers, AstraSec, and CertiK analyses)

Note: The Quill Audits blog post was not archived independently. The project issued a statement
blaming "BSC Byzantine consensus mechanism" rather than publishing a technical post-mortem.

---

## 12. Cetus Protocol (May 2025, Sui)

**What happened.** On May 22, 2025, Cetus Protocol's CLMM pools on Sui were drained. Attackers
swapped a tiny deposit into an enormous liquidity position, then withdrew it. Loss estimates
disagree: ~$223M (rekt.news, Halborn, QuillAudits), "over $260M" (Verichains), "over $230M"
(SlowMist). ~$162M was frozen by Sui validators mid-heist; ~$60M+ crossed to Ethereum via
Wormhole. The protocol relaunched June 8, 2025.

**Root cause.** Smart-contract math bug in a shared integer library
(`@cetuspackages/inter-mate`, `math_u256::checked_shlw`). The overflow guard used the wrong bound
— `0xffffffffffffffff << 192` instead of `1 << 192` — so almost every input passed the check. For
any `n >= 2^192`, `n << 64` silently wrapped modulo 2^256, collapsing the numerator in `get_delta_a`
so the token A needed to mint a given liquidity rounded to 1. A single unit of token A could then
mint a huge position in a narrow tick range.

**Pattern.** Integer overflow / faulty bounds check in fixed-width arithmetic. A guard constant
is wrong, letting a wrapped value flow into a division that rounds to 1. The same flawed function
was copy-pasted into Kriya, FlowX, and Turbos.

**Check.** (1) Unit/fuzz test on the library primitive: `checked_shlw(n)` must return `(0, true)`
for every `n >= 1 << 192`; fuzz the full u256 range. (2) Invariant test at the pool level:
depositing `x` of token A never mints liquidity recovering more than `x` on withdrawal. (3) Review
rule: treat shared math libraries as in-scope for audit, not out-of-bounds. The fix changed the
mask to `1 << 192` and the condition to `n >= mask`.

**Sources.**
- https://medium.com/@CetusProtocol/cetus-relaunch-incoming-recovery-plan-and-the-road-ahead-9fc0f8bd5c41
- https://medium.com/@CetusProtocol/cetus-report-2025-q2-9d4f25a3eed9
- https://blog.verichains.io/p/cetus-protocol-hacked-analysis
- https://blog.verichains.io/p/multiple-sui-projects-previously
- https://slowmist.medium.com/slowmist-analysis-of-the-230-million-cetus-hack-ee569af040f2
- https://www.halborn.com/blog/post/explained-the-cetus-hack-may-2025
- https://quillaudits.medium.com/cetus-protocol-hack-overflow-bug-leads-to-223m-loss-0bafd07d83e9
- https://rekt.news/cetus-rekt
- https://github.com/CetusProtocol/integer-mate/commit/06660f704c4ac1d443ab62346a46b5b60d49df33

---

## 13. Cork Protocol (May 2025, Ethereum)

**What happened.** On May 28, 2025, Cork Protocol's wstETH:weETH Liquidity Vault was drained for
3,761 wstETH (~$11.9M; rekt.news rounds to $12M). The attacker bought 3,761 Cover Tokens for
roughly 0.000003 wstETH by exploiting two vectors, then redeemed the vault's wstETH through the Peg
Stability Module. Other vaults (~$20M) were paused and returned to users.

**Root cause.** Two combined vectors. (1) Rollover pricing: `rT` used `1/T` where T is
time-to-expiry; a trade 19 minutes before expiry produced an astronomically inflated risk premium
that dominated the HIYA calculation, initializing the post-rollover AMM at a near-zero CT price.
(2) Missing access control on the Cork Hook's `beforeSwap`: any caller could inject spoofed
callback parameters that bypassed the FlashSwapRouter's authorization and tricked it into depositing
reserves into the attacker's proxy market, minting pCT/pDS tokens.

**Pattern.** (1) Hook callback validation — missing access control on a Uniswap v4 hook callback;
`beforeSwap` lacked a `msg.sender == poolManager` check. (2) Oracle/pricing manipulation through
unbounded time-decay.

**Check.** (1) Unit test for hook access control: call `beforeSwap` directly from an arbitrary EOA
and assert revert. (2) Fuzz test for rollover pricing bounds: fuzz time-to-expiry T with random
trade volumes; assert rT < 10,000% and CT initialization price > 1% of RA.

**Sources.**
- https://www.cork.tech/blog/post-mortem
- https://www.cork.tech/blog/lessons-learned
- https://rekt.news/cork-protocol-rekt
- https://www.cork.tech/blog/security-framework
- https://defillama.com/protocol/cork-v1

Note: Security firms cited (Dedaub, BlockSec, Cyvers, Blockaid, MistTrack) are quoted in Cork's
post-mortem and rekt.news; no standalone public analyses from these firms were found.

---

## 14. Meta Pool (June 2025, Ethereum)

**What happened.** On June 17, 2025, Meta Pool's liquid-staking vault (mpETH) was exploited: an
attacker minted 9,705 mpETH without depositing any ETH, then swapped part into ETH via Meta Pool's
own pool and Uniswap V3, draining ~52.5 ETH (~$130k–$133k) from DAO-provided liquidity. The minted
tokens were notionally worth ~$27M. Stakers' 913 ETH principal was untouched. Sources disagree:
SolidityScan reports ~56.35 ETH (~$142k) across Ethereum, Optimism, and Linea; SlowMist (via
Quadriga) reports ~$25k; a separate MEV front-runner took ~37.5 WETH that was later returned.

**Root cause.** Smart-contract logic/access-control bug. Meta Pool's `Staking` inherits
OpenZeppelin `ERC4626Upgradeable` but its asset is native ETH. The team overrode `_deposit` to drop
`safeTransferFrom` and consume ETH from `msg.value`, but this was applied only to `depositETH()`
and `deposit(WETH)`. The inherited, non-payable `mint(uint256 shares, address receiver)` was left
untouched. Calling `mint()` with `msg.value == 0` still called the overridden `_deposit`, which
minted shares and incremented `totalUnderlying` without checking that assets were received. The
whitelist gate was disabled.

**Pattern.** Missing access control / unvalidated input on an inherited function (mis-adapted
ERC-4626 vault). When asset collection is removed from `_deposit` but an entry point still reaches
it without delivering the asset, that path becomes a free-mint faucet.

**Check.** (1) Invariant/fuzz test: every path increasing shares or `totalUnderlying` must increase
the vault's actual custodied assets by at least the credited amount. (2) Review rule: when a fork
drops the transfer step from `_deposit`, enumerate every inherited entry point reaching it and
either make it payable-with-check or disable it. Operational backstop: alarm when `totalUnderlying`
rises with no matching ETH inflow.

**Sources.**
- https://blog.solidityscan.com/meta-pool-hack-analysis-fef7796f2303/
- https://www.quillaudits.com/blog/hack-analysis/meta-pool-hack-analysis
- https://medium.com/meta-pool/meta-pool-security-incident-on-mpeth-contract-on-ethereum-ba7a328d45c6
- https://www.okx.com/en-us/learn/meta-pool-mpeth-eth-exploit
- https://crypto.news/meta-pool-exploited-for-133k-after-attacker-mints-27m-worth-of-tokens/
- https://www.quadrigainitiative.com/casestudy/metapoolerc4626mpethmintwithoutethflawexploited.php
- https://crypto.training/hacks/2025-06-MetaPool/

---

## 15. Silo Finance (June 2025, Ethereum & Sonic)

**What happened.** On June 25, 2025, a pre-release leverage contract deployed by Silo Finance on
Ethereum and Sonic was exploited for 224 ETH (~$522,000 at transaction time; ~$550,000 per
QuillAudits at writing time; the difference reflects ETH price movement). Funds belonged to
SiloDAO; no user deposits were affected. Stolen ETH was routed through Tornado Cash.

**Root cause.** The `LeverageUsingSiloFlashloanWithGeneralSwap` contract accepted a `_swapArgs`
calldata parameter meant to encode a token swap but performed no validation on its contents. The
attacker crafted `_swapArgs` so the contract executed a borrow against a victim address that had
granted maximum token allowance to the leverage contract, draining the victim's collateral with the
attacker as receiver.

**Pattern.** Unvalidated input / calldata injection. The contract blindly forwarded user-supplied
calldata to an external call without validating the target address or function selector.

**Check.** (1) Review rule: any function forwarding user-supplied calldata to an external call must
validate the target address and function selector against an allowlist. (2) Invariant test: the
contract's token balance must never decrease except through the intended swap path; fuzz arbitrary
`_swapArgs` payloads and assert the invariant holds.

**Sources.**
- https://quillaudits.com/blog/hack-analysis/how-silo-finance-lost-500k
- https://etherscan.io/address/0x04377cfaF4b4A44bb84042218cdDa4cEBCf8fd62
- https://etherscan.io/address/0xCbEe4617ABF667830fe3ee7DC8d6f46380829DF9

Note: Silo Finance's own post-mortem was not found (domains `blog.silo.finance` and
`forum.silo.finance` did not resolve). No analyses from BlockSec, SlowMist, CertiK, Halborn, or
Verichains were located. rekt.news had no article for this exploit.