ActiveMQ Shut Down Without Login: CVE-2026-59878, Fix in 5.19.9/6.2.8

Two vulnerabilities have been disclosed in Apache ActiveMQ, the message broker that quietly shuttles data between business systems. One lets an attacker stall the broker with no login and no account at all (CVE-2026-59878). The other lets a low-privilege user push messages into destinations they should be refused (CVE-2026-61487). Apache announced both on July 27, 2026, and shipped fixes the same day.

Let us be clear up front. Neither of these is a "your server gets taken over" bug. ActiveMQ has a genuine track record of being taken over, and that memory makes people flinch reflexively, but this pair is a different animal. 59878 lets someone stop the thing. 61487 lets someone write where they should not be able to write. Get that line wrong and you either declare a needless emergency, or you miss the configuration that actually matters.

ActiveMQ is a Java message broker — software that sits between applications and passes data between them. It links an order system to an inventory system, a core banking system to a reporting system. That makes it the spine of system-to-system integration, which is exactly why "it stops" carries far more weight than the casual word "DoS" suggests. This article works through, from primary sources only, which CVE actually applies to your environment, how to decide, how to check your version, and how far you need to go.

What was disclosed

On July 27, 2026, ActiveMQ committer Christopher L. Shannon posted two advisories to the oss-security mailing list (the CVE-2026-59878 announcement and the CVE-2026-61487 announcement). The same text appears on Apache's official security advisories page. Both landed in the US National Vulnerability Database (NVD) the following day, July 28.

Fixes went out across three lines on that same July 27. According to ActiveMQ's official release news, the 5.19 line got 5.19.9, the 6.2 line got 6.2.8, and a brand-new 6.3.0 shipped the same day. All three are on Maven Central — you can see the artifacts in the activemq-broker distribution directory. In other words, this is not a "waiting for a patch" situation. Upgrade and it is fixed.

One naming note: the similarly named Apache ActiveMQ Artemis is not in scope. The official advisories list only ActiveMQ Classic artifacts (activemq-broker, activemq-amqp, activemq-all, apache-activemq). If you run Artemis, these two do not apply to you.

The two vulnerabilities at a glance

The most striking thing in that table is that the vendor's ranking and the CVSS ranking are upside down relative to each other. Apache calls 59878 "moderate" and 61487 "important". The numbers say 59878 is 7.5 High and 61487 is 6.5 Medium. The reason is that the CVSS formula weighs whether a login is needed very heavily. 59878, which anyone can try unauthenticated, scores up; 61487, which presumes credentials, scores down. Apache, meanwhile, is looking at the weight of an authorization boundary being broken, and puts 61487 higher.

Where the numbers come from matters too. As of July 29, 2026 both entries sit at "Awaiting Analysis" in NVD, meaning NVD has not issued its own score yet. The 7.5 and 6.5 above come from CISA's enrichment program acting as a secondary scorer. It is the same shape as the Apache Tomcat case where "9.1" clashed with a vendor rating of "Low", and the lesson repeats: deciding urgency from a scanner's number alone is a mistake.

Two bugs, two different attackers, two different doors

The two bugs attract completely different faces. The people who will try 59878 are automated scanners hammering their way across internet ports, and anyone whose actual goal is to halt your operations. No login, no account, so there is no skill barrier at all. 61487 is the reverse: it starts with an internal user who already holds a connection username and password, or an account you handed to a contractor or trading partner. This is not about someone breaking in from outside. It is about someone who is already inside.

One goes after the connection handlers, the other after the destination label. Even the parts they lay hands on fail to line up. With 59878 an attacker sends broken size values to silence the connection handlers one at a time, and once they are all gone, legitimate connections cannot be served either. With 61487 the attacker crafts a destination name so that a message lands in a queue that should have answered "you cannot write there". The first blocks every counter window; the second pries open a window that was meant to stay shut.

A queue that stops moving, versus a queue with someone else's messages stacked into it. Where each one ends up is opposite too. If 59878 lands, traffic between the systems joined by ActiveMQ stops. Orders do not flow, stock does not update, notifications do not arrive. To an end user it looks like "the site is up but my transaction never completes" — the kind of outage that is hard to trace. The 61487 damage is quieter. Messages from outside slip into areas you had separated with ACLs (per-destination read and write permissions). In a multi-tenant setup with a queue per customer, or a deployment where write rights are split by department, this means someone can stack forged requests onto another party's work queue. The awkward part is that the organizations that carefully designed and maintained those ACLs are exactly the ones whose assumptions break. Where no such rules exist, there was no wall to defeat.

CVE-2026-59878: killing the connection handlers one by one, without a login

Apache's official advisory puts it this way: "A remote unauthenticated peer that can reach an exposed AMQP NIO connector can trigger denial-of-service behavior by sending a frame size value. This cause the NIO threads to die and if done rapidly enough can lead to exhaustion of the NIO thread pool denying service to other connections."

Read the fix commit and the mechanism is plain. In ActiveMQ's AMQP handling, the broker reads a leading "how many bytes is this frame" value and then allocates a buffer of that size. That value is unsigned on the wire — it never legitimately goes negative — but the implementation read it as a 32-bit signed integer. And the only check was "is it larger than the maximum?" Which means a negative value was judged "small, therefore safe" and sailed straight through. Allocating a buffer of negative size throws an exception, and the thread handling it simply dies. Repeat that fast enough and the pool of threads that serve connections runs dry, so legitimate clients cannot connect either.

The fix landed in a July 1, 2026 commit titled "Add better frame size validation for AMQP". It rejects negative values, compares as unsigned, and additionally refuses frames smaller than the minimum viable 8 bytes. The same commit tightens validation on the OpenWire side. Alongside it, 5.19.9 lowered the default maximum frame size in the shipped configuration from 100 MB (104857600) to 10 MB (10485760).

This is where it starts to matter in practice: the missing check lived in the NIO-only code path (AmqpFrameParser). Trace the source and the only users of that class are AmqpNioTransport and AmqpNioSslTransport — that is, connectors listening on amqp+nio:// and amqp+nio+ssl://. The path taken by plain amqp:// explicitly rejected non-positive values even before the fix. So the deciding question is not "do you use AMQP?" but "do you listen for AMQP over NIO?"

CVE-2026-61487: a "temporary destination" label that skips the permission check

The official advisory reads: "An authenticated low-privilege user can bypass a per-destination write ACL by sending to an ActiveMQ temporary composite destination whose physical name is a comma-separated composite of real queues. This allows publishing messages to any of the destinations in the list without proper write ACL permissions because the authorization check is bypassed due to the composite destination being marked as temporary."

Two features make this readable. The first is composite destinations: in ActiveMQ you can name a destination QUEUE.A,QUEUE.B with commas, and one send delivers to all of them. The second is temporary destinations: throwaway destinations created per connection so a request can be matched to its reply. Because their names are generated dynamically, you cannot write individual ACLs for them, so ActiveMQ handles them with a dedicated blanket allow/deny setting.

The problem was what happened when both applied at once. Look at the diff of the July 15, 2026 fix commit "Ensure composite temp dests are handled in AuthorizationBroker" and you see that the old authorization code checked "is this temporary?" first, and if so consulted only the blanket temporary-destination setting, never unpacking the comma-separated contents. So attaching a "temporary" label to a string listing real queue names skipped the per-destination write check entirely. The fixed version pulls each member out of a composite temporary destination and computes the permission set the same way it does for ordinary composite destinations.

This one bites environments that actually configure per-destination ACLs. If you only require authentication — anyone who can log in can write anywhere — there was no wall to break in the first place. Which makes the risk profile the exact opposite of an unauthenticated flaw such as the Apache MINA issue that needs no credentials at all. Here, the more carefully you split permissions, the more you need to check.

This is not "ActiveMQ got taken over again"

There is a reason the name ActiveMQ makes people tense up. This product has a real history of being used by ransomware crews. But this pair is a different species, and confusing them produces misinformation, so let us separate the history from where today's disclosures sit.

On October 25, 2023, a remote code execution flaw in ActiveMQ's OpenWire protocol was disclosed as CVE-2023-46604. Crafted data caused the broker to instantiate arbitrary classes on its classpath, ending in OS command execution. Proof-of-concept code circulated, and on October 27 Rapid7 detected real exploitation, reporting that it was being used to deploy HelloKitty ransomware. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on November 2, 2023, and the raw KEV data still records it as known ransomware campaign use. Shadowserver counted 3,326 internet-exposed instances as of November 1, and later tallies of unpatched servers were reported at around 6,400.

Then in April 2026, ActiveMQ made its second trip into KEV, with CVE-2026-34197. That one abused Jolokia — the mechanism the web console exposes for driving Java management operations over HTTP — using a crafted URI to load a remote configuration file and run arbitrary code. CISA added it to KEV on April 16, 2026 with a remediation deadline of April 30. How it was found also drew attention: Naveen Sunkavally of Horizon3.ai pointed the generative AI Claude at the code and dug out a defect that had been sitting there for 13 years.

After the KEV listing, Shadowserver started scanning for it daily and reported 6,364 vulnerable IPs as of April 19. That is a useful number: it says ActiveMQ sits directly on the internet in non-trivial quantities.

That is the history. And today's two do not join that lineage. 59878 stops the service; no code runs. 61487 writes messages; nothing escapes the broker. Neither has an EPSS score — the estimated probability of exploitation — yet, and neither appears in the KEV catalog (version 2026.07.27, 1,655 entries). No proof-of-concept code and no exploitation has been reported. CISA's SSVC assessment marks both as no observed exploitation.

That said, "it is only a DoS, so it is minor" is also wrong. ActiveMQ is the spine of system integration, and when it stops, the business riding on it stops. 59878 demands no credentials, so anyone can try it once the conditions line up — CISA's SSVC assessment flags it as automatable. The history is not evidence that this one is another RCE. It is context: this product remains a target of sustained attacker interest.

2026 has been an unusual year for ActiveMQ

One more piece of background. The volume of ActiveMQ disclosures in 2026 is abnormal. Count the CVE identifiers on Apache's official security advisories page and the 2026 entries come to 24. For 2025 there were four. Six times as many.

The product did not suddenly break. What changed is that more people — and more tooling — started reading the code seriously. April's CVE-2026-34197, dug out with AI assistance, drew attention, and researchers and audit firms moved into the ActiveMQ codebase together. By late April a cluster of CVEs was published at once, including a bypass of the 34197 fix and other Jolokia-borne routes.

61487 belongs to that same wave. Apache's advisory credits the finder as "Claude and Ada Logics". Ada Logics is a firm that does open source security auditing; combining that with AI, they read the ActiveMQ code and found the gap in its authorization handling. Much like the AI-discovered Apache HTTP/2 stall attack, it marks the arrival of an era in which the branch nobody ever revisited, in code that had been running for years, gets flushed out mechanically.

For operators the implication is simple. For a while yet, treat ActiveMQ as a product with a continuous CVE stream. Rather than firefighting one at a time, build a habit of tracking the latest 5.19 or 6.2 release, and life gets easier. The same applies to open source components such as Apache Thrift that get embedded deep in integration layers.

Does this apply to your environment?

Now let us narrow it down. Even on an old version, if the conditions are not met there is no practical impact. Taking them in turn.

CVE-2026-59878: are you listening for AMQP over NIO?

Look at the <transportConnectors> block in conf/activemq.xml. You are in scope if there is a connector whose URI starts with amqp+nio:// or amqp+nio+ssl:// and its port (5672 by default) is reachable from outside. Plain amqp:// with no NIO is not the NIO connector the official advisory refers to.

What about the shipped defaults? This has changed between versions, so even an untouched installation needs checking. Lining up assembly/src/release/conf/activemq.xml across the GitHub tags gives the following.

So the shipped configuration never enables an AMQP NIO connector. On 5.19.6 and earlier, or 6.2.5 and earlier, AMQP was open over plain TCP — which is not the NIO path. And from 5.19.7 and 6.2.6, released on May 31, 2026, every additional transport besides OpenWire (AMQP, STOMP, MQTT, WebSocket) is commented out in the default configuration file, with a note explaining that additional transports are disabled by default to reduce the exposed attack surface, that you should uncomment only the protocols you actually need, and that you should prefer the secured variants in production.

So who is in scope? Organizations that deliberately rewrote the URI to amqp+nio:// to hold down thread consumption on high-connection-count deployments. ActiveMQ's own documentation presents the NIO variant as using far fewer threads than the standard connector, so people who care about capacity do choose it. If you remember editing that configuration file, check it first.

CVE-2026-61487: do you write per-destination ACLs?

Here you want the <authorizationPlugin> in conf/activemq.xml and the <authorizationEntry> elements inside it. If any line names roles per queue or topic with write="...", that is what can now be bypassed. Conversely, a deployment with only an authentication plugin (log in and you can write anywhere), or with no security configuration at all, is out of scope for this one.

Exploitation also needs a valid account. If you hand broker connection credentials to outside parties — letting a partner's or contractor's system touch queues directly — the risk is real. If every account belongs to an application under your own control, the impact narrows to "the blast radius grows if those credentials ever leak".

Version-by-version reference table

Impact and upgrade priority by product line. The package names are the dependency coordinates you would see if you embed the broker in an application.

On the 5.19 line go to 5.19.9; on 6.2 go to 6.2.8; if you are moving to a newer line, 6.3.0. Only those three series (6.3.x, 6.2.x and 5.19.x) are marked "Stable - Supported" on the official download page; the 6.0 and 6.1 lines, and everything from 5.18 back, are listed as "Deprecated" — no longer maintained. If you run 6.0.x or 6.1.x, no fix is coming for those lines, so 6.2.8 or later is the only route. Both 5.19.9 and 6.2.8 are maintenance releases, so functional incompatibility should be small. But 5.19.7 and 6.2.6 introduced several secure-by-default changes, so if you are jumping from something older than that, verify configuration compatibility first. In particular, the HTTP message servlet being disabled by default and the additional transports being commented out can leave clients unable to connect if you adopt the new defaults instead of carrying your configuration file forward.

How to check the version you are running

ActiveMQ tends to become the component nobody remembers installing. Once it is wired into a Java business system it keeps running quietly for years. Here are practical ways to read off the version.

• The web console home page: open http://host:8161/admin/ and the broker information list includes a "Version" row. Easiest option — and it doubles as a check that the console is not exposed externally.
• The startup log: data/activemq.log contains a line like Apache ActiveMQ 6.2.8 (localhost, ID:...) is starting. Since it needs no process interaction, this is the safest approach in production.
• File names: the unpacked distribution directory (apache-activemq-6.2.8) and the jar names under lib/ (activemq-broker-6.2.8.jar) carry the version.
• Embedded in an application: check the version pinned for org.apache.activemq:activemq-broker or activemq-all in pom.xml or build.gradle. It may arrive as a transitive dependency, so mvn dependency:tree or gradle dependencies gives you the value actually resolved. Having a way to list stale components hiding in your dependency graph saves the scramble every time this happens.

Note that the bin/activemq script has no option that prints the version. The available commands are things like start, console, stop, status and query; there is no activemq --version invocation. Use one of the four methods above.

JVN registration, and how much Japanese-language information exists

Status as of July 29, 2026.

Judging by past cadence, JVN registration should catch up within days to a few weeks. An absence of entries does not mean "safe"; it means the local-language information has not circulated yet. If your internal vulnerability management leans on JVN, reading Apache's own announcement is simply faster.

Other Apache disclosures landed on the same July 28. Apache Axis2/Java picked up a deserialization of untrusted data flaw in its Tribes clustering component (CVE-2026-66713, CVSS 9.8), and Apache Tomcat got a denial-of-service issue rooted in its WebSocket example application (CVE-2026-66299, CVSS 7.5). The Axis2 number stands out, so if you run Java business systems it is worth checking separately.

Which of the two applies to you decides what comes first

In priority order.

First, check whether an AMQP NIO connector is reachable from outside. If conf/activemq.xml contains amqp+nio:// and that port is reachable from the internet or from outside its segment, this is an unauthenticated flaw, so it is worth handling before anything else. If you cannot upgrade immediately, stopping that connector, binding it to an internal interface, or restricting sources at the firewall all work as interim measures. Almost no deployment needs an ActiveMQ port open to the general public.

Second, if you configure per-destination ACLs, plan the upgrade into your next maintenance window. 61487 presumes an authenticated account, so urgency drops — but as Apache's own "important" rating says, a separation you designed no longer holding is not a small thing. Pairing the upgrade with an inventory of broker credentials handed to external parties lets you do the checking and the fixing in one pass.

Third, when you do upgrade, upgrade for everything at once. ActiveMQ has 24 published CVEs in 2026, so concluding "we do not use NIO, therefore out of scope" and staying on an old build means carrying other holes. On the 5.19 line 5.19.9, and on 6.2 line 6.2.8, are the current end points for the known issues disclosed so far.

To be clear about the last point: these two do not call for stopping the service tonight to apply an emergency patch. No exploitation has been observed and no proof-of-concept code is out. But for 59878, the single question of whether an AMQP NIO port is reachable from outside is worth answering today. Once that is closed, the rest can proceed calmly and on schedule.

Frequently asked questions

Q. My scanner reports a 7.5 severity vulnerability in ActiveMQ. Should I take the service down?

A. Check the conditions first. The 7.5 belongs to CVE-2026-59878, and it only applies if an amqp+nio:// connector is reachable from outside. If your configuration file has no NIO URI, you are not on the path the official advisory describes. Even if you are, stopping the connector or restricting reachability holds the line for now. No exploitation and no published proof-of-concept code have been confirmed.

Q. Could this be used by ransomware, like the 2023 case?

A. Not directly from these two. CVE-2023-46604 in 2023 allowed arbitrary code execution on the broker, which is precisely why it became a ransomware entry point. 59878 only stops the service and 61487 only writes messages; neither can run OS commands. That said, the fact that ActiveMQ has appeared in KEV three times does not change, so measures that reduce exposure itself remain worthwhile.

Q. I run ActiveMQ Artemis. Am I affected?

A. Not by these two. The official advisories list only ActiveMQ Classic artifacts. Artemis does get its own advisories, though, so you still need to track its updates separately.

Q. We are still on the 5.18 line. What now?

A. The 5.18 line is end of life and will not receive these fixes. Independently of this disclosure, migrating to the 5.19 line is the right move. Keeping an unsupported broker wired into production is a larger risk than any individual CVE.

Summary

The two Apache ActiveMQ vulnerabilities are cleanly symmetrical in nature. CVE-2026-59878 needs no login but can only stop the service; CVE-2026-61487 needs a login but crosses an authorization boundary. Neither takes over the server. The fixes — 5.19.9, 6.2.8 and 6.3.0 — shipped on July 27, 2026, and the affected range is anything before 5.19.9, plus 6.0.0 up to before 6.2.8.

There is exactly one thing to check today. Does conf/activemq.xml contain an amqp+nio:// connector, and is that port reachable from outside? The shipped configuration never enables a NIO connector, and from 5.19.7 and 6.2.6 onward AMQP itself is disabled by default. Environments that deliberately switched to NIO for performance are the real audience for this flaw.

The other thing worth carrying away is that 2026 has been an exceptional year for ActiveMQ, with six times the disclosure volume of the previous year. Since CVE-2026-34197 was dug out with AI assistance in April, researchers and audit firms have been reading this codebase intensively. The finder field for 61487 reads "Claude and Ada Logics". Expect that current to keep running for a while, and switch from firefighting individual CVEs to routinely tracking the latest 5.19 or 6.2 release. It will be less work.

Sources

• ▸Apache ActiveMQ - CVE-2026-59878 official announcement (July 27, 2026)
• ▸Apache ActiveMQ - CVE-2026-61487 official announcement (July 27, 2026)
• ▸Apache ActiveMQ Classic - Security Advisories
• ▸Apache ActiveMQ - News (5.19.9 / 6.2.8 / 6.3.0 release announcements) (July 27, 2026)
• ▸NVD - CVE-2026-59878
• ▸NVD - CVE-2026-61487
• ▸oss-security - CVE-2026-59878 announcement (Christopher L. Shannon) (July 27, 2026)
• ▸oss-security - CVE-2026-61487 announcement (Christopher L. Shannon) (July 27, 2026)
• ▸GitHub - Add better frame size validation for AMQP (fix commit) (July 1, 2026)
• ▸GitHub - Ensure composite temp dests are handled in AuthorizationBroker (fix commit) (July 15, 2026)
• ▸GitHub - Apache ActiveMQ 5.19.9 release notes
• ▸Apache ActiveMQ - AMQP (connector configuration and the NIO variant)
• ▸CISA - Known Exploited Vulnerabilities Catalog (raw data)
• ▸CISA - KEV addition notice for CVE-2026-34197 (April 16, 2026)
• ▸Help Net Security - Claude helps researcher dig up decade-old Apache ActiveMQ RCE vulnerability (April 9, 2026)
• ▸BleepingComputer - Actively exploited Apache ActiveMQ flaw impacts 6,400 servers (November 2023)
• ▸Help Net Security - Attackers exploiting Apache ActiveMQ flaw to deliver ransomware (November 2, 2023)
• ▸FIRST - EPSS API (scoring status for both CVEs)
• ▸JVN iPedia - Japan Vulnerability Notes database