Denial of service is the least fashionable category in security because nothing is stolen and nothing is forged and the report at the end of it reads like a capacity planning memo rather than a crime scene. On most infrastructure that reputation is deserved, since a process that exhausts its heap will trip a pager and somebody will restart it and the week will carry on roughly as it would have done anyway. Consensus networks are the exception to this comfortable arrangement, because a node that has stopped answering has not merely stopped serving traffic but has stopped voting, while Ethereum's finality rules are interested in votes rather than in intentions. A validator caught in a garbage collection spiral looks identical, from the network's side of the connection, to a validator that somebody unplugged. Availability on these systems is not a reliability concern sitting politely alongside the security model but a component of the security model itself.
That is the reason Ethereum treats the existence of several competing client implementations as a defensive measure rather than as duplicated engineering effort. The protocol is a specification while the clients are software written by different teams in different languages, so that every gap between the two is a place where one team's mistake can become everybody's outage at the same moment. Ethereum's own documentation states the case without much diplomacy when it calls multiple clients a strength unique to Ethereum on the grounds that other chains are left depending on the infallibility of a single codebase. Nobody has ever seriously argued that any client is infallible, so the wager being placed here is a narrower one, which is that several independently written clients will not all fail in the same way on the same afternoon.
For a period that wager looked considerably less safe than its designers intended. In January 2024 Geth held roughly 84 percent of Ethereum's execution clients, comfortably beyond the two thirds threshold at which a client specific fault stops the chain finalising altogether, while the community spent that winter circulating black swan scenarios with the enthusiasm of people who suspected they were right. The position in August 2026 would be unrecognisable to anyone who had stopped paying attention after that argument, because Ethernodes now counts 8,023 execution layer nodes distributed across Geth on 40.58 percent, Nethermind on 32.08 percent, Reth on 15.07 percent and Besu on 7.49 percent.
Besu occupies fourth place on that chart and its position there is the necessary context for everything that follows, because a minority client is one whose failures bend the network without breaking it. None of this is an argument for caring less about bugs in Besu, since minority clients are precisely the mechanism by which client diversity does its work, but it does explain why a client of that size can ship a security release without very many people outside its operator community noticing that anything has happened.
Five ways to fill a bucket that had no lid
On 21 August, CertiK disclosed that five vulnerabilities it had reported privately to the Besu maintainers had been fixed in version 26.7.1, a release that shipped on 27 July beneath a note instructing operators to upgrade as soon as they were able. Besu followed on 14 August with four security advisories setting out what had been wrong in each case and how the repairs worked.
The findings are recorded as HYB-01 through HYB-04 together with HYB-08. Although they touch four different interfaces they share a single underlying shape. In every one of them some structure inside the client could be persuaded to grow without an upper bound by a party who had done nothing more privileged than complete a handshake or open a socket. There are no stolen funds anywhere in this set and no forged blocks and no path to a consensus split, only memory and thread capacity being consumed until a node has none of either left to spend.
| Finding | Advisory | Besu rating | Interface | What runs out |
|---|---|---|---|---|
| HYB-01, Major | High | devp2p, eth/68 | Block fetch work, memory and threads | |
| HYB-04, Medium | High | devp2p, eth/68 | Retrieval of unknown parents | |
| HYB-02, Major | Moderate | devp2p, istanbul/100 | BFT event processor heap | |
| HYB-03, Medium | Moderate | WebSocket RPC | Subscription manager state | |
| HYB-08, Minor | Moderate | HTTP JSON-RPC | Filter repository memory |
The first advisory is the one that deserves an operator's full attention and it is also the only one to which Besu attached a rating of High, because any peer that has completed the eth/68 handshake could announce a large number of different block hashes for the same block number and watch Besu obligingly schedule a fetch against every last one of them. The advisory states without hedging that this runs over the default devp2p surface with no JSON-RPC or WebSocket interface involved anywhere in the attack, which places it in a different category from the other three, since there is no configuration change available to an operator that would close it off. Peering is not an optional feature that an Ethereum node can politely decline.
The repair is bookkeeping rather than surgery, because requested blocks are now tracked in a sorted map keyed by block number and a repeat announcement for a number already in flight is honoured only when it arrives from a peer carrying a strictly better reputation score, which caps the outstanding work at roughly the number of connected peers multiplied by the propagation range. That change landed in pull request 10892.
HYB-02 is the more instructive piece of engineering. A peer that had negotiated the istanbul/100 subprotocol could send structurally valid future height QBFT or IBFT proposal messages carrying blocks several megabytes in size, doing so before Besu had performed any check on whether that peer was entitled to propose anything whatsoever. A limit did exist, in that FutureMessageBuffer retained no more than a thousand messages at a time, but the limit counted messages while ignoring how large any of them happened to be, so a thousand unusually fat proposals were sufficient to exhaust the heap belonging to the BFT event processor and stall consensus on the affected validator. A container with a headcount and no weight limit is not really a container with a limit at all, which is why the fix in pull request 10897 adds a byte budget underneath the message count rather than lowering the count.
The remaining two findings are ordinary remote procedure call abuse with one detail that raises HYB-08 above the usual run of such things, which is that Besu's log, block and pending transaction filters remained alive whether or not anybody ever polled them. A client could therefore create filters by the thousand into an unbounded concurrent hash map and then simply close the laptop, leaving server side memory occupied by objects that no one was ever going to read again.
Eighteen days between the fix and the recipe
The sequence in which all this became public carries as much information as the technical substance does. The patched release went out on 27 July saying only that it corrected security vulnerabilities and thanking both EF Security and CertiK for responsible disclosure without describing what either of them had brought to the maintainers. The technical detail arrived eighteen days later on 14 August. CertiK attached its own name to the work a further week after that.
That eighteen day interval is coordinated disclosure performing the function it was designed for, since every operator who read the release notes and acted on them was protected during it while every operator who ignored them was exposed to vulnerabilities for which no attacker had yet been handed a set of instructions. The advisories, published by maintainer macfarla, are detailed enough to be genuinely useful to somebody hardening a deployment and specific enough to be genuinely dangerous in less friendly hands, which is the reason they were always going to arrive second rather than first.
One awkward detail complicates the tidiness of the process. Not one of the four advisories carries a CVE identifier, since each of them records in the same field that no known CVE exists. Operators who follow GitHub advisories or watch the Besu release feed lose nothing at all by this, but enterprises whose entire security posture rests on automated scanning against national vulnerability databases lose a great deal, because for those organisations the five findings do not exist in any form their tooling can see. A large Java estate with org.hyperledger.besu/besu sitting in a build file and a scanner watching that file will never be told that any version below 26.7.1 is affected by anything.
Two scorecards for the same five bugs
CertiK graded its findings on a scale running from Minor to Major while Besu attached its own severities at the point of publication, yet the two columns do not agree with one another. The pattern of the disagreement turns out to be considerably more interesting than either column read on its own.
Two of the five kept the grade they arrived with, since HYB-01 was published as High in line with CertiK's Major while HYB-03 was published as Moderate in line with CertiK's Medium. The other three moved. HYB-04 was folded into the High advisory alongside HYB-01 because the pair share a root cause and a single patch between them. HYB-08, which CertiK had called Minor, went out as Moderate beneath an unusually frank line recording that Besu's own assessment had been medium and had deliberately been left unchanged, which means the maintainers concluded that the researchers had undersold their own finding.
Then there is HYB-02, submitted as Major and published as Moderate with five words of explanation that repay reading exactly as they were written: Severity critical; Probability remote.
Nothing in that phrase retreats on impact. It says instead that the impact is every bit as serious as CertiK claimed while the road leading to it is narrow, meaning that risk is properly understood as those two quantities multiplied together rather than as whichever of them sounds worse in isolation. It also lays bare what auditors and maintainers are really arguing about whenever they argue about severity ratings, because CertiK had been answering the question of how bad this could conceivably get while Besu was answering the question of how bad it is likely to get on the networks the client actually ships to. Both are legitimate questions with different answers, so any single word forced to carry both will end up being disputed. Two teams read identical code while holding different populations of deployments in their heads.
Nobody can say how much Besu there is
All of which invites an obvious follow up question that the public record answers badly, because Besu's share of Ethereum turns out to depend entirely on who is doing the counting.
Ethernodes puts Besu at 7.49 percent of execution layer nodes. Clientdiversity.org publishes a validator weighted figure of 9.45 percent directly alongside supermajority.info's hand collected 8 percent. Chainstack, writing in July from the same Ethernodes feed, arrived at 11.9 percent. The EthStaker 2026 survey of solo stakers found something closer to 15 percent, which is double the node count figure. None of these sources is being dishonest, since they are answers to four genuinely different questions about four different populations, but the spread between them ought to unsettle anybody who has ever quoted a client diversity percentage in a governance argument as though it were a settled fact.
The deeper problem is that every one of those figures measures public Ethereum while HYB-02 does not live on public Ethereum at all. QBFT and IBFT are consensus mechanisms belonging to private and permissioned networks, which is the enterprise half of Besu's reason for existing and precisely the half that no public crawler will ever index. The finding CertiK rated most severe therefore applies exclusively to deployments that appear in none of the counts above. Whatever the true exposure to it amounts to, nobody publishes that number and on current tooling nobody could.
Ceilings rather than rewrites
What actually shipped in 26.7.1 is modest by design. Nothing was rearchitected and no subsystem was replaced, because five things that previously had no upper bound were simply given one.
Filters are now capped by --rpc-max-active-filters at a default of a thousand and throw a FilterCountExceededException once that ceiling is reached, while unpolled filters expire on a configurable timer defaulting to 120 seconds in place of the ten minute expiry that had previously been hardcoded. WebSocket subscriptions are capped by --rpc-ws-max-active-subscriptions at a default of 100,000 and any subscription belonging to a connection that dies partway through subscribing is now cleaned up rather than orphaned. Buffered BFT proposals keep their thousand message ceiling while gaining a byte budget beneath it. Block fetches are bounded by peer count multiplied by propagation range.
These are cheap fixes shipped quickly, which is the correct instinct when a disclosure clock is running, though two footnotes belong with them. Both of the new numeric caps accept a value of zero to mean no limit, so an operator irritated by the defaults can restore the previous behaviour with a single flag and no warning at all. The release notes also classify the filter and subscription caps as breaking changes, which they are for anybody whose tooling leans heavily on those methods.
Why a security firm does this for nothing
CertiK has been explicit that the work carried no client engagement and no commercial scope whatsoever, having been conducted as self directed research on a private multi node test network into which controlled faults were injected across the peer to peer, HTTP RPC, WebSocket RPC and consensus facing interfaces in order to probe availability and resource exhaustion. The approach matches the grey box method CertiK has described elsewhere as deploying the full stack, injecting real faults and measuring what the system does in response, which its senior blockchain security expert Luigi Girletti has characterised as a break, fix and re-verify loop rather than a single pass review.
The commercial logic underneath that generosity reconstructs without much difficulty. Smart contract auditing, which is the business CertiK grew up in, has commoditised over the past several years and the pricing shows it plainly enough, whereas client and node level security has not commoditised because it demands a laboratory rather than a code review together with the patience to run adversarial load against distributed systems that only misbehave once they are pushed. Publishing findings against a Linux Foundation project you hold no contract with is an expensive way to demonstrate that you are capable of the harder work, but it is also the only demonstration anybody is obliged to believe, since a finding that a maintainer has accepted and patched and credited in a public advisory cannot be dismissed as marketing.
Founded by professors from Yale and Columbia and operating under SOC 2 Type II and ISO 27001, CertiK has spent several years positioning itself toward regulators and institutions rather than only toward token issuers, where research of this kind is the technical floor holding that position up. The company reports having detected more than 119,000 vulnerabilities and protected over $600 billion in digital assets, figures which are company stated rather than independently audited. The five entries now sitting in Besu's advisory database are neither, since they are public record with commit hashes attached to them.
What has to go right from here
Handling a disclosure well and having that disclosure achieve anything are two separate outcomes that people habitually confuse. Operators have to upgrade, yet there exists no public dataset showing what proportion of the 601 Besu nodes Ethernodes currently sees are running 26.7.1 or anything later than it. That number is entirely knowable and nobody publishes it, which is a small scandal standing on its own two feet. The absent CVE identifiers mean that the enterprises most likely to be running the permissioned configurations HYB-02 was written against are also the least likely to receive any automated warning, because their tooling watches national vulnerability feeds rather than a project's GitHub tab. The operators carrying the greatest exposure to the most severe finding in the set are, as a general rule, the furthest removed from the Discord channel where all of this was discussed.
There is also a loose thread lying in plain sight for anybody who reads the identifiers carefully. They run HYB-01, HYB-02, HYB-03, HYB-04 and then HYB-08, so five findings made it into advisories while the sequence itself reaches eight, which means CertiK's report to the maintainers contained at least three further items that never became advisories. Whether those were informational, rejected, duplicated or still open is something the public record does not say and neither party has yet been asked.
Each of these three is falsifiable rather than rhetorical. Version telemetry would settle the upgrade question inside a week. A CVE assignment would settle the second. A single sentence from either team would settle the third.
Nobody exhausted a Besu validator's heap in July, so the temptation with a story shaped like this one is to spend the ending describing in loving detail the outage that never arrived. The outage is not what makes the episode worth writing about. What actually happened is that a security firm with no invoice in play spent weeks attacking software it does not own and has no stake in, reported what it found through a private channel, waited while the maintainers evaluated and repaired the findings, waited again while operators were handed a fix without being handed a recipe, then finally put its name to any of it. The maintainers, for their part, disagreed with the researchers on three ratings out of five and printed that disagreement in the advisories rather than sanding it away, including the faintly embarrassing admission that they considered one finding rather worse than the people who had found it did.
The bugs themselves were unremarkable in kind even where they were serious in consequence, so what lingers afterward is the epistemics surrounding them. Five findings produced two scorecards, four advisories, zero CVE identifiers and a client whose share of the network cannot be pinned down any closer than a factor of two. An industry that will not stop talking about verification still cannot say with confidence how much of anything is running, which version it happens to be running, or how much damage a given flaw would really have done had somebody bothered to use it. Version 26.7.1 put ceilings on four resources that had been growing without any, which is a real improvement to the software. The measurement problem sitting underneath it, the one concerning who is exposed and to what, is still growing without a bound of its own.
Don’t forget to like and share the story!