$680 Million Warning: Most DeFi Attacks Fall Outside Audit Scope

Author: Liam 'Akiba' Wright, cryptoslate

Compiled by: Chopper, Foresight News

In the decentralized finance space, "audited" is often seen as a security endorsement for the entire project. But in reality, audits typically cover only a specific point in time, designated code, components, and versions. Anything added, removed, or manipulated outside this scope may have a completely different audit outcome.

A new preprint paper puts concrete numbers on this gap. Researchers from security firm ack3 and the Czech Technical University in Prague analyzed 135 security incidents reported in the first half of 2025, which caused losses of up to $939.86 million. They found that 68 of these incidents had identifiable public pre-incident audit records.

Within this sample of 68 incidents, the researchers classified 46 attack paths as entirely outside any identifiable audit scope; 20 incidents were at least partially covered by an audit; and the remaining 2 could not be determined. Out-of-scope incidents accounted for 67.6% of the total number of incidents, but their corresponding losses accounted for 94.4% of the total reported losses.

This striking ratio is not an assessment of audit effectiveness, nor is it evidence that audit scope limitations caused the losses. It merely represents the loss distribution within the selected sample of public security incidents. Two exceptionally large incidents heavily influenced the data: after excluding the $292 million loss of Kelp DAO and the $285 million loss of Drift Protocol, the proportion of losses from out-of-scope attacks in the same audited sample dropped to 72.1%.

Even with these limitations, the study reveals a fundamental security trust issue: a project claims to have been audited, but users cannot know whether the actually running system, fund flows, and related control measures have been reviewed.

What the Data Really Means

ack3's research covers the period from January 1 to June 29, 2025, with a total of 122 confirmed attack incidents and 13 suspected incidents. In the entire sample, 35 incidents had no audit records found, and 32 had unknown audit histories; these two categories are not included in the statistics for the 68 incidents mentioned above.

In the sample of 68 incidents, out-of-scope incidents corresponded to losses of $680.97 million, with total losses of $721.24 million, yielding the 94.4% figure. After excluding Kelp DAO and Drift Protocol, out-of-scope losses were $103.97 million, with total losses of $144.24 million, a ratio of 72.1%. The dataset json file can reproduce the incident classification counts and loss amounts.

The "in-scope / out-of-scope" labels are judgments made by the researchers based on public evidence. The research team reviewed project and audit firm archives, found pre-attack audit reports, and compared the final attack path with the audited code, versions, and audit exclusions. The study is a 6-page preprint paper, produced jointly with the dataset publisher, and two of the authors are affiliated with the security audit firm ack3.

The study lacks a control group of unattacked projects and does not statistically account for the duration of exposure of each system. Therefore, it cannot prove that audited protocols are overall safer, cannot estimate incident probabilities, and cannot confirm that "out of audit scope" was the direct cause of every loss. Some undisclosed audits and private incidents may be missing, and the reported loss data is not fully comparable.

Therefore, the study can only draw limited conclusions: audit records and audit coverage are two independent indicators. An audited smart contract does not mean that contract upgrades, privileged keys, frontends, relays, oracles, cloud services, or emergency response processes receive the same level of security assurance.

Two incidents in August illustrate this distinction from different angles. The ICON Network case directly shows how two audited code segments failed at the boundary between two verification steps; while the August aelf security incident is another situation where existing audit evidence cannot yet map the attack's execution path to the pre-incident audit scope.

ICON Network: A Failure Sample at the Audit Boundary

In the ICON Network replay attack on August 27, two modules in the withdrawal chain interpreted the same message differently.

According to the ICON Foundation's post-incident review report: the migration contract relied on the high-order bits of the withdrawal message sequence number to determine message uniqueness; but the cryptographic signature only covered the lower 256 bits of the sequence number. The attacker modified the high-order bits not included in the signature verification, and within about 20 minutes, repeatedly submitted two legitimately signed withdrawal messages 1,492 times, of which 1,490 calls executed successfully.

This replay attack released 119.866 million ICX and 531,600 bnUSD. At the time of the review's publication, ICON confirmed a net loss of approximately 150.2 ETH plus 31,204 USDC. The foundation stated that 531,600 bnUSD and 1.366 million SODA assets had been recovered, and user deposits, account balances, and positions were unaffected.

ICON stated that this migration contract had undergone an external audit and that the audit recommendations had been implemented, including related modifications in the same module area; the corresponding relay logic had also undergone a separate specialized review. The Sodax development documentation audit list includes 8 reports covering different components, including the November 2025 Sodax relay audit report.

But the review report clearly states that this precise mismatch between the uniqueness verification logic and the signature verification value was not within the findings of the aforementioned audits. A simple "audited" project label cannot let users know whether the two ends of the withdrawal chain maintain consistent criteria for "message uniqueness."

The response timeline also exposes another type of boundary issue. ICON's first automated alert was triggered at 02:08 UTC, about 7 minutes after the attack began. Staff began investigating around 03:40, paused the affected contract at 03:53, and paused the entire network at 06:18:54.

From the first alert to complete emergency response, there was an interval of about 90 minutes. ICON attributed this to adjustments in the alert mechanism; the alert rule had generated a large number of false positives in past network connectivity failures, so it did not notify on-call staff with high priority. The foundation plans to deploy automatic shutdown triggers, lower circuit breaker thresholds, and conduct a specialized re-review of message uniqueness and replay protection.

Such risk control mechanisms cannot replace audits, but they answer another key question: when preventive measures fail, can the system quickly detect and isolate risks?

aelf: Security Assurance Requires Continuous Updates

aelf's security incident in August illustrates the above point from another angle. Public information describes a runtime intrusion and controlled recovery, but existing evidence is insufficient to determine whether the attack path fell within a specific pre-incident audit scope.

The project's official announcement explains: there was an unauthorized smart contract that could inject encoded .NET assemblies and instructions into the node execution chain via transaction parameters.

The preliminary investigation report attributes the incident to flaws in runtime reflection and dynamic loading verification, as well as insufficient isolation between the contract execution environment and sensitive nodes and infrastructure resources. aelf identified a total of 155 related transactions and 5 independent payload assemblies, with payloads capable of executing host commands, attempting external communication, accessing node keys, and infrastructure reconnaissance.

Having capabilities does not confirm that all payloads executed successfully, nor does it mean the attacker obtained all target credentials or that sensitive data was leaked. aelf stated that it has rotated signing keys and infrastructure credentials according to potential compromise standards.

As of September 11, this conclusion remains a preliminary judgment. aelf's official website blog has not published a specific update on this incident since August 26. The August 26 announcement promised to release updates and a final review later.

aelf's technical security documentation states that its blockchain and ELF token contracts have undergone multiple rounds of audits with no security issues found. But existing public pages cannot map the runtime path corresponding to the August attack to any pre-incident audit report. Therefore, characterizing the incident as an audit oversight or an out-of-scope failure lacks sufficient evidence.

This uncertainty itself is informative. A timestamped audit report gradually becomes disconnected from the current system code, dependency libraries, and actual operational status. Users need a versioned security record to reflect this difference.

This security record should specify: the audited repository and code commit version, deployed contract addresses, excluded components, privileged roles, dependency libraries; and also record post-audit contract upgrades, key custody and rotation mechanisms, runtime isolation policies, alerting and circuit breaker mechanisms, and timestamped asset recovery status, distinguishing confirmed losses, frozen assets, and unresolved risk exposures.

This is not to deny the value of audits, but to align audit claims with actual work content and link them to the currently running system.

An audit badge cannot answer: whether the audited components, the deployed system, and the mechanisms for responding to failures are still within the same security boundary.