1inch resolver-contract patch-not-propagated exploit — Ethereum + BNB Chain — 2025-03-05

Summary

1inch is a major DEX-aggregator protocol on Ethereum, BNB Chain, and several other EVM chains. Its Fusion architecture decouples order-routing logic from order-execution logic: end users submit Fusion orders that the 1inch core protocol routes, and a network of independent third-party resolvers compete to fill those orders by running their own resolver-contract deployments. Each resolver-operator deploys their own copy of the Fusion resolver contract and operates their own inventory; the 1inch core team publishes a reference implementation of the resolver contract that resolvers are expected to adopt and to keep up to date with published patches.

Prior to March 2025, the 1inch core team had identified a vulnerability in the Fusion resolver contract's logic, had patched the vulnerability in the published reference implementation, and had communicated the patch availability to the resolver integrator cohort. A subset of resolver-operators had adopted the patched version of the contracts. A subset had not.

On March 5, 2025, an attacker exploited the original vulnerability against a 1inch resolver-operator that was still running the pre-patch version of the Fusion resolver contract. Per the public forensic write-ups (PeckShield, BlockSec, and 1inch's own post-incident disclosure), the attack consisted of a crafted on-chain interaction against the unpatched resolver contract that triggered the original vulnerability and extracted approximately $5M from the resolver's inventory. End-user funds were not affected — the Fusion architecture isolates resolver-operator inventory from end-user balances, and the attacker's leverage was confined to the affected resolver's own assets.

The 1inch security team coordinated the affected resolver-operator's response, including an on-chain bounty offer for return of the extracted funds. The attacker accepted the offer; substantially full recovery followed. The affected resolver subsequently upgraded to the patched contracts, and the 1inch core team published an updated communication to the broader resolver cohort emphasising the adoption deadline for the patched contracts.

For OAK's purposes the structurally important feature is the patch-not-propagated-to-integrators pattern. The on-chain manifestation maps to T9.005, but the failure shape that is novel within the corpus is the cross-protocol distribution issue: a known-vulnerability-known-patch situation, where the surviving attack surface is the integrator cohort that has not adopted the patch.

Timeline (UTC)

When	Event	OAK ref
Pre-event	1inch core team identifies vulnerability in Fusion resolver-contract reference implementation; patches the issue in a published release	(responsible upstream remediation)
Pre-event	1inch communicates patch availability to the resolver-integrator cohort; subset of resolvers adopt patched contracts; subset do not	(patch-propagation gap forms)
Pre-event	Attacker either (a) monitors 1inch patch release and reverse-engineers the vulnerability from the patch diff, or (b) independently discovers the vulnerability; identifies unpatched-cohort resolver targets	(attacker preparation)
2025-03-05	Attack tx submitted against unpatched 1inch resolver deployment; crafted interaction triggers the original vulnerability and extracts ~$5M from the resolver-operator's inventory	T9.005 extraction (against unpatched cohort)
2025-03-05	Affected resolver-operator detects anomalous outflow; 1inch security team is notified and coordinates response	(operator + protocol-team response)
2025-03-05 → days following	Public on-chain bounty offer issued; attacker engages with the offer; negotiated return of the extracted funds at substantially full recovery	Recovery via bounty negotiation
2025-03 onward	Affected resolver upgrades to patched Fusion contracts; 1inch core team re-issues adoption-deadline communication to broader resolver cohort; public post-incident write-up published	(transparency, integrator-cohort follow-up)

What defenders observed

• The vulnerability was already patched upstream; the failure was downstream adoption. This is the structurally novel feature of the case. The 1inch core team had executed the responsible upstream side of the disclosure-and-patch lifecycle — vulnerability identified, fix engineered, published reference updated, integrators notified. The failure was at the integrator-adoption layer, where a subset of resolvers had not yet upgraded their deployed contracts to the patched version. Defender frameworks that focus exclusively on upstream protocol-team responsibilities under-document this surface; the 1inch-resolver case is the strongest 2025 case for treating integrator-side patch adoption as a first-class security control with explicit operational requirements.
• The patch-publication moment can amplify the residual attack surface. When the upstream protocol publishes a patch, the patch diff documents the original vulnerability. For an attacker monitoring the published patch stream, the upstream patch release is a discovery signal — the difficult half of finding the vulnerability has been done by the protocol team's audit-and-engineering effort, and the residual attacker work is to work back from the patch diff and identify which integrators have not yet adopted the fix. This is a real and recurring pattern across the broader patch-management literature; the 1inch-resolver case is its 2025 crypto worked example. Defender controls in this space include (a) coordinated-disclosure timing aligned with integrator-adoption windows, (b) integrator-cohort visibility into which deployments are or are not patched, and (c) explicit adoption-deadline mechanisms with consequences for non-adoption.
• The Fusion architecture's resolver-isolation property limited the loss to resolver-operator inventory. The affected loss was ~$5M from the resolver-operator's own assets; end-user Fusion-order balances were not at risk because the architecture isolates resolver-operator inventory from end-user state. This is a substantive defender-side property worth preserving: integrator-deployed contracts that hold their own inventory rather than user inventory limit the blast radius of a patch-not-propagated exploit to the integrator's own balance sheet, not to the end-user base. Contributors writing OAK Mitigation pages should call this out as an architectural mitigation: the resolver-isolation property is what prevented the 1inch case from being a much larger systemic event.
• The bounty-mediated recovery was supported by 1inch core-team coordination. The affected resolver was a single integrator with limited operational scale; the 1inch security team's involvement in the recovery negotiation provided credibility and reach that the integrator alone would have struggled to project. This is a defender-side dynamic worth preserving: integrator-cohort security is partly the protocol team's responsibility, even when the deployed contracts are integrator-controlled, and integrator-side incident response benefits from explicit upstream coordination support. The 1inch case is a positive 2025 reference for this coordination pattern.
• The attacker's selectivity is a behavioural signal of patch-monitoring or independent-discovery sophistication. The attacker did not target every 1inch resolver — they targeted unpatched deployments specifically. The on-chain signal of patched-versus-unpatched contract code is observable to anyone willing to read the deployed bytecode; the attacker had clearly read the deployed bytecode of the candidate targets and selected the unpatched ones. Defenders modelling attacker capability for this class should expect that the patch-monitoring + bytecode-reading combination is well within reach of the typical 2025 pseudonymous DeFi-exploit operator, and design integrator-cohort communications accordingly.

What this example tells contributors writing future Technique pages

• The patch-not-propagated-to-integrators failure shape deserves explicit recognition in OAK v0.x. The 1inch-resolver case is the canonical 2025 worked example for this pattern, but OAK v0.1 does not have a clean Technique-level mapping for it. T9.005 covers the on-chain manifestation; the cross-protocol patch-distribution dimension is the structurally novel feature. Contributors writing the OAK v0.x update should consider whether to (a) extend T9.005's framing to explicitly cover the patch-propagation sub-pattern, (b) introduce a new T9.x Technique scoped to integrator-cohort patch adoption, or (c) introduce a Mitigation-side framing that captures the upstream-coordination control. The 1inch case is the strongest single-case argument for one of these framings.
• Coordinated-disclosure timing is now a defender consideration in the crypto context. The traditional infosec literature on coordinated disclosure (CVE timelines, vendor-coordination windows, embargoes) maps imperfectly onto crypto integrator cohorts because the deployed code is on-chain and observable. Contributors writing OAK Mitigation pages on disclosure timing should account for this asymmetry: the upstream protocol team can patch quickly, but the integrator-cohort adoption can be slow, and the patch publication itself can amplify the residual attack surface against unpatched integrators. The 1inch case is the strongest 2025 evidence that this asymmetry is operationally consequential.
• Architectural isolation between integrator-operator inventory and end-user state is a meaningful mitigation, and should be documented as such. The Fusion architecture's resolver-isolation property is what limited the 1inch case to ~$5M of resolver-operator loss rather than a much larger end-user-balance event. Contributors writing OAK Mitigation pages should call out this architectural pattern as a first-class mitigation: integrator-deployed contracts that hold their own inventory rather than user inventory limit the blast radius of patch-not-propagated exploits.
• ~100% recovery via bounty negotiation, with upstream-protocol coordination support, is achievable. The 1inch-resolver case is a positive 2025 reference for the coordination-supported bounty-recovery pattern. The case pairs with KiloEx (April 2025, integrator-controlled negotiation) and ZKsync (April 2025, foundation-controlled negotiation) as the three 2025 examples of substantially-full recovery via negotiation, with different operator-versus-protocol-coordination shapes. Contributors writing recovery-rate documentation should preserve the coordination-shape distinction: protocol-team-led, foundation-led, and integrator-led negotiation patterns each have different credibility profiles and produce different attacker-acceptance dynamics.
• pseudonymous is the correct attribution status; the patch-monitoring sophistication does not upgrade attribution. As with the parallel April 2025 cases, the attacker's behavioural sophistication produced no off-chain identification. Contributors should not over-claim attribution simply because the attacker demonstrated patch-monitoring or bytecode-reading capability — these are baseline 2025 attacker skills, not identity signals.

Public references

• [1inchpostmortem2025] — 1inch Network's official post-incident communication describing the unpatched-resolver scope, the upstream patch availability, and the bounty-mediated recovery.
• [peckshield1inch2025] — PeckShield on-chain analytics and forensic walkthrough for the extraction transaction against the affected resolver, used as the cumulative-loss reference.
• [blocksec1inchresolver2025] — BlockSec forensic write-up emphasising the patch-not-propagated framing and the diff-based reverse-engineering attacker model.
• [chainalysis2025rug] for category-level context on 2025 DeFi-incident loss totals (used as the broad-context citation).

Discussion

The 1inch-resolver case is OAK's canonical 2025 case for the patch-not-propagated-to-integrators failure shape. The 2024–2025 corpus contains a substantial number of T9.005 worked examples, but the cross-protocol patch-distribution dimension is structurally novel within the corpus. Earlier T9.005 cases were typically unknown-vulnerability events — the failure was discovered at the time of exploitation, with no prior upstream patch. The 1inch-resolver case is the 2025 case that establishes known-vulnerability-against-unpatched-integrators as a first-class threat shape worthy of its own defender-handbook treatment.

The asymmetry between upstream patch-publication speed and integrator-side adoption speed is the structural feature worth preserving. A protocol's core team can engineer and publish a fix quickly; the integrator cohort running independent deployments adopts the fix on its own operational schedule, which is generally slower and more variable. Between patch publication and full integrator adoption, the surviving unpatched cohort is in a worse-than-pre-publication state, because the published patch documents the vulnerability for any attacker willing to read the diff. This is a recognised pattern in the broader patch-management literature — it is sometimes referred to as the "patch-gap" or "n-day window" — and the 1inch-resolver case is its canonical 2025 crypto worked example.

The architectural-isolation property is the second-order observation worth preserving. The 1inch Fusion design isolates resolver-operator inventory from end-user state by construction; the affected loss was $5M of resolver-operator capital, not a multiple of that figure of end-user balances. This is a substantive mitigation: integrator-deployed contracts that hold their own inventory limit the blast radius of patch-not-propagated exploits to the integrator's own balance sheet. Contributors writing OAK Mitigation pages should preserve this design pattern as a first-class architectural mitigation.

The bounty-mediated recovery with upstream-protocol coordination support is the third-order observation. The 1inch core team's involvement in the recovery negotiation was load-bearing for the outcome — the affected resolver alone would have struggled to project the credibility and reach necessary for a successful negotiation. This is a positive defender-side reference for coordination shape in integrator-cohort incident response: even when the affected contracts are integrator-controlled, the upstream protocol team has both the credibility and the operational leverage to support a productive recovery negotiation, and should be willing to do so. The 1inch case is the 2025 reference for this coordination pattern.

For OAK's broader credibility, including the 1inch-resolver case in v0.1 closes one gap: it adds a patch-not-propagated-to-integrators worked example to a corpus that has under-documented this cross-protocol failure shape, and it pairs with the broader 2025 negotiation-recovery cluster (KiloEx, ZKsync, Loopscale) to bracket the operational variants of bounty-mediated recovery for the year.