Full Report
1Inch is a limit order swap DeFi platform. 1Inch Fusion is a gasless swap protocol built on top of the core Limit Order Protocol. This version was deprecated in 2023 but was kept alive for backwards compatibility reasons. The original implementation had over 9 audits. Recently, the V1 protocol was hacked. Looking at the exploit transactions, it starts off looking very normal. Then, came a red flag: both the taker and the maker on the swap were the same. Additionally, the attacker had made over 1M USDC on the trade. Upon trying to make the Settlement of the limit order, a call to resolveOrders is made to a contract. This code appeared to be very similar to the example integration and looked pretty safe. Upon closer inspection, the victim contract had not updated the protocol even when the interfaces had changed. The vulnerability appears to be around lack of validation on resolver. This is a NOT intended to be a controlled element of settleOrder. In fact, it's passed in with new bytes(0) since only the contract itself should be able to set it. How was this controlled? What gives? The woes of multiple versions! Much of this code is written in Yul, the Assembly of Solidity. In the Yul, there is a ptr. When writing a value called the suffix, it's written at an offset depending on the passed in interactionLength. interactionLength is a full 32 byte word, which can overflow when doing ptr + interactionOffset + interactionLength. Because of this overflow, the pointer can be decreased to write the user controlled suffix to any location! Sounds like memory corruption! Here's the full flow of the attack: Create a swap order that swaps a few wei for millions. Normally, this would obviously be rejected. Specify an invalid interactionLength value to overflow to point to the resolver address. Add a fake suffix structure to overwrite the resolver address. The authors of this post did the internal investigation but also did several of the audits on the protocol. So, what happened? Initially, the resolver contract code wasn't in scope for audits, so it was ignored. In March of 2023, these auditors actually found the integer overflow while assessing the scope. However, shortly after, the code was completely rewritten so they didn't feel it was necessary to callout. Here's the interesting twist: this previous version of the contract had already been deployed and the auditors didn't know it. Additionally, they were unsure about the impact of the vulnerability, so they moved on from it. How can we prevent this type of thing from happening in the future? Clearly defined what code is being used. It's acceptable to have multiple versions but both need to be audited. Informational findings are helpful. There may be more impact of something than an auditor initially realizes. Overall, a super cool postmortem on the exploitation of this vulnerability. The vulnerability is unique and I love the analysis on how this slipped through the cracks.
Analysis Summary
# Vulnerability: 1Inch V1 Calldata Corruption Leading to Arbitrary Resolver Overwrite
## CVE Details
- CVE ID: Not specified in the source material.
- CVSS Score: Not specified in the source material. (Likely High/Critical given the impact)
- CWE: CWE-190 (Integer Overflow or Wraparound), CWE-824 (Access of Uninitialized Memory) - Due to pointer manipulation within memory.
## Affected Systems
- Products: 1Inch Limit Order Protocol (Specifically the V1 Settlement contract).
- Versions: The deprecated V1 protocol still active for backwards compatibility.
- Configurations: Victim contracts using the V1 protocol that had not updated their interfaces to match the protocol's evolved structure, specifically when handling the `resolveOrders` call during settlement.
## Vulnerability Description
The vulnerability resided in the deprecated 1Inch Settlement V1 contract, written substantially in Yul (Solidity Assembly). The flaw involved an integer overflow during the processing of the order suffix data, specifically affecting the calculation of a memory pointer.
When setting data at an offset derived from `interactionLength`, an integer overflow occurred in the calculation: `ptr + interactionOffset + interactionLength`. This overflow allowed the attacker to decrease the effective pointer address. By manipulating the input data, the attacker could overwrite a critical memory location—specifically the address intended for the order resolver contract—with an address of their choosing.
This allowed the attacker to specify an arbitrary contract address as the `resolver` during the `settleOrder` execution, bypassing the intended security mechanism where the resolver should only be set by the contract itself (often passed as `bytes(0)` in a controlled flow).
## Exploitation
- Status: **Exploited in the wild** (Reported on March 5, 2025, resulting in loss of funds, later mostly returned after negotiation).
- Complexity: Medium to High (Requires deep understanding of Yul memory layout and calldata manipulation for the pointer overflow).
- Attack Vector: Network (Remote transaction submission).
## Impact
- Confidentiality: None specified, though control over execution flow could imply this.
- Integrity: **High**. The attacker successfully directed settlement logic to an arbitrary contract, leading to unauthorized movement of assets (USD 1M in losses initially reported for the market maker).
- Availability: Low (The core protocol remained functional, but a specific version suffered a major exploit).
## Remediation
### Patches
- The primary fix involves ensuring the V1 protocol is retired or that all dependent contracts update to use the newer, patched protocol structure, eliminating reliance on the vulnerable V1 implementation.
- The specific fix within the V1 code would involve adding robust bounds checking to prevent the pointer arithmetic overflow, regardless of the source of `interactionLength`.
### Workarounds
- **Immediate Action:** Downgrade or cease use of the 1Inch V1 Settlement contract entirely and migrate to newer, audited versions of the protocol.
- **Audit Scope Correction:** Ensuring that all external integration points, even deprecated ones, remain within the scope of ongoing security assessments if they are still operational.
## Detection
- **Indicators of Compromise (IOCs):**
- Limit order settlements where the order maker, taker, and invoked resolver contract appear to be the same or controlled by the same entity (as seen in the initial red flag).
- Transactions involving the V1 Settlement contract that utilize highly irregular or unexpected values for data structures related to order suffixes, interaction lengths, or resolver callbacks.
- **Detection Methods and Tools:** Monitoring contract execution traces for unusual memory pointer offsets or unexpected invocation of external contracts during the `resolveOrders` phase of settlement logic within the V1 contract address range.
## References
- Vendor Advisories: None explicitly named, but the postmortem was published by auditors who investigated the incident.
- Relevant links:
- Postmortem reference (defanged): hxxps://blog[dot]decurity[dot]io/yul-calldata-corruption-1inch-postmortem
- Example Attack Transaction (defanged): hxxps://etherscan[dot]io/tx/0x04975648e0db631b0620759ca934861830472678dae82b4bed493f1e1e3ed03a