TL;DR: Five Besu vulnerabilities that let ordinary P2P, WebSocket, or JSON-RPC traffic trigger thread or memory exhaustion, stall validators, and freeze consensus in QBFT networks, according to CertiK research. Availability failures in blockchain clients are governance failures, because default interfaces can become cheap denial-of-service paths when admission and resource caps are missing.
At a glance
What this is: CertiK identified five Besu vulnerabilities that allowed default protocol and RPC traffic to exhaust threads or memory and degrade or stall blockchain nodes.
Why it matters: This matters because blockchain availability is an operational control as much as a protocol property, and the same exhaustion path can interrupt validator service, consensus, and incident response across permissionless and permissioned deployments.
By the numbers:
- Besu shipped version 26.7.1 on July 27 as a security release patching all five findings.
- Besu added --rpc-max-active-filters with a default of 1000 to reject new filter registrations once the active count hits the configured ceiling.
Context
Availability is not a secondary property in blockchain infrastructure. When protocol handlers and RPC surfaces can be driven into unbounded work or memory growth, the result is often validator loss, stalled finality, or a network-wide denial of service rather than a clean application crash.
This research uses a chaos engineering style against a live multi-node Besu testnet to probe what happens under hostile conditions. That is a more realistic test of operational resilience than static review alone, and the subject's starting position is unfortunately typical for client software that exposes always-on interfaces.
Key questions
Q: What breaks when blockchain client interfaces allow unbounded work or memory growth?
A: The service stops behaving like a bounded system and starts behaving like a denial-of-service target. Unbounded queues, buffers, or subscriptions let an attacker spend your CPU and memory faster than the node can shed load. In validator environments, that can translate into missed commitments, stalled finality, or a full network liveness failure.
Q: Why do permissioned blockchain networks still face denial-of-service risk?
A: Because admission control only decides who can connect, not how much work a connected peer can force the client to do. Once a peer is inside the trust boundary, it can still trigger oversized messages, repeated state creation, or expensive retrieval paths unless the runtime enforces separate resource limits.
Q: What are the signs that a blockchain node is close to resource exhaustion?
A: Watch for rapid thread growth, heap pressure that rises with ordinary protocol traffic, subscription or filter counts that grow without matching business demand, and latency spikes that appear before crashes. Those signals usually mean the node lacks enforceable ceilings on attacker-controlled state.
Q: How should teams validate availability controls before upgrading blockchain clients?
A: Use hostile-load testing that exercises P2P, HTTP RPC, and WebSocket paths under realistic traffic volumes and malformed input. The goal is not just to confirm a patch, but to prove that the client sheds load safely, preserves liveness, and fails predictably when resource limits are reached.
Technical breakdown
Unbounded work queues turn ordinary protocol messages into denial of service
Besu's first failure mode was not a cryptographic break but a scheduling problem. Incoming NEW_BLOCK_HASHES messages could trigger one fetch task and one native thread per hash, with no cap on total work. In distributed systems, a bounded queue is the difference between load shedding and collapse: once attacker-controlled input can allocate work indefinitely, the node is competing with the attacker for the same CPU and memory budget. The result is a resource-exhaustion path that is reachable through a normal peer connection, not a privileged admin action.
Practical implication: Treat peer-facing message handlers as resource governors, not just parsers.
Future-message buffering needs byte limits, not only count limits
The second issue showed why message-count limits alone are incomplete. Besu buffered future-height consensus proposals before validating sender eligibility, and each proposal could legitimately be several megabytes. A message-count ceiling does not protect a heap if a small number of large payloads can accumulate first. The architectural fix is to meter total bytes and eviction behavior, because attackers often exploit size asymmetry instead of volume alone. That distinction matters in BFT systems, where a single peer can affect liveness without ever touching validator keys.
Practical implication: Enforce byte-based ceilings on every pre-validation buffer.
RPC subscription abuse is a lifecycle problem, not an authentication problem
The WebSocket finding is important because authentication did not remove the risk, it only narrowed who could trigger it. Besu allowed a single connection to create unlimited eth_subscribe registrations, and those subscriptions persisted until expiry or disconnect. That means the control gap sat in object lifecycle management, not login security. If per-connection state can grow without bound, the service can be exhausted by a trusted client just as easily as by an outsider. In identity terms, this is a reminder that access approval and resource entitlement are different problems. Read the Ultimate Guide to NHIs: Key Challenges and Risks.
Practical implication: Cap per-connection state and time-bound every subscription object.
Threat narrative
Attacker objective: The attacker wants to degrade or freeze blockchain nodes cheaply enough to disrupt validator service and consensus availability.
- Entry occurs through default P2P, WebSocket, or JSON-RPC interfaces that accept normal protocol traffic from an already-connected peer or client.
- Resource growth begins when attacker-controlled messages create unbounded threads, heap buffers, or subscription state before deeper checks or expiry rules can intervene.
- Escalation follows as scheduler saturation or memory exhaustion degrades the node, and in multi-validator deployments the same pressure can remove enough nodes to stall consensus.
- Impact is loss of node availability and, in the worst case, network liveness rather than theft or state corruption.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Availability abuse is a governance problem, not just a client bug. This research shows that a blockchain node can be taken offline through ordinary protocol traffic when resource caps are missing. The key issue is not whether the attacker can steal funds, but whether the service can keep validating under pressure. Practitioners should treat availability controls as part of core security governance, not as an optional hardening layer.
Resource exhaustion is the clearest example of protocol trust without workload boundaries. Besu accepted messages that were syntactically valid but operationally unbounded, which is the same structural mistake seen in many distributed systems. The absence of hard ceilings on work, bytes, and per-client state allowed normal interfaces to become attack surfaces. That pattern is especially relevant to adversarial testing because it is easiest to miss in code review and easiest to reproduce under load.
Blockchain operators need to distinguish reachability from entitlement. The article shows that permissioned access does not eliminate exhaustion risk if admitted peers can still generate unbounded work. This is a useful identity lesson as well: once a peer, client, or node is trusted enough to connect, its operational entitlements still need separate limits. Admission control and runtime resource governance are not substitutes for each other.
Validated resilience depends on testing the failure mode, not assuming the protocol will self-protect. CertiK's methodology matters because it exercised the system the way an attacker would, then measured whether the network survived degraded conditions. That is the right posture for client software, where safety and availability often fail in different ways. Practitioners should expect fault-injection-style validation before they rely on a client in production.
What this signals
Availability hardening is now a client governance discipline. The lesson from Besu is that operators need explicit ceilings for work, bytes, and long-lived RPC state, because exposed interfaces can become the easiest path to outage. In practice, that moves resilience checks from a one-time release review into continuous validation of protocol surfaces.
Protocol trust without resource boundaries creates an exhaustion gap. Permissioned access does not remove the need for runtime entitlement controls, especially when a peer can still create many work objects or retain subscriptions indefinitely. Teams should design their operating model around the assumption that any accepted peer may behave adversarially.
Fault injection is the right test for this class of risk. The most useful signal is whether a client can absorb hostile input without turning normal traffic into a service outage. That makes adversarial testing a production control for blockchain infrastructure, not an academic exercise.
For practitioners
- Bound every attacker-controlled queue Set explicit limits on message fan-out, scheduled tasks, and buffered work so a single peer cannot create unbounded scheduler pressure.
- Cap pre-validation memory by bytes Use total-byte ceilings for consensus and RPC buffers, not only count-based thresholds, so large payloads cannot bypass limits.
- Limit per-connection state growth Apply hard caps to subscriptions, filters, and similar long-lived RPC objects, and make expiry rules enforceable under sustained load.
- Test the client under hostile load Run adversarial fault injection against P2P, HTTP RPC, and WebSocket surfaces before upgrades reach production validators.
Key takeaways
- Besu's five findings show how ordinary protocol and RPC traffic can become a denial-of-service path when resource caps are missing.
- The evidence is operational, not theoretical: one peer could drive tens of thousands of threads, while other paths could exhaust heap or subscription state.
- Operators should pair byte-based limits, per-connection caps, and hostile-load testing to keep validator availability from depending on optimistic traffic assumptions.
Related NHI Mgmt Group resources: Breach and Attack Simulation (BAS) Guide · Google Cloud Security Guide · Ultimate Guide to NHIs: Key Challenges and Risks · Federation and Trust Relationships Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | Resource-exhaustion attacks map to adversary impact on availability and service disruption. |
| Recommendation — Map exhaustion paths to TA0040 and hunt for attackable service surfaces that can be driven into outage. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authenticated or admitted peers still need bounded runtime entitlements in exposed services. |
| Recommendation — Enforce PR.AA-05-style entitlement limits so accepted peers cannot consume unbounded service resources. | ||
| CIS Controls v8 | CIS-5 — Account Management | Long-lived filters and subscriptions behave like unmanaged service accounts in terms of lifecycle control. |
| Recommendation — Apply account-lifecycle discipline to RPC objects and remove any state that should not persist indefinitely. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | The RPC and subscription paths exhibit the same unrestricted-consumption pattern as vulnerable APIs. |
| Recommendation — Use API4 to cap request-driven work, subscriptions, and buffer growth before they can exhaust the node. | ||
Key terms
- Resource Exhaustion DoS: A denial-of-service condition caused when a workload consumes CPU, memory, or disk faster than the system can recover. In archive processing, the attack often relies on expansion or repeated allocation rather than malformed code execution, which makes limit enforcement the key defensive control.
- Bounded Queue: A bounded queue is a work buffer with a fixed maximum size. It is a core resilience control because it forces a system to shed, reject, or defer load when demand exceeds capacity instead of allowing attacker-controlled work to expand without limit.
- Consensus Liveness: Consensus liveness is the ability of a distributed network to keep making forward progress and finalising blocks. It is distinct from safety, because a chain can remain correct while still becoming unavailable or stalled if too many validators are degraded.
- Runtime entitlement: The access a software actor is allowed to use at the moment it performs work. In agentic environments, entitlement must be evaluated during execution because the system may request, combine, and release privileges within a single task.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and the identity controls that underpin resilient access design. It is suitable for practitioners who need to connect identity governance to the broader security programmes their environments depend on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org