← Back to Feed CACHED · 2026-10-02 00:02:31 · CACHE_KEY CVE-2023-46604
CVE-2023-46604 · CWE-502 · Disclosed 2023-10-27

The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution.

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Unauthenticated one-packet RCE in ActiveMQ, mass-exploited by ransomware gangs since late 2023."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate exposed broker port

The attacker scans for TCP/61616 (or any configured OpenWire transport connector port). Shodan, Censys, and FOFA all index this service trivially; GreyNoise has observed continuous mass-scanning campaigns targeting this port since November 2023. As of mid-2026, Shadowserver reports over 6,500 vulnerable instances reachable from the public internet.
Conditions required:
  • Target runs ActiveMQ with OpenWire transport connector reachable over the network
Where this breaks in practice:
  • None — port 61616 is the default and is required for broker-to-client communication
Detection/coverage: Shodan dork product:ActiveMQ port:61616. Nuclei template CVE-2023-46604.yaml (JavaScript protocol probe). Nessus plugin 186219. Qualys QID 731894.
STEP 02

Send crafted OpenWire ExceptionResponse packet

The attacker sends a single TCP packet containing a serialized OpenWire command that specifies 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.
Conditions required:
  • Network connectivity to the OpenWire port
  • ActiveMQ version is vulnerable (pre-5.15.16 / 5.16.7 / 5.17.6 / 5.18.3)
Where this breaks in practice:
  • None — exploit is a single unauthenticated packet; Metasploit module is point-and-shoot
Detection/coverage: IDS/IPS signatures from Snort/Suricata (SID 1-2048890 and community rules). WAF rules are irrelevant — this is a binary protocol, not HTTP. Network-level detection requires deep packet inspection of the OpenWire framing.
STEP 03

Broker fetches and executes attacker XML

The vulnerable broker's JVM uses 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.
Conditions required:
  • Broker JVM has outbound HTTP connectivity (extremely common)
  • Target OS allows command execution by the ActiveMQ service user
Where this breaks in practice:
  • Strict egress filtering could block the XML fetch, but most message brokers need outbound connectivity
  • In-memory execution variant (Nashorn) defeats process-tree detections
Detection/coverage: Monitor for the ActiveMQ Java process spawning child processes (cmd.exe, /bin/sh, curl, wget). Outbound HTTP from the broker to unusual external IPs. Sysmon Event ID 1 with ParentImage containing activemq.
STEP 04

Post-exploitation: ransomware or lateral movement

Documented real-world outcomes include: HelloKitty ransomware deployment within hours of initial access, TellYouThePass encryption, LockBit deployment after lateral movement via RDP and LSASS credential dumping, Kinsing rootkit and cryptominer installation, and RansomHub affiliate operations. The DFIR Report's February 2026 case study showed the full chain from ActiveMQ RCE → Metasploit stager → privilege escalation → LSASS dump → lateral movement → domain compromise → LockBit deployment — all in a single intrusion.
Conditions required:
  • Successful command execution from step 3
Where this breaks in practice:
  • 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
Detection/coverage: EDR behavioral detections (ransomware canary files, mass file encryption). SIEM correlation on ActiveMQ service account performing unusual authentication (RDP, SMB, WinRM). Honeypot shares.
03 · Compensating Control

1
CRITICAL 10.0→HIGH 7.5
SEVERITY REDUCED
Block TCP/61616 (and all OpenWire connector ports) at the perimeter firewall immediately — The single prerequisite for exploitation is network reachability to the OpenWire transport connector. Blocking external access to TCP/61616, 61613 (STOMP), and any other configured connector ports eliminates the remote unauthenticated attack vector from the internet. Deploy within the noisgate CRITICAL mitigation SLA of 3 days. For internal-only brokers, restrict access to only the specific application server IPs that need to publish/subscribe via host-based firewall rules or network segmentation.
2
CRITICAL 10.0→IGNORE 0.0
SEVERITY REDUCED
Patch to fixed version (5.15.16, 5.16.7, 5.17.6, 5.18.3, or 6.x ≥6.1.4) — The only complete remediation is upgrading to a patched version. Vendor patches were released 2023-10-25. Deploy within the noisgate CRITICAL remediation SLA of 90 days. Given active ransomware exploitation and KEV listing, the effective deadline should be *hours to days*, not weeks. Coordinate a maintenance window immediately. Test in staging first if you have clustered brokers; ActiveMQ supports rolling upgrades in networked broker topologies.
3
CRITICAL 10.0→HIGH 7.0
SEVERITY REDUCED
Set ACTIVEMQ_OPTS environment variable to override OpenWire serialization — Apache published a workaround: set the JVM system property -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.
4
CRITICAL 10.0→CRITICAL 9.0
Deploy network IDS/IPS signatures for OpenWire exploitation — Snort/Suricata community rules and vendor signatures (e.g., SID 1-2048890) can detect the crafted ExceptionResponse packet. Deploy on network segments where ActiveMQ brokers reside. This is a detective control, not preventive — it alerts you to exploitation attempts but does not block them unless deployed inline in IPS mode. Pair with SIEM alerting for immediate incident response.
5
CRITICAL 10.0→CRITICAL 9.5
Monitor ActiveMQ process for child process spawning — Create EDR/Sysmon rules to alert on the ActiveMQ Java process (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.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild StatusMassively 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 AvailabilityWeaponized 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.
EPSS0.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 KEVListed 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 VectorCVSS: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 VersionsApache 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 Versions5.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 / ExposureShadowserver: ~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 / ReporterDisclosed 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 ImpactAtlassian 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.

  1. NVD — CVE-2023-46604
  2. Apache Advisory ACTIVEMQ-2023-001
  3. The DFIR Report — ActiveMQ Exploit Leads to LockBit Ransomware
  4. Rapid7 Metasploit Module
  5. VulnCheck — In-Memory ActiveMQ Exploitation
  6. Huntress — CVE-2023-46604 Exploitation Analysis
  7. Sekoia — Kinsing Exploiting ActiveMQ
  8. CISA KEV Entry
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (10.0/10)

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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously