diff --git a/BACKLOG.md b/BACKLOG.md index 596d596..839f0fe 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -1,8 +1,8 @@ # OAK Backlog — auto-generated -_Generated by `tools/build_backlog.py` on 2026-06-24. Regenerated on every `npm run site:data`._ +_Generated by `tools/build_backlog.py` on 2026-07-03. Regenerated on every `npm run site:data`._ -_Scope: 646 worked examples, 146 Techniques, 19 Threat Actors._ +_Scope: 652 worked examples, 146 Techniques, 19 Threat Actors._ This file is a prioritized contributor backlog. **P0** items close hard structural gaps (empty Tactics, placeholder actor cards). **P1** items lift per-Tactic coverage below the documented minimum. **P2** items anchor candidate sub-Techniques from `TAXONOMY-GAPS.md`. diff --git a/STATS.md b/STATS.md index ca64cc3..bd75216 100644 --- a/STATS.md +++ b/STATS.md @@ -1,11 +1,11 @@ # OAK — Stats Snapshot -_Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ +_Auto-generated by `tools/build_stats.py` at 2026-07-03 15:51 UTC._ ## Catalogue - **17** Tactics · **146** Techniques · **19** Threat Actors · **43** Mitigations · **41** Software · **12** Data Sources -- **646** Worked Examples · **1555** bibtex entries +- **652** Worked Examples · **1555** bibtex entries ## Examples by Tactic @@ -14,14 +14,14 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ | T1 (Token Genesis) | 40 | | T2 (Liquidity Establishment) | 32 | | T3 (Holder Capture) | 36 | -| T4 (Access Acquisition) | 75 | -| T5 (Value Extraction) | 113 | -| T6 (Defense Evasion) | 52 | -| T7 (Laundering) | 152 | +| T4 (Access Acquisition) | 78 | +| T5 (Value Extraction) | 114 | +| T6 (Defense Evasion) | 55 | +| T7 (Laundering) | 156 | | T8 (Operator Continuity / Attribution Signals) | 82 | -| T9 (Smart-Contract Exploit) | 203 | -| T10 (Bridge / Cross-Chain) | 55 | -| T11 (Custody / Signing) | 144 | +| T9 (Smart-Contract Exploit) | 204 | +| T10 (Bridge / Cross-Chain) | 56 | +| T11 (Custody / Signing) | 146 | | T12 (NFT-Specific) | 31 | | T13 (Account Abstraction) | 20 | | T14 (Validator / Staking) | 39 | @@ -46,7 +46,7 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ | 2023 | 106 | | 2024 | 153 | | 2025 | 76 | -| 2026 | 62 | +| 2026 | 68 | ## Examples by Year-Month (recent dense window) @@ -75,16 +75,16 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ | 2026-03 | 5 | | 2026-04 | 11 | | 2026-05 | 16 | -| 2026-06 | 14 | +| 2026-06 | 20 | ## Attribution-strength Distribution | Strength | Count | | --- | ---: | -| pseudonymous | 305 (47.2%) | -| unattributed | 149 (23.1%) | -| confirmed | 125 (19.3%) | -| inferred-strong | 64 (9.9%) | +| pseudonymous | 308 (47.2%) | +| unattributed | 152 (23.3%) | +| confirmed | 125 (19.2%) | +| inferred-strong | 64 (9.8%) | | inferred-weak | 3 (0.5%) | ## Threat Actors diff --git a/examples/2026-06-eleven-drainer-legit-subdomain-frontend-compromise-cohort.md b/examples/2026-06-eleven-drainer-legit-subdomain-frontend-compromise-cohort.md new file mode 100644 index 0000000..1359849 --- /dev/null +++ b/examples/2026-06-eleven-drainer-legit-subdomain-frontend-compromise-cohort.md @@ -0,0 +1,54 @@ +# "Eleven drainer" injected into legitimate project subdomains — Gitcoin and Yield Yak — Ethereum / Avalanche — 2026-06 (June 21 and 24) + +> **Status: detection-stage cohort (as of 2026-06).** Both incidents were surfaced by Blockaid as front-end compromise alerts, not post-mortems. Neither project nor Blockaid published a confirmed theft total, and the initial-access vector for either subdomain was not disclosed. This entry documents the confirmed mechanism (a legitimate project subdomain serving a wallet-drainer script) and marks losses and access vector as open. + +**Loss:** **Undisclosed for both incidents.** On **2026-06-21** Blockaid flagged the **`files.gitcoin.co`** subdomain (Gitcoin, Ethereum) as serving injected "Eleven drainer" code, and on **2026-06-24** it flagged **`vote.yieldyak.com`** (Yield Yak, Avalanche) with the same kit. In both cases a secondary subdomain of the real project was compromised while the main application was not implicated, and the alerts warned users off before any confirmed theft total was published. Because these were detection-stage warnings rather than settled post-mortems, no dollar figure is attached to either; the impact recorded here is user exposure for anyone who connected a wallet to the poisoned page during the window. + +**OAK Techniques observed:** **OAK-T6.008** (Verified-but-Malicious Frontend Routing — *primary, confirmed mechanism*. A legitimate, project-owned subdomain served an injected wallet-drainer script, so the malicious code ran behind a trusted domain rather than a look-alike clone. See [`techniques/T6.008-verified-but-malicious-frontend-routing.md`](../techniques/T6.008-verified-but-malicious-frontend-routing.md)). **OAK-T4.004** (Allowance / Approve-Pattern Drainer — the "Eleven drainer" script pushes a connecting wallet to approve or sign hostile transactions, granting the operator permission to move assets; this is the drainer's extraction primitive. See [`techniques/T4.004-allowance-approve-drainer.md`](../techniques/T4.004-allowance-approve-drainer.md)). The **initial-access vector that let the attacker inject code into each subdomain was not disclosed** (candidates in this class include registrar / DNS, hosting or object-storage, and CI or package-registry credential compromise, which is OAK-T15.004); OAK does not assert a specific vector here because none was published. + +**Attribution:** **unattributed.** The only attribution is toolkit-level: both incidents used the **"Eleven drainer"** kit, a drainer-as-a-service offering that first surfaced publicly around November 2025 (flagged by SlowMist's Yu Xian) alongside established kits such as Inferno Drainer and Angel Drainer. Because the kit is rented, its presence does not identify the operator behind these specific deployments, and no operator, affiliate roster or wallet cluster was published for either the Gitcoin or Yield Yak instance. + +**Key teaching point:** **A wallet-drainer served from a project's own subdomain defeats the defenses built for fake clones, because the domain is genuinely the project's.** Users and allowlist tooling that check for look-alike domains (the fake-clone pattern in [`examples/2023-2026-fake-dex-clone-frontend-cohort.md`](2023-2026-fake-dex-clone-frontend-cohort.md)) do not flag `files.gitcoin.co` or `vote.yieldyak.com`, which really do belong to Gitcoin and Yield Yak. The compromise is at the web-delivery and access-control layer of the real project: a secondary subdomain that is easy to overlook in asset inventories, injected with a drainer that solicits approvals on wallet connect. The controls that apply are hardening every project-owned subdomain and its hosting to the same standard as the main app, subresource integrity and a content-security policy that constrains injected scripts, monitoring project domains for unexpected script changes, and client-side approval-warning tooling that flags a hostile approval regardless of which domain raised it. The recurrence of the same kit against a second legitimate project three days later is the signal that this is a repeatable playbook, not a one-off. + +## Summary + +In June 2026, the security detection firm **Blockaid** flagged two legitimate DeFi projects whose secondary subdomains had been injected with the **"Eleven drainer"** wallet-draining script. On **2026-06-21** the affected host was **`files.gitcoin.co`** (Gitcoin, on Ethereum); on **2026-06-24** it was **`vote.yieldyak.com`** (Yield Yak, an Avalanche auto-compounding yield-vault and aggregator). In both cases the main application interface was not implicated, and the compromise was scoped to a secondary subdomain. + +The injected script is a client-side drainer: when a user connects a wallet to the poisoned page, it pushes them to approve or sign hostile transactions, granting the operator standing permission to move assets. This is a website-layer compromise, not a smart-contract exploit. Neither project nor Blockaid published a confirmed loss figure at the time of the alerts, which were framed as warnings to keep users off the affected subdomains. The way each subdomain was initially compromised was not disclosed. + +The two incidents share a detector (Blockaid), a kit (Eleven drainer), and a target pattern (a secondary subdomain of a real project rather than the main app), three days apart. "Eleven drainer" is a rentable drainer-as-a-service; its operators take a cut of stolen funds, and the model relies on rushed user approvals rather than a novel on-chain exploit. + +| Incident | Date | Chain | Compromised host | Kit | Confirmed loss | +|---|---|---|---|---|---| +| Gitcoin | 2026-06-21 | Ethereum | `files.gitcoin.co` (secondary subdomain) | Eleven drainer | Undisclosed | +| Yield Yak | 2026-06-24 | Avalanche | `vote.yieldyak.com` (secondary subdomain) | Eleven drainer | Undisclosed | + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| Pre-2026-06-21 | Attacker gains the ability to inject code into `files.gitcoin.co` (vector not disclosed) | **T15.004** (candidate, undisclosed) | +| 2026-06-21 | Blockaid flags Eleven drainer code on `files.gitcoin.co`; main Gitcoin app not implicated; users warned off | **T6.008 + T4.004** | +| Pre-2026-06-24 | Attacker gains the ability to inject code into `vote.yieldyak.com` (vector not disclosed) | **T15.004** (candidate, undisclosed) | +| 2026-06-24 | Blockaid flags the same Eleven drainer kit on `vote.yieldyak.com`; framed as the same playbook three days after Gitcoin | **T6.008 + T4.004** | + +## What defenders observed + +- **Pre-event (subdomain and hosting hardening).** Both targets were secondary subdomains, the kind that fall out of asset inventories and change-control. Applying the same hosting, DNS, registrar and CI hardening to every project-owned subdomain as to the main app is the pre-event control. The specific access vector was not published, so the candidate set (DNS/registrar, hosting/object-storage, CI/package-registry credential compromise) is where hardening should concentrate. +- **At-event (trusted domain defeats clone defenses).** The malicious code ran on a real project subdomain, so look-alike-domain checks and clone allowlists did not apply. Subresource integrity, a content-security policy, and monitoring for unexpected script changes on project domains are the delivery-layer controls that do apply. +- **At-event (approval prompt on connect).** The drainer solicits approvals when a wallet connects. Client-side approval-warning and transaction-simulation tooling that flags a hostile approval independent of the originating domain is the user-facing control. +- **Cohort signal (repeatable playbook).** The same kit hit a second legitimate project three days later. Treat a confirmed drainer-on-legitimate-subdomain as a pattern to sweep for across peer projects, not a single-project cleanup. + +## Public references + +- `[blockaidgitcoin2026]` — Blockaid, detection alert naming "Eleven drainer" code on `files.gitcoin.co` (Gitcoin, 2026-06-21; user warning): +- `[cryptoeconomyyieldyak2026]` — Crypto Economy, "Yield Yak Suffers Front-End Breach in Latest Wave of Wallet-Drainer Hacks" (Yield Yak / `vote.yieldyak.com`; losses unconfirmed; same-playbook framing): +- `[cryptorankyieldyak2026]` — CryptoRank, "Yield Yak follows Gitcoin in latest wallet-drainer attack" (links the two incidents three days apart as the same pattern): +- `[cryipjune2026]` — cryip, "June 2026 Crypto Hack Report" (both logged as front-end attacks with undisclosed losses; confirms chains: Gitcoin/Ethereum, Yield Yak/Avalanche): +- `[spaziocryptoeleven2026]` — spaziocrypto, background on "Eleven drainer" as a drainer-as-a-service kit (SlowMist / Yu Xian identification ~2025-11; comparison to Inferno / Angel): + +## Discussion + +This cohort anchors the case where a wallet drainer is served from a project's own subdomain rather than a look-alike clone. It sits next to OAK's drainer-service coverage (the Inferno Drainer handover and the encrypted-config "Reloaded" cases) on the kit side, and next to the fake-DEX clone-frontend cohort on the delivery side, but it is neither: the domain is authentic, and the compromise is of the real project's web-delivery and access-control surface. That is what makes T6.008 the primary mapping, with T4.004 as the drainer's approval-based extraction. + +Two properties give the pair its teaching value. First, trusted-domain delivery defeats the defenses built for clones, so the control set shifts to subdomain and hosting hardening, subresource integrity, content-security policy, and domain script-change monitoring rather than user education about fake URLs. Second, the same rented kit reappearing against a second legitimate project within three days marks a repeatable playbook, which argues for treating one confirmed instance as a prompt to sweep peer projects' subdomains. The entry is deliberately detection-stage: losses and initial-access vectors were not disclosed, so OAK records the confirmed subdomain-plus-drainer mechanism and leaves the theft totals and access vectors open, to be revised if either project publishes a post-mortem. diff --git a/examples/2026-06-jaredfromsubway-mev-bot-counter-mev-honeypot-allowance-drain.md b/examples/2026-06-jaredfromsubway-mev-bot-counter-mev-honeypot-allowance-drain.md new file mode 100644 index 0000000..bea391e --- /dev/null +++ b/examples/2026-06-jaredfromsubway-mev-bot-counter-mev-honeypot-allowance-drain.md @@ -0,0 +1,49 @@ +# jaredfromsubway.eth — a counter-MEV honeypot lures the sandwich bot into leaving standing token allowances, then sweeps them — Ethereum — 2026-06-20 + +**Loss:** **~\$7.5M realised.** On **2026-06-20** (~18:49 UTC) the well-known Ethereum MEV bot **jaredfromsubway.eth** was drained of genuine **WETH, USDC and USDT** in a single sweep transaction. Blockaid put the loss at about **\$7.5M** and classified it as a "counter-MEV honeypot," explicitly not phishing, not a private-key compromise, and not a protocol contract bug. An operator-linked X account claimed a higher **~\$15M** figure; that claim is **unverified** and no reporter could confirm the account's link to the bot, so OAK records ~\$7.5M as the corroborated figure. No funds were recovered as of the Chainalysis writeup on 2026-06-26. + +**OAK Techniques observed:** **OAK-T4.004** (Allowance / Approve-Pattern Drainer — *primary mechanism*. The abused primitive is the ERC-20 `approve()` / allowance: when a spender is granted an allowance and a trade does not fully consume it, the leftover allowance stays standing, and the holder can later call `transferFrom()` to move the victim's tokens up to that amount with no new signature. The attacker structured trade routes so the bot's own routing logic granted allowances to attacker-controlled helper contracts that were then left partly or wholly unused. Once enough standing allowances had accumulated, a coordinator contract swept the bot's real WETH/USDC/USDT in one atomic transaction. See [`techniques/T4.004-allowance-approve-drainer.md`](../techniques/T4.004-allowance-approve-drainer.md)). **OAK-T6.006** (Counterfeit Token Impersonation — the bait was roughly **66 fake token contracts** mimicking the names and interfaces of WETH, USDC and USDT, each paired with sham liquidity pools so the routes looked like the profitable arbitrage and sandwich opportunities the bot was built to hunt). The stolen stablecoins were swapped to ETH within minutes and about **1,000 ETH** was deposited into Tornado Cash (OAK-T7.001). + +**Attribution:** **unattributed.** No named individual or group. Funds were traced to an attacker address reported as beginning `0x3e37` (single-source), consolidated into roughly 4,427 ETH before the mixer hop. The operator-linked account offered a bounty for return of funds; the bounty amount and the account's authenticity are both unverified. Blockaid's classification is quoted consistently across outlets, though no standalone Blockaid post was located; Chainalysis published the fund-tracing analysis on 2026-06-26. + +**Key teaching point:** **A standing ERC-20 allowance is a live liability, and an automated trader that leaves them open can be baited into being drained without any key compromise or phishing.** The bot was not tricked into signing anything out of band; its own routing logic issued legitimate approvals during trades that under-consumed them, and the attacker collected those dangling allowances until a single `transferFrom` sweep across ~66 contracts was worth the trap. The size-dependent behaviour is the trap's core: on small test trades the granted allowance was fully consumed, so the routes looked benign, while larger trades were structured to leave the approval open. The controls that break this are exact-amount approvals rather than unlimited ones, zeroing out allowances after each route instead of leaving them standing, validating token contracts and pools before interacting, and monitoring for non-consumed allowances as a red flag. The case also inverts OAK's existing jaredfromsubway.eth entries, where the same bot is the sandwich attacker (see [`examples/2023-02-jaredfromsubway-mev.md`](2023-02-jaredfromsubway-mev.md)); here the automation that industrialised extracting value from others' trades was itself turned by a trap built against its approval behaviour. + +## Summary + +**jaredfromsubway.eth** is Ethereum's best-known sandwich and front-running MEV operation, active since early 2023 and frequently the network's single largest daily gas spender. Reporting attributes roughly **70% of Ethereum sandwich attacks between November 2024 and October 2025** to it. The bot scans for profitable routes and executes them automatically, granting ERC-20 approvals to spender contracts as a normal step in its own pipeline. + +Weeks before the drain, an attacker deployed about **66 fake token contracts** that copied the names and interfaces of WETH, USDC and USDT and paired them with sham liquidity pools, so the routes resembled the opportunities the bot hunts. To trade those routes the bot approved attacker-controlled helper contracts to spend its real tokens. On small transactions the allowance was fully consumed inside the trade, so nothing looked wrong. On larger transactions the routes were structured so the allowance was left standing after the trade. Repeated across the fake contracts, open allowances accumulated. + +On **2026-06-20**, once enough standing allowances had built up, a coordinator contract called `withdraw` across all the child contracts at once; each called `transferFrom()` against the bot's balance up to its open allowance and forwarded the genuine WETH, USDC and USDT to the attacker, draining about **\$7.5M** in one atomic transaction. The stolen stablecoins were swapped to ETH within minutes to avoid issuer freezes, consolidated into roughly 4,427 ETH, and about 1,000 ETH was routed through Tornado Cash. No funds were recovered. + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| Weeks before 2026-06-20 | Attacker deploys ~66 fake token contracts mimicking WETH/USDC/USDT plus sham pools | **T6.006** (bait) | +| Ongoing | Bot's routing logic grants approvals to attacker helper contracts to trade the routes; small trades fully consume the allowance and look benign | **T4.004 setup** | +| Ongoing | Larger trades are structured so the allowance is left standing; open allowances accumulate across the fake contracts | **T4.004 accumulation** | +| 2026-06-20 ~18:49 | A coordinator contract calls `withdraw` across the child contracts; each `transferFrom()`s the bot's real WETH/USDC/USDT up to its open allowance; ~\$7.5M swept in one transaction | **T4.004 extraction** | +| 2026-06-20 (minutes later) | Stablecoins swapped to ETH; consolidated to ~4,427 ETH; ~1,000 ETH deposited to Tornado Cash | **T7.001** | +| 2026-06-26 | Chainalysis publishes fund-tracing analysis; no funds recovered | (third-party forensics) | + +## What defenders observed + +- **Pre-event (unvetted token contracts and pools).** The bait depended on the bot interacting with contracts it had not validated. Validating token contracts and pools before trading, and treating unvetted contracts as hostile, is the pre-event control; speed-over-diligence on automated routing is what the trap exploited. +- **At-event (standing allowance as the live liability).** The extraction needed no key and no new signature, only accumulated `approve()` grants that later trades did not consume. Exact-amount approvals and post-route allowance revocation remove the standing liability entirely. Non-consumed allowances after a completed route are the red-flag signal. +- **At-event (size-dependent benign behaviour).** The trap behaved benignly on small trades and left approvals standing on large ones, so sampling small interactions would not have surfaced it. Allowance monitoring has to cover the full trade, not a sampled subset. +- **Post-event (fast conversion to ETH, then mixer).** Stablecoins were swapped to ETH within minutes to pre-empt issuer freezes, then partly mixed. Once value reaches the mixer hop inside the same window as the drain, on-chain recovery is foreclosed, which matches the outcome here. + +## Public references + +- `[coindeskjared2026]` — CoinDesk, "Ethereum's biggest 'sandwich' bot drained of \$7.5 million in ironic exploit" (mainstream confirmation; 70% sandwich-share stat; irony framing): +- `[chainalysisjared2026]` — Chainalysis, "Sandwich Attack: How JaredfromSubway Lost \$7.5M" (fund tracing; laundering path; no funds recovered; bot history): +- `[thirdwebjared2026]` — thirdweb, "Jaredfromsubway.eth MEV Bot Exploited for \$7.5M — What Builders Need to Know" (ERC-20 `approve()` / dangling-allowance mechanism and prevention guidance): +- `[theblockjared2026]` — The Block, "Notorious jaredfromsubway MEV bot drained for roughly \$7.5 million in counter-MEV honeypot" (on-chain forensics: 18:49 UTC sweep, coordinator-contract `withdraw`, 4,427 ETH to Tornado Cash, \$15M-claim caveat): +- `[cryptonewsjared2026]` — crypto.news, "JaredFromSubway MEV bot gets drained in \$7.5m approval trap" (approval-trap breakdown; Blockaid quotes; bounty and \$15M claim; attacker address): + +## Discussion + +This is OAK's approve-pattern anchor for an automated victim rather than a phished human. T4.004 usually covers a drainer that harvests allowances from users tricked into signing; here the same primitive is turned against a bot whose own routing logic grants approvals, with the twist that the trap is patient, accumulating standing allowances across many fake-token routes until a single sweep is worthwhile. The counterfeit tokens (T6.006) are the bait that makes the routes look profitable, and the size-dependent behaviour is what keeps the trap hidden during the accumulation phase. + +The case is worth preserving for two reasons. First, it restates the standing-allowance liability in a setting where there is no user to phish and no key to steal, which sharpens the control set toward exact-amount approvals and post-route revocation rather than user education. Second, it inverts the corpus's earlier jaredfromsubway.eth entries: the bot that automated extracting MEV from others' trades was drained by automation built to exploit its approval behaviour. The neutral reading is that any automated trader leaving allowances open carries a live liability regardless of what side of the trade it usually sits on, and the defensive unit is the allowance lifecycle, not the identity of the operator. diff --git a/examples/2026-06-myswap-cl-starknet-fake-token-shared-vault-accounting-drain.md b/examples/2026-06-myswap-cl-starknet-fake-token-shared-vault-accounting-drain.md new file mode 100644 index 0000000..2b55725 --- /dev/null +++ b/examples/2026-06-myswap-cl-starknet-fake-token-shared-vault-accounting-drain.md @@ -0,0 +1,44 @@ +# mySwap CL — a fake "EVIL" token abuses shared-vault concentrated-liquidity accounting to drain residual LP — Starknet — 2026-06-19 + +> **Status: developing / preliminary mapping (as of 2026-06).** The loss, date, asset breakdown and laundering path are multi-sourced, but the exact line-level bug is not yet public and mySwap had not published a full post-mortem at the time of writing. The technique mapping below is preliminary and should be revised once the precise defect is disclosed. + +**Loss:** **~\$300K–\$305K realised.** On **2026-06-19** (~07:15 UTC) an attacker drained residual liquidity from **mySwap CL**, the concentrated-liquidity product of the Starknet DEX mySwap. The drained assets were about **137.96 ETH, 45,000 USDC, 19,900 USDT and 230,000 STRK**. The mySwap CL interface had been closed to new deposits for more than six months, so the drained funds were residual LP spread across 100,000+ positions; the attack emptied nearly all of it. mySwap confirmed the incident. The stolen assets were bridged off Starknet and routed through Railgun to obscure the trail; no attacker address was published. + +**OAK Techniques observed:** **OAK-T9.004** (Access-Control Misconfiguration — *preliminary mapping*. The confirmed shape is that the vault's accounting trusted an attacker-controlled token it should have rejected: the attacker introduced a fake token named "EVIL" that distorted the accounting path tied to the CL pools and their **shared vault**, so a malicious token interaction could pull real assets out of a vault holding liquidity across many pools. The load-bearing failure is a missing validation / authorization boundary on which tokens may influence balance and withdrawal accounting. The exact defect is not public; reported candidates include a missing token allow-list, a callback / reentrancy path, and LP-share inflation. Pending mySwap's post-mortem, OAK records this as a **token-admission / accounting-validation flaw** and flags a possible forward-candidate sub-technique (untrusted-token shared-vault accounting abuse) for TAXONOMY-GAPS. See [`techniques/T9.004-access-control-misconfiguration.md`](../techniques/T9.004-access-control-misconfiguration.md)). The laundering path (bridged off Starknet, then routed through Railgun) is OAK-T7.003 and OAK-T7.001. + +**Attribution:** **pseudonymous.** No named actor and no attacker address disclosed in public sourcing. The incident was logged by SlowMist's hacked database (2026-06-19, Starknet, smart-contract vulnerability, Railgun) and detailed by Crypto Adventure and Phemex; mySwap confirmed it but had not published a full post-mortem at the time of writing. + +**Key teaching point:** **A shared vault that pools liquidity across many concentrated-liquidity positions is only as safe as its weakest token-admission check, because one malicious token that its accounting trusts can reach all of the pooled assets.** The attack did not need to break any single pool; it introduced a token the shared vault's accounting would act on and used it to withdraw real assets that backed unrelated positions. The controls that apply are strict validation of which tokens may participate in vault accounting (allow-listing rather than accepting arbitrary tokens), isolating per-position or per-pool balances so a single token cannot reach the whole vault, and value-conservation invariants on withdrawals so a redemption cannot exceed what was genuinely deposited. The case also shows that a product closed to new deposits is not dormant for security purposes: residual LP across 100,000+ positions was still fully drainable, so wind-down and deprecation plans need to either withdraw residual funds or keep the contract monitored, not just close the front door. + +## Summary + +**mySwap** is a Starknet DEX; **mySwap CL** is its concentrated-liquidity product, whose positions were backed by a **shared vault** holding liquidity across many pools. The CL interface had been closed to new deposits for over six months, leaving residual LP spread across 100,000+ positions. + +On **2026-06-19** (~07:15 UTC), an attacker introduced a fake token named **"EVIL"** and used it to distort the vault's accounting so that a malicious token interaction could withdraw real assets from the shared vault. About **\$300K–\$305K** (137.96 ETH, 45,000 USDC, 19,900 USDT, 230,000 STRK) was drained, emptying nearly all remaining liquidity. The attacker bridged the proceeds off Starknet and routed them through **Railgun**. mySwap confirmed the incident; the precise line-level defect had not been published at the time of writing. + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| Pre-2026-06-19 | mySwap CL closed to new deposits for 6+ months; residual LP across 100,000+ positions remains in a shared vault | (standing surface) | +| 2026-06-19 ~07:15 | Attacker introduces a fake "EVIL" token and abuses the shared-vault CL accounting to withdraw ~\$300K–\$305K of residual LP | **T9.004 (preliminary)** | +| 2026-06-19 | Proceeds bridged off Starknet and routed through Railgun | **T7.003 + T7.001** | +| 2026-06-19/20 | mySwap confirms the incident; SlowMist logs it; no full post-mortem published | (operator response) | + +## What defenders observed + +- **Pre-event (token-admission boundary).** The confirmed root shape is that the vault's accounting acted on a token it should not have trusted. Allow-listing the tokens that may influence vault accounting, rather than accepting arbitrary tokens, is the pre-event control. The exact bug (missing allow-list vs callback/reentrancy vs share inflation) is unconfirmed. +- **At-event (shared vault as blast radius).** Because one vault backed liquidity across many pools, a single malicious-token interaction reached assets backing unrelated positions. Per-position or per-pool balance isolation limits how far one bad token can reach. +- **At-event (deprecated but not dormant).** The product was closed to deposits yet still held drainable residual LP. Deprecation without withdrawing residual funds or maintaining monitoring leaves a live target. +- **Post-event (fast obfuscation).** Proceeds were bridged off Starknet and routed through Railgun, foreclosing straightforward on-chain tracing. + +## Public references + +- `[cryptoadventuremyswap2026]` — Crypto Adventure, "mySwap loses \$305K on Starknet after fake EVIL token abuses CL pool accounting" (most detailed mechanism; EVIL-token / shared-vault CL accounting; asset breakdown): +- `[phemexmyswap2026]` — Phemex, "Starknet's mySwap protocol exploited, \$300,000 drained" (\$300K; Railgun laundering; mySwap confirmation): +- `[slowmistmyswap2026]` — SlowMist Hacked database — mySwap (2026-06-19, Starknet, smart-contract vulnerability, Railgun): +- `[cryptotimesmyswap2026]` — Crypto Times, mySwap coverage (corroborates ~07:15 UTC and the asset list): + +## Discussion + +mySwap CL is a deliberately preliminary entry: the dollar figure is small, no attacker address is public, and the precise defect is undisclosed, so its near-term value is the mechanism class rather than a fully specified technique. The confirmed part, a fake token abusing a shared vault's concentrated-liquidity accounting to withdraw real assets, is a clean example of a token-admission and value-conservation failure, and it is worth recording as a Starknet data point for the class. The entry maps to T9.004 preliminarily on the basis of the missing validation boundary, and flags a candidate sub-technique for untrusted-token shared-vault accounting abuse; it should be revisited once mySwap or a security firm publishes the line-level bug, at which point it may firm up under a more specific T9 subclass. The secondary lesson is durable regardless of the exact defect: a product closed to new deposits still needs its residual funds withdrawn or its contracts monitored, because closing the deposit path does not make the pooled liquidity safe. diff --git a/examples/2026-06-polymarket-frontend-vendor-js-injection-approval-drain.md b/examples/2026-06-polymarket-frontend-vendor-js-injection-approval-drain.md new file mode 100644 index 0000000..e02a050 --- /dev/null +++ b/examples/2026-06-polymarket-frontend-vendor-js-injection-approval-drain.md @@ -0,0 +1,48 @@ +# Polymarket — a compromised third-party frontend vendor injects wallet-draining JavaScript into the live site — Polygon / Ethereum — 2026-06-25 + +**Loss:** **~\$3.0–3.1M realised** from **at least 11 user wallets.** On **2026-06-25** an attacker served malicious JavaScript to real users on Polymarket's official site through a compromised third-party frontend dependency, draining **pUSD** (Polymarket's USDC-backed stablecoin). The figure firmed from ~\$3.0M at disclosure to ~\$3.1M within about two days. Polymarket's own backend, servers and smart contracts were not compromised; the failure was in the client-side supply chain of the website. The stolen pUSD was bridged from Polygon to Ethereum, swapped to roughly **1,893 ETH**, and consolidated into a single wallet. Polymarket contained the incident within hours, removed the compromised dependency, and pledged full refunds to affected users. + +**OAK Techniques observed:** **OAK-T15.002** (Supply-Chain / Vendor-Pipeline Compromise — *primary mechanism*. The entry point was a compromised **third-party frontend vendor / dependency** that Polymarket shipped as part of its website. Polymarket disclosed only that "a 3rd party vendor had been compromised"; the specific package or domain was not named. Through that dependency the attacker inserted malicious code into the legitimate frontend served on the official site. See [`techniques/T15.002-supply-chain-vendor-pipeline-compromise.md`](../techniques/T15.002-supply-chain-vendor-pipeline-compromise.md)). **OAK-T4.002** (Compromised Front-End Permit Solicitation — the injected script hijacked active browser sessions and prompted fraudulent token-approval transactions, so users on the real site were led to approve transfers that drained their pUSD. See [`techniques/T4.002-compromised-frontend-permit-solicitation.md`](../techniques/T4.002-compromised-frontend-permit-solicitation.md)). The laundering path (pUSD bridged Polygon → Ethereum, swapped to ~1,893 ETH, consolidated to one wallet) is OAK-T7.003. + +**Attribution:** **unattributed.** No named actor. Rescana notes there was no unique malware family or toolkit to attribute, and the observed behaviour is consistent with either financially-motivated crime or a more capable actor. On-chain analysts (including "Specter") sized the loss at about \$2.94M across 11 wallets; the ~1,893 ETH consolidation figure traces to PeckShield's fund-flow analysis. The specific compromised vendor was never publicly identified. + +**Key teaching point:** **A wallet interface can be fully trustworthy at the smart-contract and server layer and still drain users, because the client-side supply chain of the website is its own attack surface.** Nothing about Polymarket's contracts or backend failed here; a dependency in the frontend it ships was compromised, and the malicious code rode the trust users place in the official domain to solicit approvals. The controls that address this class live at the web-delivery layer: subresource integrity and pinning on third-party scripts, a strict content-security policy that constrains what injected code can do, review and provenance checks on frontend dependencies and vendors, and client-side transaction-simulation or approval-warning tooling that flags an unexpected approval prompt regardless of which site raised it. This is a different Polymarket supply-chain incident from the earlier trader-tooling campaign in [`examples/2026-01-polymarket-trader-tooling-supply-chain.md`](2026-01-polymarket-trader-tooling-supply-chain.md), which used malicious npm packages and impersonation to steal keys from developers and bot operators and did not touch Polymarket's own site; the two share the supply-chain theme but differ in surface, delivery and victims. The concurrent CFTC probe into Polymarket's marketing is unrelated to this incident and is not part of its mechanism. + +## Summary + +**Polymarket** is a prediction-market platform whose users trade on its official website using **pUSD**, a USDC-backed stablecoin, on Polygon. On **2026-06-25**, an attacker compromised a **third-party frontend vendor** whose dependency Polymarket shipped as part of that website, and used it to inject malicious JavaScript into the live frontend served to real users. + +The injected script hijacked active browser sessions and prompted users to approve fraudulent token-approval transactions. Users who approved had their pUSD moved to attacker-controlled addresses. At least **11 wallets** were drained for a total of about **\$3.0–3.1M**. Polymarket's backend, servers and smart contracts were not involved; the compromise was entirely in the client-side supply chain of the site. + +The stolen pUSD was bridged from **Polygon to Ethereum**, swapped to roughly **1,893 ETH**, and consolidated into a single wallet. Polymarket identified and removed the compromised dependency within hours, isolated the malicious script, began contacting affected users directly, and committed to full refunds; the loss figure was revised upward to about \$3.1M two days later. The specific vendor and no indicators of compromise were published. + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| Pre-2026-06-25 | A third-party frontend vendor / dependency shipped in Polymarket's website is compromised | **T15.002** (entry vector) | +| 2026-06-25 | Malicious JavaScript is served to real users on the official Polymarket frontend; it hijacks sessions and prompts fraudulent token approvals; ~11 wallets drained of pUSD (~\$3.0M) | **T15.002 + T4.002 execution** | +| 2026-06-25 | Stolen pUSD bridged Polygon → Ethereum, swapped to ~1,893 ETH, consolidated to a single wallet | **T7.003** | +| 2026-06-25/26 | Polymarket contains the incident, removes the compromised dependency, contacts affected users, pledges full refunds; discloses publicly | (operator response) | +| 2026-06-27 | Loss revised to ~\$3.1M | (updated accounting) | + +## What defenders observed + +- **Pre-event (frontend dependency and vendor trust).** The compromise originated in a third-party dependency Polymarket shipped. Subresource integrity, script pinning, vendor/provenance review, and a restrictive content-security policy limit what a compromised dependency can do once it is on the page. These are web-delivery controls, distinct from smart-contract audits. +- **At-event (approval prompt on the trusted domain).** The drain relied on users approving transfers on the real site, where the domain itself lent the prompt legitimacy. Client-side transaction simulation and approval-warning tooling that flags an unexpected or excessive approval, independent of the originating site, is the user-facing control. +- **At-event (backend intact, client-side drained).** On-chain, Polymarket's contracts behaved normally; the loss was in signed user transactions solicited by injected code. Monitoring that watches for anomalous approval patterns from users of a given frontend, rather than only contract-level events, is the relevant detection surface. +- **Post-event (fast containment plus refunds).** Polymarket removed the dependency within hours and committed to refunds, which bounds user exposure even though the on-chain funds were bridged and consolidated quickly. Containment here is about pulling the malicious script and making users whole, not recovering the moved funds. + +## Public references + +- `[bleepingpolymarket2026]` — BleepingComputer, "Polymarket customers lose \$3 million in supply-chain attack" (primary incident report; JS injection via frontend vendor, backend not impacted, PeckShield fund-flow): +- `[securityweekpolymarket2026]` — SecurityWeek, "\$3 Million Reportedly Stolen in Polymarket Hack" (~\$3M pUSD to ~1,893 ETH, at least 11 victims, vendor unnamed): +- `[halbornpolymarket2026]` — Halborn, "Explained: The Polymarket Hack (June 2026)" (at least 11 wallets, Polygon → Ethereum bridge, consolidation to one wallet, contracts unaffected): +- `[rescanapolymarket2026]` — Rescana, "Polymarket Supply-Chain Attack Analysis" ("fewer than 15 accounts," no IOCs or vendor disclosed, prevention guidance): +- `[coindeskpolymarket2026]` — CoinDesk, "Polymarket hack updated to \$3.1 million days after the platform promised users full refunds" (loss revision; refund-pledge context): + +## Discussion + +Polymarket 2026-06 is OAK's clean anchor for a frontend-vendor supply-chain compromise that drains users while the protocol's own contracts and servers stay intact. It belongs to the T15.002 family alongside the Ledger Connect Kit library compromise and the Nx Console extension compromise, but with a prediction-market frontend as the delivery surface and user token approvals as the extraction, which is why T4.002 is co-primary: the vendor compromise put the malicious code on the page, and the fraudulent approval prompt is how value actually left. + +The case is worth keeping distinct from the earlier Polymarket trader-tooling campaign. That one poisoned npm packages and impersonated Polymarket to steal keys from developers and bot operators, and never touched Polymarket's own site. This one compromised a dependency Polymarket itself shipped and served malicious code from the official domain. The shared lesson is that "the protocol is secure" is not the same as "the website is safe to use," and the defensive unit for a wallet-facing product includes its frontend build and its vendor dependencies, checked with subresource integrity, provenance review, and a content-security policy, plus client-side approval-warning tooling for users. The vendor was never named, so the entry records the mechanism and leaves the specific dependency open. diff --git a/examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md b/examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md new file mode 100644 index 0000000..ee99591 --- /dev/null +++ b/examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md @@ -0,0 +1,47 @@ +# SecondFi — predictable web-wallet key generation drains Cardano (ADA) wallets — Cardano — 2026-06-23 + +> **Status: developing / partially disputed (as of 2026-06-24).** Figures, the affected-address count, and especially the disposition of the large \~129M ADA flow are operator-self-reported and/or contested by on-chain analysts at the time of writing. This entry documents the *mechanism* (confirmed multi-source) and flags the *disposition* (disputed) as contested metadata, per OAK's neutral-framing convention. Revise as forensic confirmation lands. + +**Loss:** **Confirmed \~16M ADA (\~\$2.4M at \~\$0.15/ADA); total exposure up to \~129M ADA (\~\$19–20M).** Independent reporting puts confirmed theft at **\~16 million ADA across \~178 wallets**; SecondFi's own statement framed it as **\~16M ADA across 374 addresses** from "3 distinct draining events" by external actors. SlowMist (Yu Xian / "Cos") estimated **potential losses exceeding \$20M, possibly involving \~129 million ADA and other tokens**, because the root cause makes **every wallet generated by the affected software iteration potentially compromised, including those not yet drained**. A separate **\~129M ADA flow** that SecondFi described as an emergency "rescue" to a third-party custodian is **disputed** (see Disposition). + +**OAK Techniques observed:** **OAK-T11.004** (Insufficient-Entropy Key Generation — *primary, confirmed mechanism*: SecondFi attributed the breach to its **native Cardano web-wallet generation software**, which produced **private keys with predictable randomness**; this collapses the key search space so an attacker can derive keys for the whole generated cohort and sweep them, independent of which wallet software a user later restores into. This is the same structural class as the Profanity/Wintermute EVM cohort, here in a **non-EVM, wallet-provider-software** form. See [`techniques/T11.004-insufficient-entropy-key-generation.md`](../techniques/T11.004-insufficient-entropy-key-generation.md)). **Disputed-disposition lenses (NOT a confirmed classification):** if the \~129M "rescue" flow proves operator-controlled rather than a verifiable independent custodian, the disposition is adjacent to **OAK-T5.007** (custodial soft-rug / exit-or-rescue-as-single-coordinated-sweep), **OAK-T11.010** (off-chain counterparty / custodian risk), and **OAK-T6.007** (trust-substrate shift — a self-custody product reframed mid-incident as a claim-to-a-custodian); the unverified "qualified third-party custodian" claim is the concern OAK-T11.005.002 (fake-custodian) exists to capture. On-chain, a cohort-wide sweep of predictable-key wallets by an attacker is **indistinguishable** from a sweep of the same wallets to a "rescue" address — which is exactly why the disposition cannot be settled from flow shape alone. + +**Attribution:** **pseudonymous.** No named entity. SlowMist's Cos tracked suspected attacker addresses (transfers cascading from larger to smaller amounts over hours, consistent with a batch of compromised keys); community trackers tagged the \~129M-receiving address (`addr1q8g8c…7vuz99`, created 2026-06-22 17:34 UTC) as an exploiter ("William-qa"), while SecondFi characterised the same flow as a custodial rescue. Entity attribution is unresolved and the rescue-vs-theft question is open as of 2026-06-24. + +**Key teaching point:** **When a wallet provider's own key-generation software is the root cause, the compromised population is the entire generated cohort — and "do nothing, wait for us" is the wrong guidance.** The load-bearing T11.004 lesson applies directly: predictable-RNG keys remain drainable until the funds are moved to a **freshly, properly generated key**, so the only protective action for a holder is **generate a brand-new wallet (new seed) with a different, audited generator and move funds immediately** — which matches the "move assets to new wallets immediately / generate new keys with a different provider" guidance independent outlets reported SecondFi also issued. The narrower public message the maintainer-supplied posts emphasised — *"DO NOT restore your recovery phrase into a new Cardano wallet"* — is **technically correct only in the literal sense** that restoring the *same* predictable phrase elsewhere does not help (the key is still derivable); it is **not** a reason to leave funds in place. The accompanying "do nothing until official steps / submit a claim" framing is the part defenders and users should treat with skepticism: for a weak-entropy cohort, inaction is the failure mode (the half-life-of-known-vulnerability tail), and a "rescue to a custodian" that cannot be independently verified on-chain is not a substitute for the holder controlling a clean key. + +## Summary + +**SecondFi** is a Cardano (ADA) web-wallet/platform (reported by Crypto Briefing to be an April-2026 rebrand of a prior "Yoroi"-branded web wallet — single-source, noted but not relied upon). On **2026-06-23** it disclosed a security incident, suspended services / entered maintenance mode, and traced the root cause to **its native Cardano web-wallet generation software, which generated private keys with insufficient/predictable randomness**. That defect makes every key produced by the affected software iteration derivable by an attacker, so the exposed population is the full generated cohort rather than a handful of phished users. + +Confirmed theft is reported at **\~16M ADA (\~\$2.4M)** across **\~178 wallets** (independent reporting) / **374 addresses** (SecondFi's own count), executed as several draining events by external actor(s). SlowMist placed **total potential exposure above \$20M (up to \~129M ADA)** on the reasoning that un-drained predictable-key wallets remain vulnerable. + +Separately, SecondFi stated it triggered **emergency "rescue" measures securing \~129M ADA to an independent third-party custodian** and engaged an external accounting firm to verify the holdings, directing affected users to submit claims at `support.secondfi.io` and to **not restore their recovery phrase into another Cardano wallet**. On-chain trackers and SlowMist associated the large flows with **attacker-linked addresses**, and community members publicly questioned whether the "custodian" address is in fact an exploiter. The rescue-vs-theft disposition of the \~129M flow is **unresolved** at the time of writing. + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| Pre-2026-06 | SecondFi's native Cardano web-wallet generation software produces user keys with predictable randomness (standing latent cohort) | (standing T11.004 surface) | +| 2026-06-22 17:34 | Address `addr1q8g8c…7vuz99` (later the \~129M-ADA recipient; disputed rescue-custodian vs attacker) is created | — | +| 2026-06-22 → 06-23 | External actor(s) derive keys and drain wallets; transfers cascade from larger to smaller amounts over hours (SlowMist/Cos) | **T11.004** | +| 2026-06-23 | SecondFi discloses the incident, suspends services, attributes root cause to its web-wallet key-generation software; says it rolled out a patch for unaffected wallets | (operator response) | +| 2026-06-23 → 06-24 | SecondFi states \~129M ADA was "rescued" to a third-party custodian; advises users to **not** restore recovery phrases and to submit claims at `support.secondfi.io`; independent outlets report SecondFi also urged moving assets to new wallets / new keys | (disputed disposition) | +| 2026-06-24 | Community trackers + SlowMist link the \~129M flow to attacker-tagged addresses; rescue-vs-theft remains contested; "hacker still actively draining" reports | **T11.004** (active cohort tail) | + +## Public references + +- `[secondfix2026]` — SecondFi (@secondfiapp), incident statements on X (root-cause "at the address level / risk when a transaction is signed"; "DO NOT restore your recovery phrase into a new Cardano wallet"; \~129M ADA "rescue" to a third-party custodian; claims at `support.secondfi.io`): +- `[cryptobriefingsecondfi2026]` — Crypto Briefing, "SecondFi exploit drains over \$20M from Cardano users as wallet key generation flaw exposed" (predictable-randomness key generation; \~178 wallets; "generate new keys using a different wallet provider and transfer your funds"; reported Yoroi rebrand): +- `[cryptonewssecondfi2026]` — crypto.news, "Cardano project SecondFi faces \$20m loss warning after flaw" (native Cardano web-wallet generation software; SlowMist/Cos batch-of-keys analysis; ADA \~\$0.15): +- `[beincryptosecondfi2026]` — BeInCrypto, "Cardano Project SecondFi Hit by Major Exploit, Losses Could Top \$20 Million": +- `[cryptotimessecondfi2026]` — The Crypto Times, "Cardano Project SecondFi Halts Services as Hack Estimates Hit \$20M": +- `[adastatsecondfiaddr2026]` — AdaStat, tracked address `addr1q8g8cgwqw98q2mrzrwgcy3wectdxwem8a8zp9r2mn6wjy7q4x7gcpv39wwurj7n72akw4kd0dgmv72gz4j92fvhn29ss7vuz99` (created 2026-06-22 17:34 UTC; \~129M-ADA recipient; role disputed): + +## Discussion + +SecondFi is OAK's first **non-EVM, wallet-provider-software** anchor for **T11.004 (Insufficient-Entropy Key Generation)**. The existing v0.x anchors are EVM/Profanity vanity-generator cases (Wintermute institutional scale; the Profanity cohort tail); SecondFi extends the class to a **Cardano consumer wallet provider whose own generation software shipped predictable randomness** — the same cryptographic failure mode at the moment of key creation, at population scale, with no on-chain or runtime signal until disclosure. The two load-bearing T11.004 properties recur cleanly here: (1) the **compromised population is computable** from the affected software iteration rather than per-victim, so SlowMist's "every wallet may be compromised, including un-drained ones" framing is the expected cohort-enumeration signal, not alarmism; and (2) the **half-life-of-known-vulnerability-after-disclosure** is the operative risk — un-rotated keys keep getting drained, which is why "do nothing and wait for official steps" is precisely the wrong user-side posture and **immediate rotation to a cleanly generated key** is the only protective action a holder can take unilaterally. + +The element that makes this case worth preserving beyond a routine T11.004 entry is the **disposition dispute**. SecondFi describes a \~129M ADA "emergency rescue" to a "qualified third-party custodian," and instructs affected users to take no self-custody action and instead submit claims. On-chain analysts (SlowMist) and community trackers instead associate the large flows with attacker-linked addresses. OAK's neutral-framing convention is the right tool here: **the mechanism (predictable key generation) is what makes this an attack and is multi-source confirmed; the disposition (rescued / attacker-controlled / laundered) is contested metadata that does not change the classification.** It is worth recording explicitly that, for a weak-entropy cohort, an attacker sweeping every derivable key into one address and a custodian sweeping the same wallets "for safekeeping" are **on-chain indistinguishable by flow shape**; settling rescue-vs-theft requires independent verification of who controls the recipient address (the accounting-firm attestation SecondFi says is underway, corroborated against the addresses SlowMist is tracking), not inference from the sweep pattern alone. Until that lands, the prudent defender reading is that an unverifiable "custodian" claim is not protection, and the maturity-appropriate attribution is **pseudonymous**. + +If forensic confirmation later establishes the \~129M flow as operator-controlled and the "rescue/claim" process as a value-capture mechanism, this example should be re-mapped to add **T5.007 / T11.010** as a co-primary disposition classification (custodial soft-rug / off-chain counterparty), with T11.004 remaining the root-cause mechanism. If it is confirmed as a genuine white-hat-style rescue, the disposition note stands as documented and the example remains a clean T11.004 wallet-provider-software anchor. Either resolution is consistent with the entry as written; the entry's job at v0.x is to record the confirmed mechanism and the open disposition honestly rather than to pre-judge the contested flow. diff --git a/examples/2026-06-secret-network-axelar-ics20-forged-ibc-packet-unbacked-mint.md b/examples/2026-06-secret-network-axelar-ics20-forged-ibc-packet-unbacked-mint.md new file mode 100644 index 0000000..b95af5e --- /dev/null +++ b/examples/2026-06-secret-network-axelar-ics20-forged-ibc-packet-unbacked-mint.md @@ -0,0 +1,52 @@ +# Secret Network — a forked CW20-ICS20 bridge contract skips source-channel and escrow checks, minting unbacked tokens redeemed over the real Axelar route — Secret Network / Axelar (Cosmos IBC) — 2026-06-10 + +**Loss:** **~\$4.67M realised.** On **2026-06-10** an attacker minted unbacked Secret-wrapped (sa\*) tokens on Secret Network and redeemed them over the legitimate Axelar IBC route, draining the real escrowed backing assets. Per the Common Prefix post-mortem the drained assets were seven sa\* tokens: saWETH (~\$1.54M), saUSDT (~\$1.12M), saWBTC (~\$1.07M), saUSDC (~\$0.64M), saDAI (~\$0.17M), saWBNB (~\$0.10M) and sawstETH (~\$0.04M). The theft went **unnoticed for about seven days** and only surfaced on **2026-06-17** when a routine cross-chain transfer failed on insufficient escrow; Axelar disclosed it on **2026-06-19**. A residual of roughly **\$642K–\$770K** was left unmoved in the attacker's Axelar wallet (the figure varies by source and snapshot). + +**OAK Techniques observed:** **OAK-T10.002** (Message-Verification Bypass — *primary, confirmed mechanism*. The Secret-side contract was a fork of the standard **CW20-ICS20** module, adapted from an escrow model to a mint model for the Axelar integration, with two validation calls left commented out in `do_ibc_packet_receive`: `parse_voucher_denom` (which would validate the denom's `/` trace against the packet's real source channel) and `reduce_channel_balance` (which would cap any release to what that channel had actually escrowed). The contract asked only whether a denom was on its allow-list, not whether the packet had arrived over an authorised channel. Because opening an IBC channel is permissionless, the attacker stood up a single-validator chain, opened a channel straight to the bridge contract, and self-relayed forged deposit packets carrying bare allow-listed denominations. The contract could not distinguish those forged deposits from real Axelar-channel deposits and minted unbacked sa\* tokens, which were then redeemed over the genuine Axelar channel to release the real backing. See [`techniques/T10.002-message-verification-bypass.md`](../techniques/T10.002-message-verification-bypass.md)). **OAK-T11.013** (Legacy-Version Maintenance Attack Surface — the missing checks date to the contract's initial 2023 deployment (repo commit 2023-01-15; mainnet 2023-03-30) and were carried forward unchanged through a **2026-03-05** migration that updated the bytecode for new features without restoring the dropped validation). The downstream "release without matching lock" is the canonical T10.002 indicator rather than a separate technique. The cross-chain laundering path (Axelar → Osmosis → Ethereum, swap to WETH on CoW Protocol, then split to KuCoin / ChangeNow / HitBTC deposits) is OAK-T7.003 and OAK-T7.002. + +**Attribution:** **pseudonymous.** No named individual or group. On-chain identifiers only: Secret `secret154pdez8zazqh26wyuyu70nqraal3hkvf2f03vm`, the Axelar/Osmosis hop wallet `axelar1hzra9z4zn8q0w8f3dj2wnw0xgetu8dfdhl6ad8`, and the Ethereum consolidation wallet `0x6c2eAB82bA2897A6E99FB6Af018020dA15123976`. KYC exchange deposits (KuCoin) create a potential identification path, but nothing is public. The exploit executed 2026-06-10; the Common Prefix technical breakdown is the primary source for the function names, channel IDs and per-asset figures. + +**Key teaching point:** **A bridge that mints on message receipt must verify the packet's source channel and the escrow balance, not just that the denomination is recognised.** Secret Network's fork dropped exactly those two checks, so a forged packet over an attacker-opened channel was accepted as a real deposit. Two failures compounded. First, forking a standard module and adapting escrow-to-mint logic without carrying its validation forward, then migrating that code in March 2026 without restoring the checks, is the legacy-maintenance trap (T11.013): the vulnerability shipped in 2023 and survived a later upgrade. Second, the loss stayed hidden for a week because Secret encrypts balances by default, so the missing collateral was not visible on public explorers the way a drained Ethereum pool would be, and no monitoring or pause mechanism fired. The load-bearing controls are a runtime invariant that every mint reconciles to a confirmed source-side escrow, source-channel validation on every inbound packet, and value-conservation monitoring that works on encrypted balances rather than relying on explorer visibility. Secret's own note that no external audit was requested for the Axelar integration is the pre-event gap. + +## Summary + +**Secret Network** is a Cosmos-ecosystem chain with encrypted (SNIP-20) balances by default, connected to the wider IBC network. Its integration with **Axelar** used a Secret-side contract that minted Secret-wrapped (sa\*) tokens against assets escrowed on the Axelar side. That contract was a fork of the standard **CW20-ICS20** IBC module, modified from an escrow model to a mint model. + +On **2026-06-10**, an attacker exploited two validation calls that had been commented out of the contract's packet-receive path. The contract verified that an incoming denomination was on its allow-list, but not that the packet had arrived over an authorised channel, and not that the releasing channel held enough escrow. Because IBC channel opening is permissionless, the attacker ran a single-validator chain (`ibc-dev-allowlist-denom-1`), opened a light client, connection and channel directly to the bridge contract, and self-relayed forged deposit packets carrying bare allow-listed denominations. The contract minted unbacked sa\* tokens up to roughly the full circulating supply per asset, then the attacker redeemed those balances over the legitimate Axelar route so the real escrow released the backing assets. + +The drain moved about **\$4.67M** out through Axelar to Osmosis and on to Ethereum, where it was swapped to roughly 2,350 ETH on CoW Protocol and split across fresh wallets into exchange deposits. Because Secret's balances are encrypted, nothing looked wrong on public explorers. The incident was recognised only on **2026-06-17**, when a legitimate cross-chain withdrawal bounced on insufficient escrow. **Axelar** disclosed the event on **2026-06-19**, stated that neither Axelar nor IBC itself was compromised, and disabled the Secret connections; the vulnerable contract was Secret-side and not built or maintained by Axelar. + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| 2023-01-15 / 2023-03-30 | Forked CW20-ICS20 bridge contract written and deployed to Secret mainnet with `parse_voucher_denom` and `reduce_channel_balance` commented out | (standing T10.002 surface) | +| 2026-03-05 | Contract migration updates the bytecode for new features but carries the missing checks forward | **T11.013** | +| 2026-06-10 06:50–19:05 | Attacker stands up a single-validator chain and opens a light client, connection and channel directly to the bridge contract | **T10.002 setup** | +| 2026-06-10 19:14–19:20 | Attacker self-relays forged deposit packets with bare allow-listed denoms; contract mints unbacked sa\* tokens | **T10.002 execution** | +| 2026-06-10 19:33–19:36 | Attacker redeems the minted sa\* over the real Axelar channel; escrow releases ~\$4.67M of backing assets | **T10.002 extraction** | +| 2026-06-10 19:38–20:15 | Funds bridged Axelar → Osmosis → Ethereum, swapped to ~2,350 ETH on CoW Protocol | **T7.003** | +| 2026-06-10 onward | ETH split into ~30 transfers, deposited to KuCoin / ChangeNow / HitBTC; residual ~\$642K–\$770K left on Axelar | **T7.002** | +| 2026-06-17 15:39 | A legitimate cross-chain transfer fails on insufficient escrow, revealing the drain | (detection) | +| 2026-06-19 | Axelar discloses, disables Secret connections, contacts exchanges and law enforcement; declines to pursue a freeze of the residual | (operator response) | + +## What defenders observed + +- **Pre-event (validation dropped in a fork, then carried through a migration).** The exposure was two commented-out checks in a forked module, preserved across the 2026-03-05 migration. Auditing a fork against its upstream, and re-auditing on every migration, is the pre-event control (T11.013). Secret publicly noted no external audit was requested for the Axelar integration. +- **At-event (mint without authorised source deposit).** The direct signature is a mint that does not reconcile to a confirmed, correctly-channelled source escrow. A runtime invariant tying every sa\* mint to a real Axelar-channel deposit, and rejecting packets from unrecognised channels, is the highest-leverage control for this class. +- **At-event (permissionless channel to a minting contract).** The attacker opened a channel straight to the bridge and self-relayed. A minting contract should pin the specific authorised channel/port and refuse deposits arriving over any other, rather than trusting an allow-list of denominations alone. +- **Detection (encrypted balances hid the loss for a week).** Secret's default balance encryption meant the missing collateral was not visible on explorers, and no monitoring or pause fired. Value-conservation monitoring that operates on the protocol's own encrypted accounting, independent of public explorer views, is the detection control. This is the same detection lesson as [`examples/2026-06-namada-masp-ibc-transfer-logic-shielded-drain.md`](2026-06-namada-masp-ibc-transfer-logic-shielded-drain.md), where shielded-pool opacity and a stale indexer also masked an IBC-boundary drain in the same month. + +## Public references + +- `[commonprefixsecret2026]` — Common Prefix, "Secret Network CW20-ICS20 Exploit: What Exactly Happened" (primary technical post-mortem; commented-out `parse_voucher_denom` / `reduce_channel_balance`, channel and Code IDs, per-asset losses, six-stage fund flow): +- `[theblocksecret2026]` — The Block, "Secret Network's Axelar bridge drained for \$4.67 million in infinite-mint exploit that went unnoticed for seven days" (\$4.67M, seven-day window, escrow-to-mint rework, audit-not-requested, residual figures): +- `[rektsecret2026]` — Rekt News, "Secret Network — Rekt" (independent breakdown; UTC timeline, ~2,350 ETH consolidation, exchange split, attacker addresses): +- `[cryptonewssecretaxelar2026]` — crypto.news, "Axelar shuts down Secret Network bridge routes after \$4.7M exploit" (Axelar official statement: core protocol and IBC not compromised, connections disabled, law-enforcement coordination): +- `[cryptopolitansecret2026]` — Cryptopolitan, "Axelar-bridged tokens worth \$4.67 million drained in Secret Network contract exploit" (mainstream corroboration of loss, mechanism, disclosure date): + +## Discussion + +Secret Network is a clean addition to OAK's T10.002 family because it isolates a specific sub-shape: a bridge that mints on packet receipt while verifying only the denomination, not the channel the packet arrived on or the escrow behind it. It sits next to Syscoin (proof-parsing ambiguity), Nomad (trusted root initialised to zero) and Wormhole (missing guardian-account validation) in the same class, contract-side message verification admitting a message it should reject, here in a Cosmos IBC mint-on-receipt form. The IBC detail that makes it worth preserving is that channel opening is permissionless, so the attacker could deliver forged packets to the contract directly; a minting contract that pins its authorised channel would have rejected them. + +The two properties that give the case durable teaching value are the legacy carry and the detection delay. The dropped checks shipped in 2023 and passed through a 2026 migration untouched, which is why T11.013 is co-primary rather than incidental: the same code that failed had been "maintained" without being re-audited against the checks it dropped. And because Secret encrypts balances by default, the drain was invisible on the layer most teams watch, so recognition came from an unrelated failed withdrawal a week later. Contributors writing future bridge examples should record both the mint-without-authorised-deposit invariant and the point that privacy-preserving accounting needs its own value-conservation monitoring, because explorer-based detection does not apply. The same-month Namada MASP drain is the sibling case for the detection lesson. diff --git a/index.html b/index.html index a22b9fa..54411a5 100644 --- a/index.html +++ b/index.html @@ -16,7 +16,7 @@ - + @@ -26,7 +26,7 @@ - + diff --git a/techniques/T10.002-message-verification-bypass.md b/techniques/T10.002-message-verification-bypass.md index c6c317b..93e806a 100644 --- a/techniques/T10.002-message-verification-bypass.md +++ b/techniques/T10.002-message-verification-bypass.md @@ -55,6 +55,7 @@ OAK classifies T10.002 separately from T9.004 (Access-Control Misconfiguration) - [`examples/2026-06-taiko-bridge-leaked-sgx-prover-key-forged-proof-withdrawal.md`](../examples/2026-06-taiko-bridge-leaked-sgx-prover-key-forged-proof-withdrawal.md) — Taiko bridge — Ethereum L1 ⇄ Taiko Alethia L2 — 2026-06-21 — ~$1.7M — T10.002 **TEE-attestation-signing-key-exposure sub-shape**; an RSA-3072 SGX prover signing key committed to the public `taikoxyz/raiko` repo let the attacker register a malicious prover and submit forged-but-correctly-signed L2-state proofs to the L1 Bridge/ERC20Vault. The verification predicate evaluated correctly — the trusted key itself was public. Composes T15.004 (leaked credential) → T10.002. Forward candidate: TEE-attestation-key exposure sub-technique. - [`examples/2026-06-aztec-deprecated-rollup-forged-proof-cohort.md`](../examples/2026-06-aztec-deprecated-rollup-forged-proof-cohort.md) — Aztec deprecated rollup infrastructure (cohort) — Ethereum — 2026-06 (≈06-14 + ≈06-17) — ~$4.3M combined — T10.002 **forged-proof / proof-data-manipulation** shape + T11.013; two immutable, abandoned Aztec products (Aztec Connect, deprecated 2023; Private Rollup Bridge, closed 2022) drained via falsified rollup proofs that released reserves; team had no admin and could not pause. - [`examples/2026-06-namada-masp-ibc-transfer-logic-shielded-drain.md`](../examples/2026-06-namada-masp-ibc-transfer-logic-shielded-drain.md) — Namada — Cosmos/IBC — 2026-06-19 — ~$600K — T10.002-adjacent **IBC-transfer-logic** flaw draining the Multi-Asset Shielded Pool (shielded-pool value-conservation bypass; mechanism pending Namada post-mortem); notable detection anti-pattern — a stale indexer masked the loss while live RPC showed zero. Forward candidate: shielded-pool IBC value-conservation bypass. +- [`examples/2026-06-secret-network-axelar-ics20-forged-ibc-packet-unbacked-mint.md`](../examples/2026-06-secret-network-axelar-ics20-forged-ibc-packet-unbacked-mint.md) — Secret Network / Axelar (Cosmos IBC), 2026-06-10, ~$4.67M; a forked CW20-ICS20 bridge contract with source-channel and escrow checks commented out accepted forged IBC packets over an attacker-opened permissionless channel, minting unbacked sa* tokens redeemed over the real Axelar route (co-primary T11.013 legacy carry from a 2023 deploy through a 2026-03 migration; encrypted balances masked the loss for ~7 days). Sibling detection case to Namada 2026-06. ## Reference implementations diff --git a/techniques/T11.004-insufficient-entropy-key-generation.md b/techniques/T11.004-insufficient-entropy-key-generation.md index 4355de3..88cae0c 100644 --- a/techniques/T11.004-insufficient-entropy-key-generation.md +++ b/techniques/T11.004-insufficient-entropy-key-generation.md @@ -41,6 +41,7 @@ T11.004's load-bearing operational property is the **half-life-of-known-vulnerab ### Additional incidents - [`examples/2022-2025-custody-infrastructure-compromise-cohort.md`](../examples/2022-2025-custody-infrastructure-compromise-cohort.md) — Custody infrastructure compromise cohort, 2022–2025; combined T11.003 + T11.004 cohort-level anchor +- [`examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md`](../examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md) — SecondFi Cardano web-wallet predictable key generation drain, 2026-06 (developing; first non-EVM / wallet-provider-software T11.004 anchor — confirmed mechanism, disputed \~129M ADA "custodian rescue" disposition) ## Reference implementations diff --git a/techniques/T15.002-supply-chain-vendor-pipeline-compromise.md b/techniques/T15.002-supply-chain-vendor-pipeline-compromise.md index 74c5780..1074f0f 100644 --- a/techniques/T15.002-supply-chain-vendor-pipeline-compromise.md +++ b/techniques/T15.002-supply-chain-vendor-pipeline-compromise.md @@ -52,6 +52,7 @@ T15.002 is **distinct from T11.002 (Wallet-Software Distribution Compromise)**. - [`examples/2024-2026-solana-npm-trader-key-exfiltration.md`](../examples/2024-2026-solana-npm-trader-key-exfiltration.md) — Solana NPM trader-key exfiltration — 2024–2026 — T15.002; Solana NPM package supply-chain attacks targeting trader signing keys - [`examples/2025-rekt-uncovered-incidents-cohort.md`](../examples/2025-rekt-uncovered-incidents-cohort.md) — 2025 Rekt.Uncovered Cohort — BigONE ($27M, CEX supply-chain attack via third-party vendor pipeline compromise) - [`examples/2026-05-nx-console-vscode-extension-supply-chain-compromise.md`](../examples/2026-05-nx-console-vscode-extension-supply-chain-compromise.md) — Nx Console VS Code extension — May 2026 — IDE-extension supply-chain sub-shape: trojanised `nrwl.angular-console` v18.95.0 (2.2M installs) executed a credential stealer on workspace open (GitHub/npm/AWS/Vault/K8s/1Password + `~/.claude/settings.json`), exfiltrated ~3,800 repos; entry via a chained TanStack credential leak; TeamPCP-claimed, CISA-alerted. Credential-harvest fan-out (no direct on-chain loss) cross-ref T15.004 / T11.009 +- [`examples/2026-06-polymarket-frontend-vendor-js-injection-approval-drain.md`](../examples/2026-06-polymarket-frontend-vendor-js-injection-approval-drain.md) — Polymarket, Polygon/Ethereum, 2026-06-25, ~$3.0–3.1M across ~11 wallets; a compromised third-party frontend vendor injected wallet-draining JavaScript into the live official site, which solicited fraudulent token approvals (co-primary T4.002); backend and contracts intact. Frontend-vendor sub-shape, distinct from the 2026-01 Polymarket trader-tooling npm campaign (T11.009). ## Reference implementations diff --git a/techniques/T4.004-allowance-approve-drainer.md b/techniques/T4.004-allowance-approve-drainer.md index 0f02854..acb0b94 100644 --- a/techniques/T4.004-allowance-approve-drainer.md +++ b/techniques/T4.004-allowance-approve-drainer.md @@ -53,6 +53,7 @@ T4.004 is one of the dominant flows in the modern wallet-drainer service ecosyst - [`examples/2023-2024-counterfeit-token-dust-attack-lure-cohort.md`](../examples/2023-2024-counterfeit-token-dust-attack-lure-cohort.md) — Counterfeit-token dust-attack lure cohort — 2023–2024 — T4.004 + T4.003; dust-token airdrop as allowance-drainer solicitation vector - [`examples/2024-06-walletconnect-multisig-drain.md`](../examples/2024-06-walletconnect-multisig-drain.md) — WalletConnect multisig drain — June 2024 — T4.004 + T4.006; WalletConnect-session-hijack chained to `approve`-allowance drain - [`examples/2024-08-discord-bookmark-drainer.md`](../examples/2024-08-discord-bookmark-drainer.md) — Discord bookmark drainer — 2024 — T4.004 + T4.007; social-engineering distribution of `approve`-allowance solicitation via Discord bookmark manipulation +- [`examples/2026-06-jaredfromsubway-mev-bot-counter-mev-honeypot-allowance-drain.md`](../examples/2026-06-jaredfromsubway-mev-bot-counter-mev-honeypot-allowance-drain.md) — jaredfromsubway.eth MEV bot, Ethereum, 2026-06-20, ~$7.5M; counter-MEV honeypot where ~66 counterfeit WETH/USDC/USDT contracts (T6.006) baited the bot's routing logic into leaving standing allowances that a coordinator swept via `transferFrom` in one transaction. Automated-victim / no-phishing sub-shape; inverts the 2023 jaredfromsubway.eth attacker entries. ## Reference implementations diff --git a/techniques/T6.008-verified-but-malicious-frontend-routing.md b/techniques/T6.008-verified-but-malicious-frontend-routing.md index c836fcb..7f974d1 100644 --- a/techniques/T6.008-verified-but-malicious-frontend-routing.md +++ b/techniques/T6.008-verified-but-malicious-frontend-routing.md @@ -54,6 +54,7 @@ Two distinguishable sub-patterns: - [`examples/2024-2025-uniswap-permit2-phishing-cohort.md`](../examples/2024-2025-uniswap-permit2-phishing-cohort.md) — Uniswap Permit2 phishing cohort, 2024–2025; ~$38M in Permit2-signature-based phishing losses across the broader ecosystem in 2024. Demonstrates the T6.008 sub-pattern where the extraction primitive is an off-chain Permit2 signature rather than an on-chain routing-manipulation transaction: the phishing frontend displays legitimate Uniswap branding and interacts with the real Permit2 contract, the user's wallet confirmation screen shows the verified Permit2 contract address, and the extraction occurs through the signature's spender-authorisation field (which the wallet UI does not surface in human-readable form). The most active and highest-loss Verification-Evasion phishing vector in the 2024–2025 window; structurally distinct from the routing-manipulation sub-pattern in the extraction layer (signature-authorisation manipulation vs calldata-path manipulation) while sharing the same verification-evasion structure - [`examples/2013-04-atlas-dns-bitcoin-hijack-phishing.md`](../examples/2013-04-atlas-dns-bitcoin-hijack-phishing.md) — Atlas DNS Bitcoin-domain hijack phishing campaign — Bitcoin — April 2013 +- [`examples/2026-06-eleven-drainer-legit-subdomain-frontend-compromise-cohort.md`](../examples/2026-06-eleven-drainer-legit-subdomain-frontend-compromise-cohort.md) — Gitcoin and Yield Yak (Ethereum / Avalanche), 2026-06-21 and 2026-06-24, losses undisclosed; the "Eleven drainer" kit was injected into legitimate project subdomains (`files.gitcoin.co`, `vote.yieldyak.com`), so a real project domain served a wallet drainer that solicited approvals on connect (co-primary T4.004; access vector undisclosed, candidate T15.004). Trusted-subdomain sub-shape, distinct from fake-clone frontends. ## Reference implementations diff --git a/techniques/T9.004-access-control-misconfiguration.md b/techniques/T9.004-access-control-misconfiguration.md index 2476a1a..819322a 100644 --- a/techniques/T9.004-access-control-misconfiguration.md +++ b/techniques/T9.004-access-control-misconfiguration.md @@ -136,6 +136,7 @@ OAK groups several sub-patterns under T9.004: - [`examples/2026-05-retoswap-haveno-arbitrator-ack-spoof-multisig-hijack.md`](../examples/2026-05-retoswap-haveno-arbitrator-ack-spoof-multisig-hijack.md) — RetoSwap / Haveno — May 2026 — ~$2.7M / ~7,000 XMR; "unauthenticated role-binding message" sub-shape: Haveno trusted the source address of an unverified ACK as the official arbitrator, letting a forged ACK rebind the arbitrator role and hijack the 2-of-3 trade multisig at instantiation (T11.003); Tor/Monero, untraceable - [`examples/2026-06-gnosis-pay-zodiac-delay-module-fallback-handler-bypass.md`](../examples/2026-06-gnosis-pay-zodiac-delay-module-fallback-handler-bypass.md) — Gnosis Pay — June 2026 — undisclosed loss (Gnosis to cover all); "trusted-module composition" sub-shape: a *legitimate, audited* Zodiac Delay Modifier v1.1.0 / Roles Modifier v2 could be driven to skip its cooldown/role gate when a Safe with a vulnerable fallback handler was enrolled as a module/role member (T11.003); fleet-wide blast radius across card Safes; core Safe contracts unaffected - [`examples/2026-06-tesseradao-tsr-admin-key-unauthorized-mint.md`](../examples/2026-06-tesseradao-tsr-admin-key-unauthorized-mint.md) — TesseraDAO ($TSR) — June 2026 — ~$2.5M; T11.002 + T9.004 + T5.001 + T7.001; "single key with no circuit-breakers" sub-class (Resolv restatement): open mint capability under one privileged key with no cap/timelock/multisig → 99M TSR minted → AMM dump → ~1,285.5 ETH via Tornado Cash +- [`examples/2026-06-myswap-cl-starknet-fake-token-shared-vault-accounting-drain.md`](../examples/2026-06-myswap-cl-starknet-fake-token-shared-vault-accounting-drain.md) — mySwap CL, Starknet, 2026-06-19, ~$300–305K (developing / preliminary mapping); a fake "EVIL" token abused a shared concentrated-liquidity vault's accounting to withdraw residual LP across 100,000+ positions. Token-admission / accounting-validation boundary failure; exact line-level bug undisclosed, forward candidate (untrusted-token shared-vault accounting abuse). ## Reference implementations