Worked example · 2023-02

Yearn iearnUSDT v1 deprecated-vault misconfiguration — Ethereum — 2023-02-02

Loss: approximately $11.6M at time of exploit. Industry write-ups (PeckShield, BlockSec, Halborn, SlowMist) consolidate around the ~$11.6M figure across affected stablecoins. The drained assets included DAI, USDC, USDT, TUSD, and BUSD across the affected vault and downstream stablecoin pools. Recovery negotiations were ongoing through 2023; partial recovery via attacker-initiated negotiation occurred but the bulk of proceeds remained unrecovered.
OAK Techniques observed: OAK-T9.004 (Access-Control / Configuration-Rot subclass — a deprecated v1 vault left in production with a stale fUSDT mapping in its share-token registry), with OAK-T9.002 (Flash-Loan-Enabled Exploit) as the working-capital precondition; OAK-T7.001 (Mixer-Routed Hop — proceeds were laundered through Tornado Cash).
Attribution: pseudonymous. No public named-individual attribution. Funding routed through Tornado Cash; recovery negotiations conducted via on-chain encrypted messages. No public OAK-G01 / state-actor attribution.
Key teaching point: **deprecated contracts left in production are a recurring T9.004 surface — configuration rot is a real failure mode and deserves first-class Mitigation attention.** The exploited vault was Yearn's v1 iearnUSDT (yUSDT), deployed in 2020 and superseded by Yearn v2's vault architecture in 2021–2022. The v1 vault was not actively used or marketed by Yearn at the time of the 2023 incident — but it remained on-chain, and its setUnderlying-style configuration left a stale mapping between its share token (yUSDT) and the underlying token (which was incorrectly set to fUSDT, a Fulcrum / bZx wrapper, rather than the intended Tether USDT). The misconfiguration was not novel to 2023; it had been present since 2020. The attacker's discovery in 2023 — three years after the deprecation — is the canonical OAK example of a vulnerability lying dormant in a deprecated production contract long enough that its existence had passed out of operator memory.

Summary

Yearn Finance's iearnUSDT v1 vault (yUSDT) was deployed on Ethereum in 2020 as part of Yearn's first-generation vault architecture. The vault was structurally simple: users deposited Tether USDT and received yUSDT shares; the vault routed deposits into yield strategies (Compound, Aave, dYdX) and shares were redeemable for the proportional share of the strategy-deployed USDT. In 2021–2022, Yearn migrated to v2 vaults with materially different architecture; the v1 vault was deprecated, no longer marketed, and its TVL drained to near-zero — but the contract remained deployed, the share token (yUSDT) remained mintable for anyone willing to interact directly with the contract, and the contract's internal configuration retained a stale mapping that was the seed of the eventual exploit.

The proximate cause — per PeckShield, BlockSec, Halborn, SlowMist post-incident write-ups, all converging on the same root-cause description — was that the v1 iearnUSDT vault's underlying-token mapping was stale: the contract's token reference did not point at the canonical Tether USDT contract but at a different token (in the literature this is consistently described as fUSDT, a Fulcrum / bZx-era wrapper). This stale mapping had been present since the contract's 2020 deployment and was a known artifact of Yearn v1's loose configuration discipline at the time. The mapping became weaponisable when an attacker, using flash-loaned working capital, deposited an arbitrary token (USDC, in the most-cited variant of the exploit) into the deprecated v1 vault — and because of the stale mapping, the share-issuance computation treated the deposit at a favourable ratio, returning yUSDT shares that could be redeemed against downstream stablecoin pools at multi-million-dollar profit.

Repeated across the affected stablecoin pools and scaled by flash-loaned working capital, the cycle drained ~$11.6M. The misconfiguration was not a new bug; it was a 2020-era artifact rediscovered in 2023.

For OAK's purposes the incident is a clean T9.004 (access-control / configuration-rot subclass) extraction with a T9.002 (flash-loan) precondition. The novel OAK contribution of the worked example is the configuration-rot-in-deprecated-contracts sub-pattern: a defender lesson distinct from the rescue-path-function sub-pattern visible at Platypus / Euler (2023) because the failure here is not a missing post-condition on a function intended for non-attack use, but a stale configuration on a deprecated contract that operator memory had effectively forgotten existed.

Timeline (UTC)

When	Event	OAK ref
2020	Yearn iearnUSDT v1 vault (`yUSDT`) deployed on Ethereum with stale fUSDT mapping in its underlying-token reference; loose configuration discipline characteristic of Yearn v1 era	T9.004 surface (latent since deployment)
2021–2022	Yearn migrates to v2 vault architecture; v1 vaults deprecated, no longer marketed; v1 TVL drains to near-zero; v1 contracts remain deployed and externally callable	(deprecation-without-decommission)
2023-02-02 (attack tx window)	Attacker takes flash loan; interacts directly with the deprecated v1 iearnUSDT vault; deposits USDC (in the most-cited variant); receives yUSDT shares at favourable ratio due to the stale fUSDT mapping; redeems yUSDT against downstream stablecoin pools (DAI, USDC, USDT, TUSD, BUSD); repays flash loan; nets ~$11.6M	T9.004 + T9.002 extraction
2023-02-02 (within hour)	Yearn operations and integrating-protocol operations teams detect the drain; investigate; identify the deprecated v1 vault as the entry vector	(operator response)
2023-02-02 onward	PeckShield, BlockSec, Halborn, SlowMist publish post-incident write-ups converging on the same stale-mapping root cause	(transparency)
2023-02-02 → 2023-Q2	Recovery negotiations conducted via on-chain encrypted messages; partial attacker-initiated returns	(recovery channel)
Continuing 2023	Yearn governance and integrating protocols coordinate on inventory of all deprecated v1 contracts and their decommission status	(cohort remediation)

What defenders observed

The exploit was reachable because the v1 vault was deployed, not because it was actively used. Yearn's active product surface in 2023 was v2; v1 had effectively zero TVL and no user-facing entry points. The exploit nonetheless was reachable because the v1 contract remained deployed, was directly callable from any address, and retained its 2020-era stale mapping. The defender lesson is deprecation-without-decommission is a real failure mode: a contract that no longer serves user traffic but remains deployed is still attack surface, and the absence of recent operator attention to that surface is itself an attractor for attackers performing systematic surface enumeration of dormant deployments.
The misconfiguration predated the exploit by approximately three years. This is OAK's longest-dwell-time T9.004 case in the v0.1 corpus. The defender lesson is that latent T9.004 surfaces do not heal; they wait. Operator-side mitigations that depend on "we will catch this in code review next time we touch the contract" do not engage if the contract is never touched again. Mitigations contributors writing on configuration-rot should treat dwell-time as a first-class severity-amplifier: a misconfiguration present for three years carries higher cumulative discovery risk than the same misconfiguration present for three days.
Flash-loaned working capital was the precondition that scaled the attack to its useful size. The per-iteration profit from depositing into a stale-mapping vault and redeeming downstream is bounded by the attacker's own capital. T9.002 converts the per-iteration profit into a single-transaction-window multi-million-dollar extraction. Defender monitoring focused only on the extraction Technique (T9.004) without the precondition (T9.002) misses half the structure.
Detection latency was operator-acceptable; recovery latency was effectively infinite for the bulk of proceeds. Yearn paused / advised on the affected pools within an hour. Recovery negotiations recovered a fraction; the residual remained unrecovered and entered Tornado Cash within days of the incident. This is the realistic expected-outcome shape for T9.004 cases without law-enforcement intervention.
The attribution is pseudonymous and is the realistic attribution status for this class. Funding was routed through Tornado Cash pre-event; no industry forensics provider has converted the on-chain analysis into a named-individual claim, and the recovery-negotiation channel was on-chain encrypted messaging without identifying off-chain hooks.

What this example tells contributors writing future Technique pages

T9.004 (Access-Control / Logic Misconfiguration) needs explicit sub-classification for the configuration-rot-in-deprecated-contracts sub-pattern. Canonical T9.004 (Parity multisig 2017, Wormhole guardian-set 2022) is "the access-control modifier was missing on a primary entry point at deployment". The 2023 Platypus / Euler sub-pattern is "the access-control post-condition was bypassed on a rescue-path / donation-path entry point". The Yearn v1 sub-pattern is structurally distinct from both: the configuration was wrong at original deployment (2020) on a contract that subsequently became deprecated, and the rediscovery of the misconfiguration three years later was the proximate event. T9.004 contributors should distinguish at-deployment-misconfiguration on actively-used contracts from at-deployment-misconfiguration on now-deprecated contracts, because the defensive baselines differ: the actively-used surface is monitored; the deprecated surface is not.
The defender-side Mitigation for the configuration-rot sub-pattern is complete-decommission discipline. When a protocol deprecates a contract version, the operational requirement is not just "stop marketing the v1 surface" but "either remove the contract from the deployment registry by upgrade/destruction or explicitly add it to a watchtower-monitored inventory of dormant-but-deployed surfaces, with documented configuration-state attestation". Either path is acceptable; neither path is the default; and Yearn v1 represents the "neither path" outcome — a deprecated contract that nobody was watching, with a misconfiguration that nobody was reviewing.
Configuration-rot is a cross-cutting Mitigations theme, not a Yearn-specific finding. The same shape recurs across DeFi: deprecated proxy contracts that retain admin keys; deprecated bridge endpoints that retain validator-set authority; deprecated oracle adapters with stale price-source pointers. Mitigations contributors should consider a cross-cutting Mitigation entry for "deprecated-contract decommission discipline" with Yearn v1 as the canonical T9.004-class worked example and parallel cases (where they exist) as cross-references.
Long-dwell-time T9.004 cases imply systematic-surface-enumeration attacker behaviour. A misconfiguration present for three years was not discovered in three years of opportunistic code review. The attacker's discovery in 2023 is more consistent with deliberate, systematic enumeration of dormant deployments than with chance discovery during routine integration review. This implies a defender threat-model addition: assume that motivated attackers periodically sweep the deployed-contract layer for mappings that no longer match canonical token addresses, and treat the existence of any deprecated-but-still-deployed contract as a finding worth justifying.

Public references

[peckshieldyearn2023] — PeckShield post-incident analysis covering the v1 vault stale-mapping exploit chain.
[blocksecyearn2023] — BlockSec forensic analysis of the Yearn v1 attack including the flash-loan + stale-mapping transaction-trace breakdown.
[halbornyearn2023] — Halborn post-incident technical write-up.
[slowmistyearn2023] — SlowMist incident analysis covering funding-source tracking and Tornado Cash routing.
[yearnpostmortem2023] — Yearn governance / operations post-incident statement and v1-decommission review.
[zhou2023sok] — academic taxonomy classifying configuration-misconfiguration as a primary DeFi vulnerability class.

Citations

[peckshieldyearn2023] — PeckShield Yearn v1 write-up.
[blocksecyearn2023] — BlockSec Yearn v1 forensic.
[halbornyearn2023] — Halborn Yearn v1 post-mortem.
[slowmistyearn2023] — SlowMist Yearn v1 funding-source analysis.
[yearnpostmortem2023] — Yearn governance post-mortem.
[zhou2023sok] — academic SoK classification.

Discussion

Yearn iearnUSDT v1 is OAK's reference case for the configuration-rot-in-deprecated-contracts sub-pattern of T9.004. The case is unusual in OAK's v0.1 corpus for its dwell time: the misconfiguration was present from 2020 and the exploit fired in 2023, a three-year latency that exceeds the typical T9.004 deploy-to-exploit window by an order of magnitude. The teaching point is structural: T9.004 surfaces do not heal on their own; they wait for systematic-surface-enumeration attacker behaviour or for incidental rediscovery, and the operator-side practices that catch newer-deployment misconfigurations (recent code review, recent integration testing, recent audit) do not engage on contracts that operator attention has long since rotated away from.

The deprecation-without-decommission failure mode is the analytically important feature. Yearn deprecated v1 in the user-facing sense — stopped marketing it, drained TVL, migrated documentation — but did not decommission v1 in the deployment-state sense. The contract remained externally callable, the share token remained mintable, and the stale mapping remained authoritative for anyone willing to interact with the deprecated surface directly. This is a recurring shape across DeFi: a contract version goes through a user-facing-deprecation lifecycle without going through a corresponding deployment-state-decommission lifecycle, and the deprecated surface remains attack-reachable for as long as the contract is deployed. Mitigations contributors should treat the two lifecycles as separate and require both for full deprecation.

Two open questions remain for OAK v0.x. First, whether the configuration-rot sub-pattern of T9.004 warrants its own Technique ID or stays within the broad T9.004 construction with sub-class footnoting. The author's lean is the latter for v0.1; if more long-dwell-time cases accumulate, v0.x can revisit. Second, whether OAK's Mitigations layer should distinguish "deprecation discipline" (user-facing) from "decommission discipline" (deployment-state) as separate Mitigation entries. The author's lean is yes — the Yearn case demonstrates that conflating the two is itself the failure mode worth flagging at Mitigation granularity.