1inch, a decentralized exchange aggregator, was the victim of a $5 million hack in March 2025. The attacker exploited a vulnerability affecting 1inch resolvers to steal the tokens before returning most of the funds after a negotiation with 1inch.
Inside the Attack
The 1inch attacker targeted resolvers, which are independent entities that fulfill orders within the 1inch ecosystem. The root cause of the incident was the fact that resolvers were using Fusion v1 in their contracts. This version is unsupported by 1inch and can’t be used for swaps with users, limiting the impacts of the attack to the vulnerable resolvers themselves.
The attacker exploited a vulnerability in Fusion v1 that permitted unintended executions of transactions. This vulnerability was part of the Settlement function of the v1 contract, which allows takers to resolve all pending, matched orders at the end of processing a transaction. This function should only be callable by the taker itself, but it was vulnerable to a calldata corruption vulnerability.
The attacker exploited a buffer overflow vulnerability in the low-level _settleOrder function. By using a long transaction, the attack was able to modify the value of the interactionLength variable. This value is used in an unsafe calculation to determine where the order suffix, which includes the resolver address, is located in some serialized data. By exploiting the buffer overflow, the attacker could use their own version of the order suffix, pretending to be the resolver and allowing them to swap a few wei for $5 million.
After the hack was discovered, 1inch and the affected resolver entered into negotiations with the attacker. As a result, the majority of the stolen assets were returned minus a bug bounty fee.
Lessons Learned from the Attack
The 1inch hack highlights a few important security lessons. The first is the importance of performing upgrades when possible. The resolver affected by this incident was still using Fusion v1, which was deprecated in 2023. While the code was not self-destructed to support backward compatibility, resolvers should have updated their contracts to use Fusion v2 long ago.
This hack also demonstrates the wide range of potential vulnerabilities that can exist in smart contracts. While this vulnerability mirrors heap exploitation vulnerabilities in traditional applications (and is common there), it’s an unusual exploit for a smart contract. This is likely also one reason that the vulnerable code was deployed despite numerous audits.
Finding tricky vulnerabilities like this requires expertise in both the Web2 and Web3 spaces. For help with securing your project, reach out to Halborn.