RabbitMQ can be taken down with no login, and no fixed release yet (CVE-2026-59248)

On July 28, 2026, two vulnerabilities were published in Cowboy and Cowlib, the Erlang web-server components. On paper they are unremarkable denial-of-service bugs. What matters is where the code ships: RabbitMQ — the message broker sitting between systems in a great many enterprises — is affected in every currently released version.

No login is required. A single crafted request to the management port can consume hundreds of megabytes of memory and take RabbitMQ down. Credentials are irrelevant, and a password does not help, because header parsing happens before authentication is ever reached.

The remediation picture is the awkward part. The fixes exist in Cowboy and Cowlib, but no RabbitMQ release containing them has shipped yet. That includes the latest 4.3.4. RabbitMQ has published no advisory either. For now, restricting who can reach those ports is the practical answer.

Reading a header is enough to melt the memory

Both flaws come from parsing headers — the metadata that precedes the body of a web request — without an upper bound. Because nothing caps how much gets read, deliberately long input causes memory to be allocated without limit.

CVE-2026-59248: an uncapped integer decoder (Cowlib)

The serious one is CVE-2026-59248. HTTP/2 and HTTP/3 shrink headers using compression schemes called HPACK and QPACK. The routine that reconstructs a number inside them kept reading as long as a "there is more" marker was set, with no ceiling.

It gets worse because Erlang integers are immutable: every additional chunk allocates a fresh value rather than extending one. Total allocation therefore grows with the square of the digit count. Per the published advisory, at default settings a single exchange — headers split across two frames — can force hundreds of megabytes of allocation. Severity is 8.7 on CVSS 4.0. Cowlib below 2.19.0 is affected; 2.19.0 fixes it.

The fix is almost anticlimactic: one added condition capping the read at 38 bits. Reported by David Hernández; remediated by Cowboy's author Loïc Hoguin.

CVE-2026-65624: repeat one header name and the limit never triggers (Cowboy)

The second, CVE-2026-65624, applies to ordinary HTTP/1.1. Cowboy enforces a cap of 100 headers — but it counted the number of distinct header names, and that was the trap.

Send the same header name on many lines and the values are joined with commas into a single entry. The count of distinct names stays at one, so no matter how many lines arrive, the cap is never reached — and the values pile up as one ever-growing string in memory. Severity is 6.9 on CVSS 4.0. Cowboy below 2.18.0 is affected; 2.18.0 adds a counter that tracks lines rather than names. Reported by Qiyi Deng and three colleagues at Wuhan University.

Neither flaw leaks data. What is lost is availability — the service continuing to run at all. We have covered the same shape before in Apache HTTP Server's "HTTP/2 Bomb" and in the HTTP/2 flaw that slipped past AWS WAF. HTTP/2's design lets a small amount of traffic buy a large amount of work at the far end, and this class of bug keeps recurring because of it.

Why RabbitMQ gets caught in this

RabbitMQ brokers messages between systems — order processing, notification fan-out, and similar plumbing across enterprise architectures. It is written in Erlang, and it uses Cowboy and Cowlib internally to serve its management and monitoring interfaces over the web. The Cowlib advisory names RabbitMQ's management plugin explicitly when describing reach.

Here is which versions are affected, taken from the dependency pins in RabbitMQ's own source tree.

The commit raising those dependencies landed in the development tree roughly an hour before the CVEs were published. No release contains it yet. Whichever RabbitMQ you can install today, it is affected.

The affected surface is every feature with a web entry point: the management UI, the Prometheus metrics endpoint, the browser-facing messaging bridges (Web-STOMP and Web-MQTT), and the HTTP-based authentication backends.

"The management UI has a password" does not help

RabbitMQ's management UI requires a username and password, which sounds like protection. It is not, here. The attack lands during header parsing, and that runs before any authentication decision. The memory is gone before the login screen is in play.

The other thing worth checking is whether HTTP/2 is on. RabbitMQ never tells Cowboy which protocols to accept, so Cowboy's default — HTTP/2 and HTTP/1.1 both — applies. HTTP/2 is open whether or not you enabled it. Port by port:

Only the TLS management (15671) and metrics (15691) listeners escape the serious flaw, because of how they are constructed HTTP/2 cannot be negotiated there. The HTTP/1.1 issue still reaches every port. One piece of good news: the QPACK/HTTP/3 path is unreachable, because RabbitMQ does not build in the component Cowboy needs for HTTP/3.

Who goes after this, and why

Nobody values this flaw for stealing data. The people who want it are attackers whose objective is stopping your business — crews softening a target before a ransom demand, or anyone paid to disrupt a competitor or adversary. A way to reliably knock something over with very little traffic is excellent value for that kind of work.

What they do is send a handful of crafted requests until memory is exhausted and the message broker falls over. The cost to them is trivial and no volumetric flood is needed. There is no burst of failed logins either, so from the monitoring side all you see is memory climbing and then a crash.

RabbitMQ sits at the seams between systems — handing off orders, dispatching notifications. When it stops, individual services stay up but nothing progresses. It surfaces as "orders are not completing" or "notifications never arrived", which tends to burn a lot of time before anyone looks at the broker.

What to do until a fixed RabbitMQ ships

Waiting for the patched release is the real answer, but not an acceptable position to hold indefinitely. In the meantime the work is making sure attackers cannot reach those ports.

Start by confirming the management UI (15672) and the metrics endpoint (15692) are not visible from the internet. Neither should ever need to be — they exist for your own operators. In cloud deployments, over-permissive security groups on these two are a common finding. If you expose the browser-facing bridges (15674 / 15675) because the application genuinely requires it, move on to the next step.

For anything that must stay public, put a reverse proxy in front, terminate at HTTP/1.1 only, and cap header count and header size there. The serious flaw lives in HTTP/2 header compression, so a proxy that terminates HTTP/2 keeps it away from RabbitMQ entirely.

RabbitMQ does impose a per-connection request timeout (5 seconds by default), which bounds how much a single connection can accumulate. Treat that as mitigation, not a fix — an attacker simply reconnects and repeats.

If you run your own Erlang or Elixir application, this is far simpler: move to Cowboy 2.18.0 and Cowlib 2.19.0 or later. Both must be raised together. For dependency sweeps, tooling like a paste-your-manifest vulnerability scanner helps, though that one covers npm and Python — for Erlang, read the dependency definitions directly.

Your automated alerting will not fire on these

The thing to be most careful about is that the usual automation will not tell you about this. Three factors stack up.

First, no GitHub Security Advisory has been created for either CVE. Dependabot works off that database, so it stays silent. Second, NVD analysis is still pending on both (they sit at "Received"), so many scanners have nothing to match on. Third, the vendor's public announcement contains no CVE identifiers at all.

The release post of July 28 says only that the releases "contain a number of defense-in-depth and security hardening improvements so all users are encouraged to upgrade." No numbers, no details. Only the migration guide reveals what was actually fixed.

And that guide lists around eight further security-related changes beyond these two: rejecting empty continuation frames, rejecting oversized frames, rejecting carriage-return / newline / null characters, capping integer digits, and more — all the same family of hardening. The vendor also writes that "a few more security oriented releases" are coming, and that they will "address increased threats from AI agents usage." It is reasonable to assume these two are not the whole batch.

RabbitMQ has issued no advisory as of publication. Neither CVE appears in CISA's catalogue of vulnerabilities confirmed under attack (KEV), and no exploitation has been reported. This is simply very early — nobody is talking about it yet.

Who else ships this code

Cowboy and Cowlib are the de facto standard in the Erlang and Elixir world. Cowboy has around 146 million all-time package downloads and Cowlib around 102 million; in the last week alone they saw roughly 294,000 and 318,000.

Beyond RabbitMQ, affected software includes EMQX (IoT messaging), MongooseIM, VerneMQ, Livebook, Supabase Realtime and Plausible Analytics. Note that EMQX and Kazoo carry their own patched forks of Cowboy, so a version bump alone will not pull in the upstream fix — those users wait on their respective vendors.

Elixir's Phoenix framework is mostly clear. Since v1.7.11 in February 2024, newly generated applications default to the Bandit web server instead of Cowboy, and Bandit does not use Cowlib. Applications generated before that, or ones that explicitly select Cowboy, are affected. Check your project's dependency lock for Cowboy.

Confirmed unaffected: ejabberd, Apache CouchDB, Riak, Erlang/OTP itself, and Nerves — all of which use different web server implementations.

Summary

Cowlib's CVE-2026-59248 (CVSS 4.0 8.7) and Cowboy's CVE-2026-65624 (6.9) are both uncapped header-parsing flaws that let an unauthenticated attacker exhaust memory. The component fixes are out: Cowlib 2.19.0 and Cowboy 2.18.0.

The large downstream impact is RabbitMQ, where every released version including the latest 4.3.4 is affected and no fixed release exists yet. The management and metrics ports are hit before authentication, so passwords are no defence. Restricting who can reach those ports is the only practical measure right now.

On top of that, no GHSA exists so Dependabot stays quiet, and the vendor announcement carries no CVE numbers. Wait for automated alerts and these two will pass you by. The vendor has also signalled that more security releases are coming. We will update this article when a fixed RabbitMQ ships, further CVEs land, or exploitation is confirmed.

Sources

• ▸ Erlang Ecosystem Foundation - CVE-2026-59248 advisory (Cowlib)
• ▸ Erlang Ecosystem Foundation - CVE-2026-65624 advisory (Cowboy)
• ▸ NVD - CVE-2026-59248
• ▸ NVD - CVE-2026-65624
• ▸ Nine Nines - Cowboy 2.18, Cowlib 2.19, Gun 2.5, Ranch 2.2.1 release post
• ▸ Nine Nines - security strategy
• ▸ Cowlib - fix commit for CVE-2026-59248
• ▸ Cowboy - fix commit for CVE-2026-65624
• ▸ OSV - EEF-CVE-2026-59248
• ▸ Hex - cowboy package (download counts and versions)
• ▸ RabbitMQ - server source (dependency pins verified here)