Someone left the back door of the warehouse wide open and four different robbery crews already have the key
CVE-2023-46604 is a deserialization-of-untrusted-data flaw in the OpenWire protocol marshaller used by Apache ActiveMQ. An unauthenticated attacker who can reach the broker's transport connector port (default TCP/61616) sends a single crafted OpenWire command that forces the broker to instantiate a ClassPathXmlApplicationContext with an attacker-controlled URL. The broker then fetches a malicious Spring XML bean definition from the attacker's server and executes arbitrary OS commands — typically as the service account (often root or SYSTEM). Every version of ActiveMQ before 5.15.16, 5.16.7, 5.17.6, and 5.18.3 is vulnerable, spanning roughly a decade of releases. The OpenWire Legacy module shipped in ActiveMQ 6.x also carried the flaw until 6.1.4.
The vendor's CVSS 10.0 rating is *completely justified* and, if anything, undersells the operational reality. This is not a theoretical scoring exercise: CVE-2023-46604 has been weaponized by HelloKitty, TellYouThePass, LockBit, RansomHub ransomware affiliates, and the Kinsing cryptomining operation. The DFIR Report documented a full LockBit intrusion chain in February 2026 — nearly two and a half years after disclosure — originating from this single CVE. EPSS places it at the 99.89th percentile, CISA flagged it in KEV within a week of disclosure with a 'Known' ransomware tag, and Shadowserver still counts over 6,500 unpatched internet-facing instances as of April 2026. There is zero friction in the exploit chain: no auth, no interaction, no special config. The vendor severity matches reality.
4 steps from start to impact.
Locate exposed broker port
- Target runs ActiveMQ with OpenWire transport connector reachable over the network
- None — port 61616 is the default and is required for broker-to-client communication
product:ActiveMQ port:61616. Nuclei template CVE-2023-46604.yaml (JavaScript protocol probe). Nessus plugin 186219. Qualys QID 731894.Send crafted OpenWire ExceptionResponse packet
ClassPathXmlApplicationContext as the class to unmarshal, with the constructor argument pointing to an attacker-hosted URL serving a malicious Spring XML bean definition. No authentication or session establishment is required — the broker processes the packet immediately upon connection. Tooling includes the Metasploit module exploit/multi/misc/apache_activemq_rce_cve_2023_46604, VulnCheck's Go exploit (vulncheck-oss/cve-2023-46604), and at least ten Python PoC repos on GitHub.- Network connectivity to the OpenWire port
- ActiveMQ version is vulnerable (pre-5.15.16 / 5.16.7 / 5.17.6 / 5.18.3)
- None — exploit is a single unauthenticated packet; Metasploit module is point-and-shoot
Broker fetches and executes attacker XML
ClassPathXmlApplicationContext to fetch the attacker-controlled XML over HTTP/HTTPS. The XML defines a Spring bean that invokes Runtime.getRuntime().exec() with arbitrary OS commands. This executes in the broker's process context — commonly root on Linux or SYSTEM on Windows. VulnCheck demonstrated a variant that uses Nashorn scripting to execute entirely in memory, bypassing process-based EDR detections.- Broker JVM has outbound HTTP connectivity (extremely common)
- Target OS allows command execution by the ActiveMQ service user
- Strict egress filtering could block the XML fetch, but most message brokers need outbound connectivity
- In-memory execution variant (Nashorn) defeats process-tree detections
cmd.exe, /bin/sh, curl, wget). Outbound HTTP from the broker to unusual external IPs. Sysmon Event ID 1 with ParentImage containing activemq.Post-exploitation: ransomware or lateral movement
- Successful command execution from step 3
- EDR on the broker host may catch known ransomware payloads — but in-memory Nashorn variant is harder to detect
- Network segmentation may slow lateral movement, but the broker itself is already a high-value pivot point
-Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,java.util to restrict deserializable classes. This narrows the attack surface but is not a guaranteed fix — researchers have explored bypasses. Use only as a bridge while scheduling the actual upgrade. Apply within 3 days per noisgate CRITICAL mitigation SLA.java.exe or java with command line containing activemq) spawning shell processes (cmd.exe, powershell.exe, /bin/sh, /bin/bash, curl, wget). The VulnCheck in-memory Nashorn variant *bypasses* this detection, so this control is necessary but not sufficient. Residual severity remains critical because the in-memory variant succeeds silently.- WAF/reverse proxy in front of ActiveMQ — OpenWire is a binary protocol over raw TCP, not HTTP. A web application firewall cannot inspect or filter it. Deploying a WAF is irrelevant to this attack vector.
- Java Security Manager — Deprecated since Java 17 and removed in Java 21. Even when available, it was rarely configured for ActiveMQ and trivially bypassed in this exploit chain via Spring's
ClassPathXmlApplicationContext. - Upgrading Java runtime only — The vulnerability is in ActiveMQ's OpenWire marshalling code, not in the JVM itself. Running a newer JDK does not remediate the flaw. You must upgrade ActiveMQ.
- TLS on the OpenWire connector — Enabling TLS encrypts the transport but does not authenticate the client or prevent deserialization. The exploit works identically over TLS-wrapped OpenWire connections.
The supporting signals.
| In-the-Wild Status | Massively exploited. Multiple ransomware families (HelloKitty, TellYouThePass, LockBit, RansomHub) and Kinsing cryptomining have weaponized this CVE since late October 2023. The DFIR Report documented a full LockBit chain via ActiveMQ in Feb 2026. Kinsing infrastructure was still exploiting it as recently as March 2026 per Canary Intelligence. |
|---|---|
| PoC / Exploit Availability | Weaponized and commoditized. Metasploit module exploit/multi/misc/apache_activemq_rce_cve_2023_46604 (by sfewer-r7). Go exploit: vulncheck-oss/cve-2023-46604. Python PoCs: evkl1d/CVE-2023-46604, strikoder/CVE-2023-46604-ActiveMQ-RCE-Python, vulhub/vulhub. Nuclei template: javascript/cves/2023/CVE-2023-46604.yaml. VulnCheck published an in-memory Nashorn variant that evades process-based EDR. |
| EPSS | 0.99891 (99.89th percentile). This is effectively the ceiling — nearly every model input (exploit maturity, in-the-wild activity, PoC count, vendor severity) is maxed. |
| CISA KEV | Listed 2023-11-02. Due date: 2023-11-23. Ransomware flag: Known. Added within 6 days of public disclosure — one of the fastest KEV additions in 2023. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H → 10.0. Network-reachable, no privileges, no interaction, changed scope (broker compromise pivots to connected systems). The Confidentiality:Low is generous — real-world outcomes include full domain compromise. |
| Affected Versions | Apache ActiveMQ < 5.15.16, 5.16.x < 5.16.7, 5.17.x < 5.17.6, 5.18.x < 5.18.3. ActiveMQ Legacy OpenWire Module < 6.1.4. Covers all releases from roughly 4.x through 5.18.2 — about 13 years of versions. |
| Fixed Versions | 5.15.16, 5.16.7, 5.17.6, 5.18.3, 6.0.0+ (for main), 6.1.4 (for Legacy OpenWire Module). Major Linux distros backported: RHEL/CentOS via activemq-5.15.16; Debian/Ubuntu via activemq 5.16.7; downstream consumers (Atlassian Bamboo) also issued patches. |
| Scanning / Exposure | Shadowserver: ~8,000 exposed instances (April 2026 sweep). Shodan: ~6,500 unpatched as of mid-2026. Pluto Security: ~2,600 via Shodan (separate methodology). GreyNoise: continuous scanning/exploitation observed since November 2023; CVE-2023-46604 exploitation tag remains active. |
| Disclosure / Reporter | Disclosed 2023-10-27 by Apache. Discovery credited to the Alibaba Cloud Computing team (member X1r0z) who reported it to Apache. CVE reserved through MITRE. Apache published advisory ACTIVEMQ-2023-001. |
| Downstream Impact | Atlassian Bamboo Data Center/Server shipped a bundled ActiveMQ and required independent patching (Atlassian advisory). Any Java application embedding the activemq-openwire-legacy or activemq-client JAR is also potentially vulnerable if it exposes an OpenWire transport connector. |
Sources.
Why this verdict
- Zero friction in the exploit chain. The attack requires only network reachability to TCP/61616 — no authentication, no user interaction, no special configuration. A single packet triggers the full RCE. This is about as close to 'spray and pray' as enterprise exploitation gets.
- Commoditized weaponization. Metasploit module, multiple Python/Go PoCs, Nuclei templates, and an in-memory Nashorn variant are all publicly available. Script-kiddie-accessible. The exploit has been integrated into automated ransomware and cryptomining toolchains.
- Active mass exploitation across multiple threat actor classes. HelloKitty, TellYouThePass, LockBit, RansomHub affiliates, and Kinsing have all weaponized this CVE. The DFIR Report published a complete LockBit kill chain via this CVE in February 2026 — exploitation is ongoing nearly three years post-disclosure.
- Role multiplier: ActiveMQ is canonically a production middleware component — it IS the message bus. In typical enterprise deployments it sits on the application/data tier and connects to backend databases, microservices, and sometimes identity systems. Compromise of the broker gives the attacker a pivot point into the entire connected application ecosystem. The DFIR Report's LockBit case demonstrated progression from ActiveMQ → LSASS → lateral movement → domain compromise. The blast radius is host → tenant → domain → fleet depending on network segmentation. Because ActiveMQ's primary deployment role is production message infrastructure (≥80% of installs are production app-tier), the verdict floor is CRITICAL.
- Persistent exposure surface. Over 6,500 unpatched internet-facing instances remain as of mid-2026 per Shadowserver/Shodan, providing a continuously replenished target pool for automated exploitation campaigns.
Why not higher?
CVSS 10.0 is the maximum score. There is no higher severity bucket than CRITICAL. The vendor scoring is accurate and the real-world threat landscape, if anything, makes this worse than a generic 10.0 because of the breadth of active exploitation.
Why not lower?
Every single downgrade factor is absent. There is no authentication requirement, no complex precondition, no unusual configuration dependency, no user interaction, and no attacker-side complexity. The exploit is trivial, commoditized, and mass-deployed by multiple ransomware families. ActiveMQ is canonically deployed on production infrastructure where compromise leads to domain-level or fleet-level impact. The EPSS score (99.89th percentile) and CISA KEV ransomware flag confirm that theoretical severity matches operational reality. Downgrading this CVE would be malpractice.
Crowdsourced verification payload.
Run this script on each host running ActiveMQ (or remotely against hosts with SSH access). Invoke as bash check_cve_2023_46604.sh [activemq_home_dir] — defaults to /opt/activemq if no argument given. Requires read access to the ActiveMQ installation directory (no root needed). The script checks the installed ActiveMQ version against known-vulnerable ranges.
#!/usr/bin/env bash
# check_cve_2023_46604.sh — Detect CVE-2023-46604 (Apache ActiveMQ OpenWire RCE)
# Usage: bash check_cve_2023_46604.sh [/path/to/activemq]
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
AMQ_HOME="${1:-/opt/activemq}"
RESULT="UNKNOWN"
# Try to find version from activemq-broker JAR filename
find_version() {
local jar
jar=$(find "$AMQ_HOME" -name 'activemq-broker-*.jar' 2>/dev/null | head -1)
if [[ -z "$jar" ]]; then
jar=$(find "$AMQ_HOME" -name 'activemq-all-*.jar' 2>/dev/null | head -1)
fi
if [[ -n "$jar" ]]; then
basename "$jar" | grep -oP '\d+\.\d+\.\d+' | head -1
fi
}
# Try version command
get_version() {
local ver
ver=$(find_version)
if [[ -z "$ver" ]] && [[ -x "$AMQ_HOME/bin/activemq" ]]; then
ver=$("$AMQ_HOME/bin/activemq" --version 2>/dev/null | grep -oP '\d+\.\d+\.\d+' | head -1)
fi
echo "$ver"
}
version_gte() {
# Returns 0 if $1 >= $2
printf '%s\n%s' "$2" "$1" | sort -V -C
}
VERSION=$(get_version)
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — Could not determine ActiveMQ version at $AMQ_HOME"
exit 2
fi
echo "Detected ActiveMQ version: $VERSION"
# Parse major.minor
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
# Fixed versions: 5.15.16, 5.16.7, 5.17.6, 5.18.3, 6.0.0+
if [[ "$MAJOR" -ge 6 ]]; then
RESULT="PATCHED"
elif [[ "$MAJOR" -eq 5 ]]; then
case "$MINOR" in
18) version_gte "$VERSION" "5.18.3" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
17) version_gte "$VERSION" "5.17.6" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
16) version_gte "$VERSION" "5.16.7" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
15) version_gte "$VERSION" "5.15.16" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
*) RESULT="VULNERABLE" ;; # 5.0-5.14 are all vulnerable
esac
else
# Version 4.x or earlier — all vulnerable
RESULT="VULNERABLE"
fi
echo "$RESULT"
case "$RESULT" in
VULNERABLE) exit 1 ;;
PATCHED) exit 0 ;;
*) exit 2 ;;
esac