$680M lost in DeFi hacks outside audit scope in H1 2026

Written by Liam 'Akiba' Wright

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 cover only specific code, components, and versions at a particular point in time. Any additions, deletions, or modifications outside this scope may result in entirely different audit outcomes.

A new preprint paper provides specific figures for this gap. The security firm ack3, in collaboration with researchers from the Czech Technical University in Prague, analyzed 135 security incidents reported in the first half of 2026, which resulted in losses of up to $939.86 million. They found that 68 of these incidents had identifiable public pre-audit records.

Of the 68 incident samples, researchers classified 46 attack paths as entirely outside the scope of any available audit; 20 incidents were covered by at least one audit; and the remaining 2 were undeterminable. Incidents occurring outside audit scope accounted for 67.6% of total incidents but represented 94.4% of the reported financial losses.

This striking proportion is not an assessment of audit effectiveness, nor is it evidence of losses resulting from scope limitations in audits. It merely represents the distribution of losses within the selected sample of public security incidents. Two massive incidents have a significant impact on the data: after excluding the $292 million loss from Kelp DAO and the $285 million loss from Drift Protocol, the percentage of losses caused by attacks outside the audit scope in the same group of audited samples drops to 72.1%.

Even with the aforementioned limitations, this study reveals a fundamental security and trust issue: a project claims to have been audited, but users cannot determine whether the actual running system, fund flows, or related controls have been reviewed.

This study by ack3 covers 122 confirmed attacks and 13 suspected incidents from January 1, 2026, to June 29, 2026. Of all samples, 35 incidents had no audit records found, and 32 had unknown audit histories; these two categories are not included in the above count of 68 incidents.

Out of 68 incident samples, incidents outside the audit scope resulted in losses of $680.97 million, with total losses amounting to $721.24 million, yielding the figure of 94.4%. After excluding Kelp DAO and Drift Protocol, losses outside the audit scope amounted to $103.97 million, with total losses at $144.24 million, accounting for 72.1%. The dataset json file can reproduce the number of incident classifications and loss amounts.

The "Within Scope / Out of Scope" labels are judgments made by researchers based on publicly available evidence. The research team reviewed project records and audit firm archives to locate audit reports issued prior to the attack, then compared the final attack path with the audited code, versions, and excluded items. This research is a 6-page preprint paper produced in collaboration with the dataset publisher, with both authors affiliated with the security audit firm ack3.

The study lacks a control group of unattacked systems and does not measure the duration of exposure risk for each system. Therefore, it cannot demonstrate that audited protocols are overall more secure, estimate the probability of incidents, or confirm that "out-of-scope" issues were the direct cause of every loss. Some unpublicized audits and private incidents may be missing, and the reported loss data is not fully comparable.

Therefore, this study can only draw limited conclusions: audit records and audit coverage are two separate metrics. An audited smart contract does not guarantee equivalent security for contract upgrades, privileged keys, frontends, relayers, oracles, cloud services, or incident response procedures.

Two incidents in August illustrated this distinction from different perspectives. The ICON Network case clearly showed a failure at the boundary between two review stages, where two audited code segments interacted; in contrast, the August aelf security incident was different, as existing audit evidence has not yet been able to map the attack’s execution path to the pre-audit scope.

During the August 27 ICON Network replay attack, two modules in the withdrawal pathway 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; 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 signature verification, and replayed two legitimately signed withdrawal messages 1,492 times within approximately 20 minutes, with 1,490 of the calls successfully executed.

The replay attack released 119.866 million ICX and 531,600 bnUSD. Upon 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 have been recovered, and user deposits, account balances, and positions remain unaffected.

ICON states that this migration contract has completed external auditing and has implemented the audit recommendations, including related modifications within the same module area; the corresponding relay logic has also undergone a dedicated review. The Sodax development documentation audit list includes eight reports covering different components, including the Sodax relay audit report from November 2025.

However, the retrospective report states that this precise mismatch between the uniqueness verification logic and the signature verification value is not within the scope of the aforementioned audit findings. A simple "audited" project label does not inform users whether the criteria for "message uniqueness" are consistent across both ends of the withdrawal pathway.

The response timeline also reveals another class of boundary issues. ICON’s first automated alert was triggered at 02:08 UTC, approximately seven minutes after the attack began. Staff initiated an investigation around 03:40, paused the affected contract at 03:53, and halted the entire network at 06:18:54.

There was approximately a 90-minute gap between the initial alert and full incident resolution. ICON attributes this to an adjustment in the alerting mechanism, as the alert rule had generated numerous false positives during previous network connectivity issues and was therefore not prioritized for immediate notification to on-call personnel. The foundation plans to deploy an automated shutdown trigger, lower the circuit breaker threshold, and conduct a dedicated review of message uniqueness and replay protection.

This type of risk control mechanism cannot replace auditing, but it answers another critical question: when preventive measures fail, can the system quickly detect and isolate risk?

Users still need to answer the security questions clearly.

The security incident involving aelf in August further supports the above perspective from another angle. Public records describe a runtime intrusion with controlled recovery, but existing evidence is insufficient to determine whether the attack vector fell within the scope of pre-incident audits.

Official project announcement: An unauthorized smart contract exists that can leverage transaction parameters to inject encoded .NET assemblies and commands into the node execution pipeline.

The preliminary investigation report attributes the incident to defects in runtime reflection and dynamic loading validation, as well as insufficient isolation between the contract execution environment and sensitive nodes and infrastructure resources. aelf identified 155 related transactions and five independent payload assemblies, each capable of executing host commands, attempting outbound communication, accessing node keys, and conducting infrastructure reconnaissance.

Having the capability does not confirm that all payloads were successfully executed, nor does it indicate that the attacker obtained all target credentials or that sensitive data has been exfiltrated. aelf stated that it has rotated signature keys and infrastructure credentials in accordance with potential breach standards.

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

The aelf technical security document states that its blockchain and ELF token contract have undergone multiple rounds of audits with no security issues found. However, the current public pages do not allow correlation between the runtime path associated with the August attack and any audit report prior to the incident. Therefore, there is insufficient evidence to classify the event as either an audit oversight or a failure outside the audit scope.

This uncertainty itself holds reference value. A timestamped audit report gradually becomes disconnected from the current system code, dependencies, and operational status. Users need a versioned security record to reflect these discrepancies.

This security record should specify: the reviewed repository and code commit versions, deployed contract addresses, excluded components, privileged roles, and dependencies; it should also document contract upgrades after the audit, 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 is not about denying the value of audits, but about aligning audit communications with the actual work being done and connecting them to the systems currently in operation.

A single audit badge cannot answer whether the reviewed components, deployed systems, and failure response mechanisms still reside within the same security boundary.