blockchain vulnerabilities

A new analysis of 135 DeFi incidents in the first half of 2026 reveals that audited protocols lost $885 million to attacks that fell outside their audit scopes, exposing a critical gap between what “audited” claims and what users actually know about their security. The finding highlights that audit reports cover only specific code, versions and components at a single point in time, leaving upgrades, operational controls and infrastructure changes unreviewed.

• Of 68 incidents with identifiable pre-incident audits, 46 attack paths fell outside every audit scope, representing 94.4% of losses totaling $680.97 million.
• Two major incidents dominated the outside-scope losses: Kelp DAO ($292 million) and Drift Protocol ($285 million); excluding them still left 72.1% of audited-incident losses outside scope.
• The research exposes a fundamental assurance problem: projects can truthfully claim audit status while leaving users unable to determine whether the live system, the fund-holding code path and incident response controls were actually reviewed.

• $939.86M Total attributed losses across the 135 incidents examined in the study
• 67.6% Outside-scope incidents as a percentage of reviewed incident count overall
• 94.4% Outside-scope incidents as a percentage of total losses in audited incidents
• 72.1% Outside-scope loss percentage after removing Kelp DAO and Drift Protocol

Researchers affiliated with security firm ack3 and Czech Technical University in Prague analyzed 135 reported DeFi incidents from January 1 through June 29, 2026, with $939.86 million in attributed losses. They identified public pre-incident audits for 68 of those incidents and classified each attack path as either inside, outside or unresolved relative to the audit scope. The dataset revealed a stark disparity: while outside-scope incidents represented 67.6 percent of the 68-incident subset, they accounted for 94.4 percent of the $721.24 million in reported losses from that group, or $680.97 million.

The research underscores a widening trust problem in the DeFi industry. As decentralized finance has grown, security audits have become a standard marketing tool and user reassurance mechanism. Yet the analysis reveals that many breaches exploit attack vectors that auditors never examined, either because those vectors emerged after the audit, involved operational infrastructure rather than code, or exploited interactions between audited components and unreviewed systems. The result is that audit reports, while valuable, provide a false sense of completeness to the average user.

The Audit Scope Problem Exposed Through A Message Uniqueness Mismatch

The ICON Network incident of August 27 provides a direct case study in how audited code can fail at unreviewed boundaries. In a replay attack, two parts of a withdrawal path interpreted the same message differently: a migration contract used the high bits of a withdrawal message’s serial number to decide uniqueness, while the cryptographic signature covered only the low 256 bits. By modifying the unsigned high bits, an attacker resubmitted the same legitimately signed withdrawal messages 1,492 times over roughly 20 minutes, with 1,490 calls succeeding.

The attack released 119.866 million ICX and 531,600 bnUSD. ICON Foundation’s August 30 postmortem confirmed net losses of approximately 150.2 ETH plus 31,204 USDC, though the foundation noted that 531,600 bnUSD and 1.366 million SODA were recovered and user deposits and positions were not affected. ICON stated that the migration contract had undergone external audit with recommendations implemented, and that the relay logic received dedicated review, with eight audit reports across different components listed in the SODAX archive including a November 2025 relay audit.

The postmortem revealed that the precise mismatch between the uniqueness check and the signed value fell outside those findings, demonstrating how a project-level audit badge cannot tell users whether both ends of a withdrawal path agreed on what made a message unique.

This type of boundary vulnerability is common in complex systems. Two independently audited components may receive thorough review of their internal logic while the assumptions each makes about the other go unexamined. An auditor reviewing Contract A might assume that Contract B will enforce a particular invariant, while the auditor reviewing Contract B makes the opposite assumption. Neither audit catches the gap because both reports focus on isolated components rather than their interaction.

Detection And Response Gaps Extended ICON’s Exposure By 90 Minutes

Beyond the code-level boundary, ICON’s incident response timeline exposed another kind of assurance gap. The network’s first automated alert fired at 02:08 UTC, roughly seven minutes after the exploit began, yet staff did not open an investigation until 03:40 and did not pause the affected contract until 03:53. Full network halt did not occur until 06:18:54, a roughly 90-minute gap that ICON attributed to alert tuning.

The alert class had generated false positives during unrelated connectivity incidents and did not page the on-call team at the required severity level.

ICON stated that it planned an automatic shutdown trigger, lower circuit-breaker thresholds and a follow-up review focused on message uniqueness and replay guards. The foundation acknowledged that such controls do not replace an audit but instead provide evidence for a different question: when prevention fails, how quickly can detection become containment. This distinction underscores that assurance requires tracking not only reviewed code but also the operational machinery meant to stop it if that code fails.

Operational controls represent a critical but often overlooked dimension of security. An audit may verify that code is written correctly, but if alert systems are misconfigured or on-call response procedures are slow, an attacker can exploit even well-audited vulnerabilities before anyone notices. The 90-minute window between the first alert and network halt illustrates how infrastructure and operational decisions can amplify the damage from a code-level flaw.

The aelf August Incident Shows Why Audit Evidence Must Remain Current And Specific

aelf’s August incident tests the audit-scope question from an opposite direction, illustrating why dated audit claims can become detached from live systems. On August 18, aelf announced a network pause. In its August 26 progress update, the company disclosed that an unauthorized smart contract could use transaction parameters to deliver encoded .NET assemblies and instructions into the node execution path, provisionally linked to gaps in checks for runtime reflection and dynamic loading and weak isolation between contract execution and sensitive node or infrastructure resources.

aelf identified 155 associated transactions and five unique payload assemblies with capabilities including host command execution, attempted outbound communication, node-key access and infrastructure reconnaissance. Critically, capability is not the same as confirmed execution; aelf stated that the payloads did not prove every assembly ran, every targeted credential was obtained or that sensitive data left the system. As of September 11, aelf’s public status remained provisional, with no incident-specific update published after August 26 and only a commitment to future updates and an eventual final review.

aelf’s standing security documentation states that its blockchain and ELF token contracts underwent multiple audits with no security issues identified, yet the available pages do not connect a specific pre-incident report to the runtime path described in August.

Classifying this incident as an audit miss or an outside-scope failure would outrun the available evidence, but that uncertainty itself proves the point: a dated audit history can become detached from a system’s current code, dependencies and operational state. Users need an assurance record that is versioned and specific enough to reveal such drift, naming reviewed repository and commit, deployed addresses, excluded components, privileged roles, dependencies, upgrades since review, key custody and rotation, runtime isolation, alert behavior and dated recovery status separating confirmed loss from frozen exposure.

The problem worsens as protocols undergo frequent upgrades and patches. An audit conducted six months prior may have examined code that bears little resemblance to the live system. Without continuous tracking of what has changed since audit completion, users cannot know whether they are protected by the audit or operating in unreviewed territory.

An audit badge cannot answer whether the reviewed artifact, the deployed system and the machinery responding to failure still share the same security boundary. Until projects publish detailed, current assurance records connecting specific audits to live code paths and operational controls, users will remain unable to distinguish between genuinely reviewed systems and those carrying an audit label while operating largely or entirely outside that review’s scope.