$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. However, audits typically only cover specific points in time, designated code, components, and versions. Any additions, deletions, or operations outside this scope may yield completely different audit results.

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

Among these 68 incidents, researchers classified 46 attack paths as completely outside any verifiable audit scope; 20 incidents were covered by at least one audit; and the remaining 2 could not be determined. Events outside the audit scope accounted for 67.6% of the total incidents, yet the corresponding loss amount represented 94.4% of the reported total losses.

This astonishing ratio is not an assessment of the effectiveness of audits, nor is it evidence that the limitations of audit scopes lead to losses. It merely represents the distribution of losses within the selected sample of public security incidents. Two major incidents significantly impacted the data: excluding the $292 million loss from Kelp DAO and the $285 million loss from Drift Protocol, the proportion of losses from attacks outside the audit scope in the audited sample dropped to 72.1%.

Despite these limitations, the study reveals a fundamental security trust issue: a project may claim to be audited, but users cannot ascertain whether the actual operating system, fund flows, and related control measures have been reviewed.

The Real Meaning of the Data

The ack3 study covers the period from January 1 to June 29, 2026, with a total of 122 confirmed attack incidents and 13 suspected incidents. Among all samples, 35 incidents could not find audit records, and 32 had unknown audit histories, both of which are not included in the statistics of the aforementioned 68 incidents.

In the sample of 68 incidents, losses from events outside the audit scope amounted to $680.97 million, with total losses of $721.24 million, leading to the figure of 94.4%. After excluding Kelp DAO and Drift Protocol, losses outside the audit scope were $103.97 million, with total losses of $144.24 million, accounting for 72.1%. The dataset's JSON file can reproduce the classification of incidents and loss amounts.

The "in/out of audit scope" label is a judgment made by researchers based on public evidence. The research team reviewed project and audit firm archives, found audit reports prior to the attacks, and compared the final attack paths with the reviewed code, versions, and audit exclusions. This study is a 6-page preprint paper produced in collaboration with the data set publisher, with two authors affiliated with the security audit firm ack3.

The study lacks a control group of non-attacked systems and does not account for the duration of exposure to risks across systems. Therefore, it cannot prove that audited protocols are overall safer, estimate the probability of incidents, or confirm that "beyond audit scope" is a direct cause of each loss. Some undisclosed audits and private incidents may be missing, and the reported loss data may not be entirely comparable.

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

Two incidents in August corroborated this distinction from different angles. The ICON Network case intuitively demonstrated that two segments of audited code failed at the boundaries of two verification stages; while the August aelf security incident presented another situation where existing audit evidence could not map the attack path to the pre-audit scope.

ICON Network: Failure Sample at the Review Boundary

In the August 27 replay attack on ICON Network, two modules in the withdrawal link had a disagreement on the interpretation of the same message.

According to the post-mortem report from the ICON Foundation: the migration contract relied on the high-order bits of the withdrawal message sequence number to determine message uniqueness; however, the cryptographic signature only covered the lower 256 bits of the sequence number. The attacker modified the high-order bits, which were not included in the signature check, and within about 20 minutes, resubmitted two legally signed withdrawal messages 1492 times, of which 1490 calls executed successfully.

This replay attack released 119.866 million ICX and 531,600 bnUSD. At the time of the post-mortem release, 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 external audits and implemented audit recommendations, including relevant 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 Sodax relay audit report from November 2025.

However, the post-mortem report clearly states that the mismatch between the uniqueness verification logic and the signature verification value was not within the scope of the above audit findings. A simple "audited" project label does not inform users whether the two ends of the withdrawal link maintain consistent standards for "message uniqueness".

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

There was approximately a 90-minute gap between the first alert and complete emergency response. ICON attributed this to adjustments in the alert mechanism, as this alert rule had generated numerous false positives in past network connectivity failures and therefore did not notify on-duty personnel with high priority. The foundation plans to deploy an automatic shutdown trigger mechanism, lower the circuit breaker threshold, and conduct a special review of message uniqueness and replay protection.

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

Users Still Need to Clearly Answer Security Questions

The aelf security incident in August corroborated this viewpoint from another angle. Public information describes runtime intrusion and controllable recovery, but existing evidence is insufficient to determine whether the attack path fell within the pre-specified audit scope.

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

The preliminary investigation report attributed the incident to flaws in runtime reflection and dynamic loading checks, 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 capabilities to execute host commands, attempt external communication, access node keys, and conduct infrastructure reconnaissance.

Having capabilities does not equate to confirming that all payloads executed successfully, nor does it imply that the attacker obtained all target credentials or that sensitive data was leaked. aelf stated that it had rotated signature keys and infrastructure credentials according to potential leakage standards.

As of September 11, this conclusion remains a preliminary judgment. The aelf official blog has not published any special updates regarding this incident since August 26. The August 26 announcement promised subsequent updates and a final review.

The aelf technical security documentation states that its blockchain and ELF token contracts have undergone multiple rounds of audits, with no security issues found. However, the existing public page cannot correlate the runtime path of the August attack with any specific audit report prior to the incident. Therefore, classifying the incident as an audit oversight or an out-of-scope failure lacks sufficient evidence to support.

This uncertainty itself holds reference significance. An audit report with a timestamp will gradually become 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 reviewed repository and code submission version, deployed contract address, excluded components, privileged roles, dependency libraries; while also recording contract upgrades, key custody and rotation mechanisms, runtime isolation strategies, alert and circuit breaker mechanisms, and timestamped asset recovery status, distinguishing confirmed losses, frozen assets, and unresolved risk exposures.

This does not negate the value of audits but aims to align audit promotion with actual work content and relate it to the currently operating system.

An audit badge cannot answer whether the reviewed components, deployed systems, and fault response mechanisms remain within the same security boundary.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.