Few 2023 vulnerabilities went from disclosure to ransomware payload as quickly as CVE-2023-46604. On October 25, 2023, the Apache ActiveMQ project published a fix for an unauthenticated remote code execution flaw in its OpenWire protocol. The NVD rates it CVSS 3.1 10.0 (Critical), the maximum possible score. Within days, proof-of-concept exploits circulated and multiple ransomware operators, including HelloKitty and TellYouThePass, were dropping payloads on internet-exposed brokers.
ID and severity
CVE-2023-46604 is an unbounded deserialization vulnerability in Apache ActiveMQ, the widely deployed open-source Java message broker. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no privileges, no user interaction, with total compromise of confidentiality, integrity, and availability. When a bug requires nothing but a single TCP connection to the broker's default port, a 10.0 is warranted.
Timeline and impact
Apache disclosed the flaw and shipped patched releases on October 25, 2023. Public proof-of-concept code appeared within roughly two days, and Shadowserver reported mass scanning almost immediately. Some incident responders later traced exploitation attempts as far back as mid-October, before the public advisory. CISA added CVE-2023-46604 to its Known Exploited Vulnerabilities catalog on November 2, 2023.
The impact was severe because ActiveMQ sits in the middle of enterprise messaging, from service buses to microservice communication, and Shodan scans identified thousands of internet-exposed instances. The attacker workflow was mechanical: scan for the OpenWire port, send one crafted packet, gain code execution, then deploy ransomware or a remote access trojan.
Root cause
OpenWire is ActiveMQ's native binary wire protocol, listening by default on TCP 61616. When the broker receives certain OpenWire command types, it reads a class name and constructor argument straight off the wire and instantiates that class using Java reflection. The code path did not restrict which classes could be created.
The specific gadget used in the wild was a well-known Spring class that loads a remote application context. Conceptually, the exploit tells the broker to instantiate a class whose constructor fetches and evaluates an XML file from an attacker-controlled URL. That XML defines a bean whose initialization runs an operating-system command. In pseudo-form the malicious instruction is simply "create object of type X with argument http://attacker/poc.xml", and the broker obliges.
This is a textbook Java deserialization-style problem: untrusted input drives object instantiation, and object instantiation has side effects. It sits in the same lineage as the Apache Commons Collections gadget chains and the Struts and Log4Shell incidents. The lesson repeats because Java's reflection and serialization machinery is deeply embedded in enterprise frameworks and hard to fully sandbox.
Detection
- Inventory every ActiveMQ broker and record its exact version. Anything below 5.15.16, 5.16.7, 5.17.6, or 5.18.3 is vulnerable.
- Identify which brokers expose the OpenWire port (61616) beyond the trusted network. Internet-reachable brokers are the top priority.
- Review broker logs for exceptions referencing unexpected class instantiation or failed remote context loads around the disclosure window.
- Hunt for indicators of compromise: unexpected child processes spawned by the ActiveMQ service account, outbound connections to unknown hosts fetching XML, and new files under the broker's working directory.
Remediation and patched versions
Upgrade both brokers and clients to a fixed release: ActiveMQ 5.15.16, 5.16.7, 5.17.6, or 5.18.3 (or later). The patch adds validation so that OpenWire will only instantiate approved throwable classes rather than arbitrary types.
Layer these controls as well:
- Do not expose OpenWire (61616), AMQP (5672), or the web console (8161) to the internet. Restrict them with firewalls, VPNs, or segmentation.
- Treat any previously exposed broker as potentially compromised and investigate before returning it to service.
- Keep client libraries patched too; the advisory notes clients are also affected.
How Safeguard helps
ActiveMQ is an application dependency you ship, not a black-box appliance, which is exactly where supply chain tooling earns its keep. Safeguard's software composition analysis fingerprints the ActiveMQ version embedded in your builds and flags CVE-2023-46604 the moment it maps to a component you run, then ranks it above the noise using CISA KEV and exploitation signals. Because so many brokers ship as containers, container scanning surfaces vulnerable ActiveMQ layers before they reach production, and the Safeguard CLI lets you fail a CI pipeline when a known-exploited message broker is about to be deployed. If you are weighing that KEV-aware prioritization against a scanner you already run, the Safeguard vs Snyk comparison lays out the differences.
A patch that exists on day zero only protects you if you know the component is in your estate. Get started free or read the documentation.
Frequently Asked Questions
What is CVE-2023-46604 and why is it rated 10.0?
It is an unbounded deserialization vulnerability in Apache ActiveMQ's OpenWire protocol that lets an unauthenticated attacker instantiate arbitrary Java classes and achieve remote code execution with a single crafted packet. It scores CVSS 10.0 because it is network-reachable, needs no credentials or user interaction, and fully compromises the affected broker.
Which ActiveMQ versions are affected?
Apache ActiveMQ releases before 5.15.16, 5.16.7, 5.17.6, and 5.18.3 are vulnerable, spanning the 5.15.x through 5.18.x branches. Both brokers and Java OpenWire clients should be upgraded to a fixed version.
Was CVE-2023-46604 exploited in the wild?
Yes, extensively. Proof-of-concept exploits appeared within days of the October 25, 2023 disclosure, and ransomware groups including HelloKitty and TellYouThePass weaponized it quickly. CISA added it to the Known Exploited Vulnerabilities catalog on November 2, 2023.
How do I fix it if I cannot patch immediately?
Restrict the OpenWire port (default 61616) so it is not reachable from untrusted networks, and put the broker behind a firewall or VPN. This reduces exposure but is a mitigation, not a fix: upgrading to a patched ActiveMQ release is the authoritative remediation, and any previously exposed broker should be investigated for compromise.