Availability is a security property. When a blockchain client has a resource-exhaustion bug, the consequence often is a validator forced offline, a network's finality stalled, or an attacker with a cheap way to grief an entire chain. CertiK's research team set out to find that class of bug in Besu, the widely used Java-based Ethereum execution client hosted by Linux Foundation Decentralized Trust (formerly known as Hyperledger Besu).
This wasn't a client engagement and there was no scope document. Instead, we deployed a private, multi-node Besu testnet and used an adversarial testing methodology, adapted from chaos engineering in telecom and large-scale distributed systems, to probe how the client behaved under deliberately hostile conditions. That work turned up five vulnerabilities, each capable of degrading or crashing a node using nothing more than default protocol interfaces, no special privileges beyond whatever access the network already grants a connected peer or client. On a permissionless deployment that means any peer on the open internet; on a permissioned deployment, where a peer allow-list is enabled, it means any peer already admitted to that list.
We reported all five findings directly to the Besu team along with reproducible proof-of-concept harnesses, and the two teams coordinated confidentially while Besu evaluated and addressed the issues. Besu shipped version 26.7.1 on July 27 as a security release patching all five findings, and published the technical advisories on August 14, once operators had time to upgrade. Besu's release notes credit CertiK, alongside a separate disclosure from Ethereum Foundation Security, for responsible disclosure.
Here's what we found, how we found it, and why it matters.
Chaos Engineering, Applied to a Live Blockchain Network
Chaos engineering starts from a simple premise: instead of hoping a system handles failure gracefully, you inject failure on purpose, under controlled conditions, and observe what breaks. We built a harness that applies this discipline to Web3 infrastructure, running against a live multi-node Besu network rather than a static code review.
A few things distinguish the approach:
- Targeted fault injection. We used Besu's own public APIs and documentation to reason about which faults were worth testing, things like unbounded message fan-out, missing admission control, and the distinction between heap and native-memory exhaustion, which determines whether an attack causes slow degradation or an instant crash.
- Every finding ships with a repeatable proof. Each vulnerability has a harness that reproduces the fault on demand, so the Besu team could verify the issue and confirm the fix without relying on a one-time observation.
- Impact was measured at the network level. Where relevant, we ran the same attacks against a multi-validator QBFT network to test whether knocking out a minority of nodes was enough to stall the chain's liveness entirely.
- The harness is built for continuous use. The same tooling that surfaced these bugs can be pointed at future Besu releases to catch regressions before they ship.
This methodology now underpins Chain Scan, CertiK's continuous adversarial-testing service for blockchain infrastructure. Others have run end-to-end fault injection before; what we believe is distinctive here is turning it into a repeatable, productized pipeline built specifically for Web3 clients.
The Findings
All five vulnerabilities are patched in Besu version 26.7.1 and documented in four public GitHub Security Advisories (two of the five findings shared the same root cause and the same fix, so they're covered under one advisory). Severity labels reflect Besu's own classification, and range from Minor to Major, including two Major-severity findings.
1. Block Hash Announcements Could Spawn Unbounded Threads (Major)
Besu's handling of NEW_BLOCK_HASHES messages, ordinary eth-protocol announcements that any connected peer can send, treated every hash in an incoming message as an independent unit of work. Each one triggered its own scheduled fetch task and native thread, with no cap on how many could pile up at once. A single peer, using default P2P access and nothing else, could drive a properly-provisioned node to tens of thousands of threads and force an out-of-memory kill within seconds. Pointed at a majority of validators in a QBFT network, the same technique stalled consensus outright.
Besu replaced the unbounded thread pool backing this path with a fixed-size, bounded pool, throttling floods instead of letting them spawn threads without limit. Full details are in GHSA-j2j5-x2rr-cv75.
2. Future-Dated Consensus Proposals Could Exhaust Heap Before Sender Checks Ran (Major)
In QBFT and IBFT deployments, Besu buffers consensus proposals for future block heights before verifying whether the sender is even an eligible validator. That buffer was capped by message count but not by message size, and a single proposal can legitimately carry several megabytes of block data. An unauthenticated peer, no validator key required, could send a stream of oversized future-height proposals and exhaust a node's heap well before the count limit ever engaged. On a single node this shut down the BFT event processor. Across a four-validator network, it knocked out enough validators to halt commit quorum and freeze the chain.
Besu added a total-byte budget to the future-message buffer, with eviction, capping it at a fixed memory ceiling regardless of message size. Full details are in GHSA-qhrf-865g-38rh.
3. Unlimited WebSocket Subscriptions Could Grow Memory Without Bound (Medium)
Besu capped WebSocket connection counts and individual frame sizes, but placed no limit on how many eth_subscribe registrations a single connection could create, and subscriptions never expired on their own. On an undersized node this meant a fast kill; on a properly-sized node, sustained subscription floods still pushed heap usage steadily toward exhaustion for as long as the connection stayed open. Enabling authentication didn't close the gap either, it only restricted who could launch the flood, not whether it worked.
Besu shipped --rpc-ws-max-active-subscriptions, capping global active subscriptions and rejecting new requests once the limit is reached. Full details are in GHSA-ffqr-pj4h-xq37.
4. Unknown-Parent Block Announcements Shared the Same Fan-Out Flaw (Medium)
A close relative of finding #1: when a peer announced a NEW_BLOCK for a near-future block with an unrecognized parent, Besu scheduled unbounded parent-retrieval work on the same uncapped thread pool. A flood from a single peer could exhaust scheduler threads outright, and blocks carrying large transaction payloads added genuine heap pressure on top. The root cause was identical to finding #1: no limit on attacker-controlled retrieval work, and it was resolved by the same bounded thread pool change, documented under the same advisory, GHSA-j2j5-x2rr-cv75.
5. HTTP-Only Clients Could Still Exhaust Memory Through Filters (Minor)
Besu's legacy JSON-RPC filter API (eth_newFilter, eth_newBlockFilter, and related methods) had no cap on how many filters a single client could register. Filters eventually expired after ten minutes, but that window was long enough for a client to create them faster than cleanup could remove them. Unlike the previous findings, this one required nothing but plain HTTP JSON-RPC access, so nodes that had disabled WebSocket RPC specifically to avoid finding #3 were still exposed through this separate path.
Besu added --rpc-max-active-filters (default 1000), rejecting new filter registrations once the active count hits the configured ceiling. Full details are in GHSA-vff7-xxjc-rccp.
All five vulnerabilities below are now resolved in Besu. Severity labels reflect Besu's own resolved classification.
Why It Matters
None of these five findings involved a cryptographic flaw or a consensus-safety break. They're all availability issues, reachable through default, always-on interfaces rather than obscure misconfigurations, and none required a fund-theft exploit to threaten a network's ability to stay online. That's precisely the class of risk that's easy to underrate and expensive to ignore.
It's also the class of risk that a code review alone tends to miss. Finding it took running a live, adversarial network under load, which is the gap Chain Scan exists to close on an ongoing basis, not just for a single point-in-time assessment.
FAQs
Was this a paid audit engagement with Besu?
No. CertiK conducted this research independently and proactively, without a client engagement, then disclosed the findings directly to the Besu team.
What kind of vulnerabilities were found?
All five findings were resource-exhaustion and denial-of-service issues, unbounded memory or thread growth reachable over P2P or JSON-RPC, rather than fund-theft or consensus-safety bugs. Two were rated Major severity.
What methodology did CertiK use to find these issues?
CertiK deployed a private multi-node Besu testnet and used a chaos-engineering-style fault injection harness, adapted from telecommunications and distributed-systems testing practices, to send adversarial inputs across the P2P, HTTP RPC, and WebSocket RPC surfaces and observe the results.
When were the fixes released, and when was the technical detail made public?
Besu shipped version 26.7.1 on July 27 as a security release patching all five findings, then published the technical advisories on August 14, giving operators time to upgrade before details became public.
Is this testing approach available as an ongoing service?
Yes. The methodology behind this research underpins Chain Scan, CertiK's continuous adversarial-testing service for blockchain infrastructure, which can be run against ongoing releases to catch regressions before they ship.
