Octane Security’s AI Catches High-Severity Ethereum Client Bug

‍

This bug could have stopped localblock production and inhibited the network's ability to process transactions across nearly 40 percent of mainnet Ethereum validators. 

The issue was responsibly disclosed through the Ethereum bug bounty program and awarded $50,000, the maximum high-severity payout.

How We Found It

A few months ago, we started building a language-agnostic version of Octane's AI engine. To stress-test an early alpha prototype, we entered the Fusaka upgrade audit contest – a four-week, $2M security competition co-sponsored by Gnosis and Lido to maximize scrutiny of the Fusaka upgrade before it reached mainnet.

We did this in collaboration with security researcher Guhu, who served as our test pilot: reviewing AI-generated findings, reproducing issues, and preparing the reports and proofs of concept. None of the submissions were first identified through manual review – each began as an AI-generated finding that Guhu then validated.

The mainnet Nethermind vulnerability emerged from this same workflow. Octane's AI flagged the missing length-equality enforcement in blob transaction handling; Guhu confirmed exploitability, built the PoC, and submitted it through the Ethereum bug bounty program.

Technical Breakdown of the Nethermind Client Bug

Root Cause

The issue stems from missing length-equality enforcement in Nethermind's blob transaction validation on acceptance into the transaction pool. The ValidateHashes path in IBlobProofsVerifier did not enforce that the number of blobVersionedHashes in a transaction matched the number of blobs, commitments, and proofs. This allowed malformed blob transactions – where the versioned hash count exceeded the actual blob count – to pass validation and enter the mempool.

Once admitted, these malformed transactions would be propagated to other clients and accepted by other Nethermind validators. In each of those, during local block building, GetBlobCount() uses N (number of hashes) to size BlobsBundleV1 requests, while only M blobs/proofs exist, resulting in null trailing entries. When the consensus layer requests blobs via engine_getBlobsV1, the EL returns a mixed list like [blob, null] (or hits an out-of-bounds path), so the CL cannot assemble a valid block and skips the proposal – resulting in no block production. This would continue happening for all Nethermind validators for as long as the malformed transactions are in their mempools.  

Attack Path

An attacker could craft a blob transaction with well-formed but unbacked versioned hashes – each with correct length, but without corresponding blob data. By setting a high gas tip, the malformed transaction would be preferentially selected during payload building. Because the transaction persisted in the mempool across proposal attempts, every Nethermind validator that encountered it during local block construction would fail to produce a block for that slot.

This could have caused sustained missed slots across all Nethermind-based proposers for as long as the malformed transaction remained in the pool.

Impact

Approximately 38% of Ethereum validators run Nethermind as their execution layer client. Exploitation would have removed that capacity from the network assuming local block production. It would also likely similarly prevent external block builders running Nethermind (at least 10-15% market share at the time) from building their blocks. Any affected validators would miss block rewards, incur inactivity leak penalties, and degrade overall network liveness and availability. Ethereum's bug bounty program classifies liveness failures of this magnitude as high severity.

Resolution

The Nethermind team addressed the vulnerability by enforcing strict length equality during transaction admission - requiring that BlobVersionedHashes.Length, blob count, commitment count, and proof count are all consistent before a transaction enters the mempool. 

The patch is now live on Ethereum Mainnet. No exploitation of this vulnerability was observed in the wild prior to patching.

The Fusaka Contest By the Numbers

The Nethermind bug was the most serious finding, but it wasn't the only one. Across the contest, Octane and Guhu:

• Analyzed all 11 in-scope clients 
• Submitted 17 issues for 8 clients; 16 of which were fixed
• Produced 9 severe issues (safety failures or liveness failures) across 6 clients, of which 6 are believed to be unique
• Covered 5 programming languages, with notable success in Rust-based clients
• Found 5 of the contest's 14 non-informational issues (4 rewarded; 3 unique)
• Placed 4th overall out of 500+ researchers, earning $70,633 in contest rewards

For clarity, "severe" here means either safety failures (chain splits, invalid blocks) or liveness failures (no blocks, empty blocks). Specific details for each submission will be published once the contest report is made public.

The Broader Trend: AI Is Moving Into the Base Layer

AI security tools have long been framed as a faster way to review smart contracts. The shift now is upstream: automated systems can examine client software that runs the network itself – execution and consensus clients.

At the time the report was filed, Ethereum had roughly $380 billion in market capitalization, which is why this disclosure matters beyond the client bug itself. It is also a concrete, high stakes proof point that AI led vulnerability research is no longer confined to smart contracts or toy targets. AI can now demonstrably surface edge case vulnerabilities in the critical software that actually runs blockchains.

More broadly, AI is compressing the entire vulnerability research pipeline. Generating bug hypotheses, validating their exploitability, and turning the result into a submission that maintainers can act on now happens an order of magnitude faster than in previous workflows.

This changes the security equation for anyone shipping software: teams that run continuous AI driven analysis in development are raising their floor, while teams that do not are in a race against adversaries who have the power of automation on their side.

What's Next

This is the biggest accomplishment for Octane so far, but it won’t be the last.

We’re proud to have delivered on Vitalik Buterin’s hypothesis from two years ago that AI-assisted vulnerability findings could meaningfully improve Ethereum’s overall security.

This is what significantly changing the game looks like.

Huge thanks to the Ethereum Foundation Protocol Security Team for handling the disclosure responsibly and coordinating on public release. Thanks to the Nethermind team for their prompt response in patching the issue. And thanks to Guhu for the sharp work validating and reporting these findings – this collaboration is a model for what AI-augmented security research looks like in practice.