Written by: Liam 'Akiba' Wright
Compiled by: Chopper, Foresight News
In the decentralized finance space, "audited" is often viewed as a security endorsement for the entire project. However, in reality, audits typically only cover specific points in time, designated code, components, and versions. Anything added, removed, or manipulated outside this scope may have completely different audit results.
A new preprint paper quantifies this gap. Security firm ack3 and researchers from the Czech Technical University in Prague analyzed 135 security incidents reported in the first half of 2026, resulting in losses as high as $939.86 million. They found that 68 of these incidents had identifiable, publicly available pre-attack audit records.
Within this sample of 68 incidents, researchers classified 46 attack paths as completely outside any verifiable audit scope; 20 incidents were at least partially within the scope of at least one audit; the remaining 2 could not be determined. Incidents outside the audit scope accounted for 67.6% of the total number of events in this sample, yet corresponded to 94.4% of the total reported losses.
This staggering proportion is not an assessment of audit effectiveness, nor evidence that audit scope limitations caused the losses. It merely represents the distribution of losses within the selected sample of publicly reported security incidents. Two特大 events heavily influence the data: after removing the $292 million Kelp DAO loss and the $285 million Drift Protocol loss, the share of losses caused by attacks outside the audit scope within the same audited sample drops to 72.1%.
Despite these limitations, this research reveals a fundamental trust issue in security: a project may claim to have been audited, but users cannot know whether the actually running system, the flow of funds, and the associated control mechanisms have been reviewed.
What the Data Really Means
ack3's study covers the period from January 1 to June 29, 2026, including 122 confirmed attack incidents and 13 suspected incidents. In the full sample, 35 incidents had no audit records found, and 32 had an unknown audit history; these two categories were not included in the above statistics for the 68 incidents.
In the sample of 68 incidents, attacks outside the audit scope corresponded to $680.97 million in losses, out of a total loss of $721.24 million, yielding the 94.4% figure. After removing Kelp DAO and Drift Protocol, losses from attacks outside audit scope were $103.97 million, with total losses of $144.24 million, constituting 72.1%. The dataset JSON file allows for reproduction of event classifications and loss amounts.
The "in-scope/out-of-scope" labels are judgments made by researchers based on publicly available evidence. The research team reviewed archived project and auditor documents, found audit reports predating the attacks, and compared the final attack paths with the reviewed code, versions, and audit exclusions. The study is a 6-page preprint paper co-published with the dataset publisher; two authors are affiliated with the security audit firm ack3.
The study lacks a control group of unattacked systems and does not account for the duration of risk exposure for each system. Therefore, it cannot prove that audited protocols are overall safer, estimate the probability of incidents, or confirm that "being outside audit scope" was the direct cause of each loss. Some undisclosed audits and private incidents may be missing, and the reported loss data may not be fully comparable.
Thus, the study can only draw a limited conclusion: audit records and audit coverage are two separate metrics. A reviewed smart contract does not imply that contract upgrades, privileged keys, frontends, relayers, 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 clearly shows a failure at the boundary between two pieces of reviewed code during two verification steps; the August aelf security incident is another case where existing audit evidence is currently insufficient to map the attack path to a pre-attack audit scope.
ICON Network: A Sample Failure at the Audit Boundary
In the ICON Network replay attack on August 27, two modules in the withdrawal pathway interpreted the same message differently.
According to the ICON Foundation's post-mortem report: the migration contract used 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. Attackers, by modifying the high-order bits not covered by the signature verification, repeatedly submitted two legitimately signed withdrawal messages 1492 times within about 20 minutes, with 1490 of those calls executing 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 audit recommendations had been implemented, including related modifications within the same module area; the corresponding relay logic had also been separately reviewed in a dedicated audit. The Sodax development documentation audit list includes 8 reports covering different components, including a Sodax relay audit report from November 2025.
However, the post-mortem report explicitly states that this specific mismatch between the uniqueness verification logic and the signature verification value was not within the scope of the findings in those audits. A simple "audited" project label cannot inform users whether the criteria for determining "message uniqueness" are consistent across both ends of the withdrawal pathway.
The response timeline also exposed another type of boundary issue. ICON's first automated alert triggered at UTC 02:08, approximately 7 minutes after the attack started. Staff initiated investigation around 03:40, paused the affected contract at 03:53, and paused the entire network at 06:18:54.
There was about a 90-minute interval between the first alert and the complete emergency response. ICON attributed this to adjustments in the alerting mechanism; this alert rule had generated numerous false positives during previous network connectivity issues and was therefore not configured to notify on-call personnel with high priority. The foundation plans to deploy automatic shutdown triggers, lower circuit-breaker thresholds, and conduct specialized reviews on message uniqueness and replay protection.
Such risk control mechanisms cannot replace audits, but they answer another critical question: when preventive measures fail, can the system quickly detect and isolate the risk?
Security Questions Users Still Need Clear Answers To
aelf: Security Assurance Needs Continuous Updates
The aelf security incident in August reinforces the above point from another angle. Public descriptions mention a runtime intrusion and controlled recovery, but existing evidence is insufficient to determine whether the attack path fell within the scope of a specific pre-incident audit.
The project's official announcement explains: an unauthorized smart contract existed that could, using transaction parameters, inject encoded .NET assemblies and instructions into the node execution pipeline.
The preliminary investigation report attributed the incident to flaws in runtime reflection and dynamic loading validation, coupled with insufficient isolation between the contract execution environment and sensitive node and infrastructure resources. aelf identified a total of 155 related transactions and 5 independent payload assemblies, with capabilities including executing host commands, attempting external communication, accessing node keys, and infrastructure reconnaissance.
Having capabilities does not confirm all payloads executed successfully, nor that attackers obtained all targeted credentials or that sensitive data was exfiltrated. aelf stated they have rotated signing keys and infrastructure credentials according to potential leak standards.
As of September 11, this conclusion remains interim. The aelf official blog has not published a dedicated update for this incident since August 26. The August 26 announcement promised subsequent updates and a final post-mortem.
aelf's technical security documentation states that its blockchain and ELF token contract have undergone multiple rounds of audits, with no security issues found. However, existing public pages cannot map the runtime path corresponding to the August attack to a specific audit report prior to the incident. Therefore, categorizing the incident as an audit oversight or an out-of-audit-scope failure lacks sufficient supporting evidence.
This uncertainty itself is informative. An audit report with a timestamp gradually becomes disconnected from the current system code, dependency libraries, and actual operational state. Users need a versioned security record to reflect this discrepancy.
This security record should clearly state: the reviewed repository and code commit version, deployed contract addresses, excluded components, privileged roles, dependency libraries; while also recording post-audit contract upgrades, key custody and rotation mechanisms, runtime isolation policies, alerting and circuit-breaker mechanisms, and time-stamped asset recovery status, distinguishing confirmed losses, frozen assets, and unresolved risk exposure.
This is not to negate the value of audits, but to align audit claims with the actual work done and connect them to the currently running system.
An audit badge cannot answer: whether the reviewed components, the deployed system, and the failure response mechanisms are still within the same security perimeter.
