CVE-2026-41044 · Apache ActiveMQ Classic RCE via Malicious Broker Name and…

01 · The Real Story

The locksmith changed the deadbolt but forgot the side door has the same key

CVE-2026-41044 is a code-injection vulnerability in Apache ActiveMQ Classic that lets an authenticated attacker craft a malicious broker name through the admin web console, embedding an xbean: binding that passes broker-name validation. When the attacker subsequently uses the DestinationView MBean (via Jolokia on port 8161) to send a message that triggers vm:// transport creation, ActiveMQ loads the attacker-controlled Spring XML context through ResourceXmlApplicationContext. Because Spring instantiates all singleton beans *before* BrokerService validates the configuration, arbitrary OS commands execute via Runtime.exec() on the broker's JVM. Affected versions: all ActiveMQ Classic < 5.19.6 and 6.0.0 – 6.2.4; fixed in 5.19.6 and 6.2.5.

The vendor's HIGH / 8.8 rating is honest and, if anything, slightly generous to defenders. CVE-2026-41044 is one of *two* patch-bypass siblings (alongside CVE-2026-40466) of CVE-2026-34197, which the original Jolokia-to-addNetworkConnector RCE that CISA added to the KEV catalog on April 16 2026 after confirmed active exploitation. Organisations that rushed to deploy 5.19.4 / 6.2.3 for the KEV entry may now sit in a false-safe window — versions 5.19.4–5.19.5 and 6.2.3–6.2.4 closed the first vector but remain fully exploitable via *this* vector. The PR:L in the CVSS vector assumes the attacker needs valid credentials, but ActiveMQ ships with admin:admin and many production brokers never rotate it. FOFA indexed 3 million+ ActiveMQ fingerprints in the past year, and prior scans surfaced ~70,000 vulnerable instances. Combined with a public PoC, the effective real-world risk is at the top of HIGH.

"Patch bypass of actively exploited ActiveMQ RCE - default creds make auth friction illusory"

02 · The Attack Path

6 steps from start to impact.

STEP 01

Reach the Jolokia endpoint

The attacker identifies an ActiveMQ Classic web console on port 8161, which ships enabled by default with Jolokia (/api/jolokia/) exposed. Scanning with Shodan, FOFA, or Censys for app="APACHE-ActiveMQ" returns millions of results. The attacker needs HTTP(S) connectivity to this port.

Conditions required:

Network path to ActiveMQ web console on port 8161

Where this breaks in practice:

Well-managed enterprises restrict 8161 to management VLANs or localhost
Cloud security groups should not expose 8161 to 0.0.0.0/0

Detection/coverage: Shodan/Censys/FOFA exposure queries; Tenable plugin 310128; external ASM tools flag exposed Jolokia endpoints

STEP 02

Authenticate to the admin console

The attacker logs in to the web console using valid credentials. Default credentials are admin:admin in most ActiveMQ deployments and are rarely changed. On versions 6.0.0–6.1.1 (CVE-2024-32114), the Jolokia endpoint required zero authentication, making this step free. For all other versions, default-cred spraying or credential stuffing suffices.

Conditions required:

Valid web console credentials or a version with unauthenticated Jolokia

Where this breaks in practice:

Organisations that rotated defaults and enforced strong passwords block this step
MFA on management interfaces would stop credential reuse

Detection/coverage: Failed login attempts in Jetty access logs; brute-force detection on 8161

STEP 03

Inject malicious broker name

Through the admin console UI or a direct Jolokia REST call, the attacker creates or renames a broker with a name containing an xbean:http://<attacker>/evil.xml payload. The broker-name validation in versions < 5.19.6 / < 6.2.5 does not strip or reject embedded xbean URIs. This plants the malicious binding in the broker registry without executing it yet.

Conditions required:

Authenticated session from step 2
Unpatched ActiveMQ < 5.19.6 or 6.0.0–6.2.4

Where this breaks in practice:

Patching to 5.19.6 / 6.2.5 adds validation that rejects the payload

Detection/coverage: Audit broker configuration changes; alert on broker names containing xbean: or http://

STEP 04

Host malicious Spring XML payload

The attacker stands up a lightweight HTTP server hosting a Spring XML context file containing a MethodInvokingFactoryBean that calls Runtime.getRuntime().exec() or ProcessBuilder. This is trivially hosted on any VPS or cloud function. The XML can include a reverse shell, coinminer, or C2 beacon drop.

Conditions required:

Outbound HTTP from the ActiveMQ host to attacker-controlled server

Where this breaks in practice:

Egress filtering / proxy that blocks unknown outbound HTTP from servers
DNS-layer security that sinkhole unknown domains

Detection/coverage: Outbound HTTP from ActiveMQ process to non-whitelisted IPs; DNS queries to novel domains

STEP 05

Trigger VM transport via DestinationView MBean

The attacker uses the Jolokia API to call the DestinationView MBean's sendTextMessage operation, targeting a destination that triggers vm:// transport creation referencing the poisoned broker name from step 3. ActiveMQ's transport factory resolves the vm:// URI, encounters the embedded xbean: config URL, and calls ResourceXmlApplicationContext to fetch and parse it.

Conditions required:

Steps 3 and 4 completed
Jolokia access (same session)

Where this breaks in practice:

If outbound fetch from step 4 is blocked, the transport creation fails gracefully

Detection/coverage: Log entries showing vm:// transport creation with brokerConfig=xbean:http; JMX operation audit logs

STEP 06

Arbitrary code execution on broker JVM

Spring instantiates all singleton beans in the malicious XML before BrokerService validates the configuration. The attacker's Runtime.exec() bean fires, executing arbitrary OS commands with the privileges of the ActiveMQ service account (often root/SYSTEM in lazy deployments). Full RCE is achieved. The public PoC by mrillicit (GitHub) confirms this path end-to-end.

Conditions required:

Steps 1–5 succeeded
ActiveMQ service account has OS-level privileges

Where this breaks in practice:

Running ActiveMQ as a low-privilege service account limits post-exploitation blast radius
Application-layer sandboxing (containers, SELinux) constrains exec

Detection/coverage: EDR/HIDS alerting on child processes spawned by the ActiveMQ JVM (java → sh/cmd); Sysmon Event ID 1 with ParentImage containing activemq

03 · Compensating Control

HIGH 8.5→LOW 3.5

SEVERITY REDUCED

Block or restrict port 8161 to management-only networks immediately — The entire attack chain requires HTTP access to the ActiveMQ web console / Jolokia endpoint on port 8161. Apply firewall rules (host-based and network-level) to restrict 8161 to jumpbox/bastion IPs or localhost only. This is the single highest-ROI control and should be deployed within the noisgate mitigation SLA of 30 days (but given the KEV-listed sibling, treat as urgent — aim for days, not weeks).

HIGH 8.5→MEDIUM 6.0

SEVERITY REDUCED

Rotate admin console credentials from defaults — Change the web console password from admin:admin to a strong, unique credential. Edit conf/jetty-realm.properties (Classic 5.x) or the appropriate JAAS config (6.x). This converts PR:L to PR:H in practice, blocking the most common exploitation path. Deploy within the noisgate mitigation SLA of 30 days.

HIGH 8.5→MEDIUM 5.5

SEVERITY REDUCED

Block outbound HTTP from ActiveMQ hosts to untrusted destinations — The exploit requires the ActiveMQ broker to fetch a malicious Spring XML file over HTTP from an attacker-controlled server. Egress filtering that restricts the broker's outbound HTTP to known-good update/dependency sources breaks step 4 of the attack chain. Configure proxy allowlists or firewall egress rules. Deploy within 30 days.

HIGH 8.5→IGNORE 0.0

SEVERITY REDUCED

Patch to ActiveMQ 5.19.6 or 6.2.5 — The definitive fix. Versions 5.19.6 and 6.2.5 add validation that rejects vm:// transport schemes and sanitizes broker names against xbean: injection. This also closes companion CVE-2026-40466. Target deployment within the noisgate remediation SLA of 180 days, but prioritize sooner given the sibling KEV listing and active exploitation of the same attack surface.

HIGH 8.5→HIGH 7.0

Run ActiveMQ under a dedicated low-privilege service account — If the broker JVM runs as root/SYSTEM, successful exploitation yields full host control. Running under a dedicated unprivileged account (activemq:activemq) with no sudo/admin rights limits post-exploitation to the broker's data and network context. Apply as part of standard hardening.

What doesn't work

WAF in front of ActiveMQ — Jolokia uses standard POST requests with JSON payloads that look like legitimate management traffic; generic WAF rules will not distinguish malicious MBean calls from normal operations without custom signatures specific to the sendTextMessage + vm:// pattern.
Disabling the OpenWire protocol — This CVE does not use OpenWire (unlike CVE-2023-46604); it operates entirely through the HTTP/Jolokia management plane, so protocol-level restrictions on AMQP/STOMP/OpenWire are irrelevant.
Java Security Manager — Deprecated since Java 17 and removed in Java 24; even where available, ActiveMQ's own code requires broad permissions that an attacker's Runtime.exec() bean inherits.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	Not confirmed for CVE-2026-41044 specifically, but its sibling CVE-2026-34197 (same Jolokia RCE class) was added to CISA KEV on April 16 2026 with confirmed active exploitation. Threat actors scanning for exposed ActiveMQ Jolokia endpoints were observed by multiple vendors. The bypass nature of -41044 means existing exploit tooling adapts trivially.
Proof-of-concept	Public PoC available. mrillicit/CVE-2026-41044 — a Bash script (`poc.sh`) that operates in detection-only mode by default: it queries the Jolokia API for version banners and tests the `vm://` transport scheme response to distinguish patched from vulnerable hosts. The full exploitation chain (malicious Spring XML → RCE) is documented. Researcher jsjcw is credited for the original vuln discovery.
EPSS	0.0115 (1.15% probability of exploitation in next 30 days), ~66th percentile. Note: EPSS may lag the sibling-CVE exploitation context; the bypass relationship to KEV-listed CVE-2026-34197 suggests real-world probability is higher than the model reflects.
KEV status	Not listed as of 2026-09-27. Sibling CVE-2026-34197 is KEV-listed (added 2026-04-16, deadline 2026-04-30). CVE-2026-41044 is a strong candidate for future KEV addition given it bypasses the patch that KEV mandated.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` → 8.8 HIGH. Network-accessible, low complexity, low privileges required, no user interaction. Full CIA impact. The `PR:L` is the only friction factor in the vector, and it is undercut by default credentials in practice.
Affected versions	ActiveMQ Classic < 5.19.6 (all 5.x releases) and 6.0.0 through 6.2.4. Critically, versions 5.19.4–5.19.5 and 6.2.3–6.2.4 that patched CVE-2026-34197 remain vulnerable to this bypass. Also affects embedded ActiveMQ in IBM Sterling Control Center v6.3.1.0, v6.4.1.0, v6.4.2.0.
Fixed versions	5.19.6 and 6.2.5 (released April 24 2026). IBM Sterling: iFix09 (v6.3.1.0), iFix03 (v6.4.1.0), iFix04 (v6.4.2.0). Debian/Ubuntu: check distro tracker — Tenable plugin 310128 flags unpatched distro packages.
Exposure data	FOFA: 3M+ ActiveMQ fingerprints globally in the past year (FOFA tweet). Prior Shodan scans identified ~70,000 potentially vulnerable instances and ~6,400 IPs confirmed vulnerable to the sibling CVE-2026-34197. Port 8161 (web console/Jolokia) is the attack surface.
Companion CVEs	CVE-2026-40466 — a second bypass of CVE-2026-34197 disclosed the same day, using HTTP Discovery transport redirect to `vm://`. Same CVSS 8.8, same fix versions. Treat -40466 and -41044 as a pair.
Disclosure & credit	Disclosed 2026-04-24 via Apache security advisory. Vulnerability discovered by jsjcw. PoC by mrillicit (GitHub). Sibling CVE-2026-34197 research by Horizon3.ai.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (8.5/10)

Why this verdict

Patch-bypass of KEV-listed CVE: CVE-2026-41044 circumvents the fix for CVE-2026-34197, which CISA added to the KEV catalog on April 16 2026 after confirmed exploitation. Existing attacker tooling for -34197 adapts to this vector with minimal effort. This negates any 'no exploitation observed' comfort and keeps the urgency firmly at HIGH.
Default credentials collapse PR:L to near-zero friction: ActiveMQ ships with admin:admin and the web console enabled by default. Industry surveys and prior ActiveMQ CVE post-mortems consistently show a majority of internet-facing instances retain defaults. The CVSS PR:L substantially overstates the difficulty of authentication.
Public PoC lowers the bar: The mrillicit/CVE-2026-41044 GitHub repo provides a working detection script and documents the full exploitation chain. The companion CVE-2026-40466 provides a *second* bypass path in the same advisory window. Attackers have choice of vectors.
Significant internet exposure: FOFA indexed 3M+ ActiveMQ fingerprints; ~70,000 instances were identified as potentially vulnerable in Shodan sweeps for the sibling CVE. Even if only a fraction have console-exposed-to-internet, the absolute numbers are material.
Role multiplier: ActiveMQ is a *typical-role* application-tier component (message broker). In its most common deployment, compromise yields host-level RCE + access to all queued/in-flight messages, which may contain PII, financial transactions, or healthcare HL7 data. Pivot potential to database and application tiers is real but bounded to the local application zone. ActiveMQ is NOT canonically a high-value-role component (not an IdP, DC, hypervisor, CA, or edge appliance) — ≤5% of installs occupy a role where compromise cascades to fleet-scale or identity-scale impact. The floor for this component class is HIGH given RCE impact, but not CRITICAL.
Minor downward adjustment for console placement: In properly hardened environments, port 8161 is restricted to management networks or localhost, adding one real friction layer that the CVSS vector does not credit. This justifies a modest 0.3-point reduction from the vendor's 8.8 baseline.

Why not higher?

The vulnerability does not reach CRITICAL because ActiveMQ is not a canonical high-value-role component where ≥10% of installs serve as identity, hypervisor, or edge infrastructure. The blast radius caps at host-level RCE and application-zone pivot — not fleet-scale or domain-scale compromise. Authentication is required (even if trivially bypassed in many deployments, it is a discrete step), and the web console attack surface can be firewalled.

Why not lower?

Downgrading below HIGH would require ignoring that this is a functional bypass of a KEV-listed, actively-exploited vulnerability, that a public PoC exists, and that default credentials make the auth barrier negligible. The 3M+ FOFA footprint and ~70K vulnerable-instance scan data confirm material exposure. The combination of full RCE impact, trivial exploitation complexity, and active threat-actor interest in this exact Jolokia attack surface firmly anchors the verdict at HIGH.

06 · Verification

Crowdsourced verification payload.

Run this script on each ActiveMQ host (or from an auditor workstation with HTTP access to the broker's Jolokia endpoint). Invoke as: bash check_cve_2026_41044.sh https://broker-host:8161. Requires curl and jq. No special privileges needed beyond network access to port 8161.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_41044.sh — Detect CVE-2026-41044 in Apache ActiveMQ Classic
# Usage: bash check_cve_2026_41044.sh <BASE_URL> [USERNAME] [PASSWORD]
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

BASE_URL="${1:?Usage: $0 <BASE_URL> [user] [pass]}"
USER="${2:-admin}"
PASS="${3:-admin}"
JOLOKIA="${BASE_URL}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=*"

echo "[*] Querying ActiveMQ version via Jolokia at ${BASE_URL}..."
RESP=$(curl -sk -u "${USER}:${PASS}" -w '\n%{http_code}' "${JOLOKIA}" 2>/dev/null) || true
HTTP_CODE=$(echo "$RESP" | tail -1)
BODY=$(echo "$RESP" | sed '$d')

if [[ "$HTTP_CODE" == "401" || "$HTTP_CODE" == "403" ]]; then
  echo "[!] Authentication failed (HTTP $HTTP_CODE). Cannot determine version."
  echo "UNKNOWN"
  exit 2
fi

if [[ "$HTTP_CODE" != "200" ]]; then
  echo "[!] Unexpected HTTP $HTTP_CODE from Jolokia. Is this an ActiveMQ host?"
  echo "UNKNOWN"
  exit 2
fi

VERSION=$(echo "$BODY" | jq -r '.. | .BrokerVersion? // empty' 2>/dev/null | head -1)

if [[ -z "$VERSION" ]]; then
  echo "[!] Could not extract BrokerVersion from Jolokia response."
  echo "UNKNOWN"
  exit 2
fi

echo "[*] Detected ActiveMQ version: $VERSION"

# Version comparison
vercomp() {
  printf '%s\n%s' "$1" "$2" | sort -V | head -1
}

MAJOR=$(echo "$VERSION" | cut -d. -f1)

if [[ "$MAJOR" -le 5 ]]; then
  FIXED="5.19.6"
  LOWEST=$(vercomp "$VERSION" "$FIXED")
  if [[ "$VERSION" == "$FIXED" ]] || [[ "$LOWEST" == "$FIXED" ]]; then
    echo "[+] Version $VERSION >= $FIXED — PATCHED"
    echo "PATCHED"
    exit 1
  else
    echo "[-] Version $VERSION < $FIXED — VULNERABLE to CVE-2026-41044"
    echo "VULNERABLE"
    exit 0
  fi
elif [[ "$MAJOR" -ge 6 ]]; then
  FIXED="6.2.5"
  LOWEST=$(vercomp "$VERSION" "$FIXED")
  if [[ "$VERSION" == "$FIXED" ]] || [[ "$LOWEST" == "$FIXED" ]]; then
    echo "[+] Version $VERSION >= $FIXED — PATCHED"
    echo "PATCHED"
    exit 1
  else
    echo "[-] Version $VERSION < $FIXED — VULNERABLE to CVE-2026-41044"
    echo "VULNERABLE"
    exit 0
  fi
fi

echo "[!] Unrecognized major version: $MAJOR"
echo "UNKNOWN"
exit 2