CVE-2026-42588 is an improper input validation and code injection vulnerability in Apache ActiveMQ Classic. The Jolokia JMX-HTTP bridge's default access policy allows execution of operations on ActiveMQ MBeans, including BrokerService.addNetworkConnector(String). An authenticated attacker can supply a crafted discovery URI that reaches the VM transport brokerConfig parameter through a masterslave transport URL and causes Spring ResourceXmlApplicationContext to load attacker-controlled XML. ResourceXmlApplicationContext instantiates singleton beans before BrokerService validates the configuration, permitting execution of bean factory methods such as Runtime.exec() in the broker JVM. Affected products are Apache ActiveMQ Broker, ActiveMQ All, and ActiveMQ versions before 5.19.7 and versions from 6.0.0 before 6.2.6.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
4 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
This repository is a research archive centered on Apache ActiveMQ Classic exploitation, not a single minimal PoC. It contains: (1) an original CVE-2026-34197 reproduction directory with Python exploit scripts, malicious Spring XML payloads, and a Docker lab; (2) a re-audit directory validating the RCE across multiple ActiveMQ versions with improved PoCs and bash automation; (3) a live re-audit for CVE-2026-42588 and CVE-2026-42253 with dedicated PoCs; and (4) a broader 6.2.6 source audit and findings ledger. Main exploit capability: the core exploit abuses the Jolokia JMX-over-HTTP endpoint on the ActiveMQ web console to invoke BrokerView.addNetworkConnector or addConnector with a crafted discovery URI. That URI embeds vm:// plus brokerConfig=xbean:<resource>, causing VMTransportFactory/XBeanBrokerFactory to load attacker-controlled Spring XML. The XML eagerly instantiates beans such as ProcessBuilder or Runtime.exec gadgets, yielding arbitrary command execution before broker validation. The repo demonstrates both the original remote-HTTP XML delivery (CVE-2026-34197) and the later patch-bypass logic (CVE-2026-42588), including no-paren/composite wrapper variants and a local-file xbean payload path. The exploit code is operational rather than framework-based. The Python scripts are self-contained and use only the standard library. They can host the malicious XML over an embedded HTTP server, probe Jolokia availability, discover broker names, send authenticated Jolokia exec requests with Basic auth and Origin headers, and wait for payload fetches as a success signal. The re-audit PoC in 02-reaudit-apr30/pocs/poc.py fixes earlier payload/server-timing issues and is the cleanest working implementation in the repo. A secondary exploit capability is included for CVE-2026-42253. The script 03-reaudit-42588-42253/lab/pocs/poc_42253.py targets /api/message/<queue> and demonstrates attacker-controlled JMS properties being reflected into HTTP response headers by MessageServlet, enabling arbitrary header injection, Content-Type override, cookie injection, and stored XSS. Fingerprintable targets and infrastructure are clear: the target service is ActiveMQ web console/Jolokia on port 8161, with OpenWire on 61616 in the lab. The exploit posts to /api/jolokia/, reads broker MBeans via /api/jolokia/read/..., and in the XSS PoC uses /api/message/<dest>. Attacker infrastructure is an HTTP server on ports 8888, 8889, or 9999 serving XML such as /poc-payload.xml, /evil.xml, or /poc.xml. Proof artifacts are written under /tmp on the target. Overall purpose: the repository documents exploit development, regression testing, and patch-bypass analysis for ActiveMQ Classic RCE, then extends into a broader security review of the fixed 6.2.6 release. It is a genuine exploit repository with working code, lab automation, and detailed writeups rather than a detection-only or fake project.
This repository is a minimal proof-of-concept exploit consisting of a single Spring XML bean definition file and a .gitattributes file. The XML PoC uses org.springframework.beans.factory.config.MethodInvokingFactoryBean twice: first to obtain a java.lang.Runtime instance via Runtime.getRuntime(), and then to invoke Runtime.exec() with a shell command. The hardcoded payload runs /bin/sh -c "touch /tmp/activemq_pwned", which creates a marker file to demonstrate successful code execution. The exploit’s core capability is arbitrary command execution, provided the target application deserializes, imports, or otherwise processes attacker-supplied Spring bean XML. There is no networking logic, delivery mechanism, authentication handling, or target discovery in the repository; it is only the malicious bean configuration payload. The attack is therefore best characterized as a file/web-delivered Spring XML RCE payload rather than a complete end-to-end exploit tool. Repository structure is extremely small: 2 total files, with 1 code-like artifact (the XML PoC). No framework affiliation is evident. Because the payload is hardcoded and functional, this is an operational PoC rather than a mere detection artifact.
Repository is a small standalone Python exploit for CVE-2026-42588 targeting Apache ActiveMQ Jolokia-authenticated RCE. Structure is simple: one main exploit script (CVE-2026-42588_EXP.py), one malicious Spring XML template (malicious.xml), dependency file, README, and CI metadata. The Python script uses requests and HTTP Basic Auth to interact with the target Jolokia endpoint at /api/jolokia/. It builds a JSON exec request against the default MBean org.apache.activemq:type=Broker,brokerName=localhost and invokes addNetworkConnector with a crafted masterslave:// URI containing brokerConfig=xbean:<remote_xml_url>. This causes the target to fetch attacker-controlled XML and instantiate Spring beans that execute OS commands. The script includes both detection logic (check whether Jolokia is reachable and optionally extract version info) and exploitation logic (send payload, handle HTTP/auth errors, and print guidance for asynchronous verification). The included malicious.xml demonstrates two execution paths: MethodInvokingFactoryBean calling Runtime.getRuntime().exec(), and ProcessBuilder with init-method="start". README documents prerequisites, vulnerable versions, example commands, reverse shell usage, Windows adaptation, and mitigations. Overall, this is a real operational exploit with a basic but functional payload chain rather than a mere detector.
This repository is a standalone Java Swing exploit toolkit for Apache ActiveMQ, not a Metasploit/Nuclei module. The project is Maven-based, with a single executable entry point in src/main/java/cc/kiiy/App.java that launches a GUI (MainFrame). The codebase is organized into service classes for exploitation/detection logic (EnvironmentService, VulnerabilityService), UI panels for each supported CVE and settings, and utility helpers for HTTP and local config handling. Core capability-wise, the tool supports both detection and exploitation. EnvironmentService fingerprints ActiveMQ by requesting the target URL and checking for the Apache ActiveMQ title, and can authenticate to /admin/ using HTTP Basic auth to extract hostname, version, and uptime from the admin console HTML. VulnerabilityService is the main exploit engine. For CVE-2015-5254, it accepts a user-provided Base64 serialized payload, decodes it, wraps it into an ActiveMQObjectMessage, and sends it over OpenWire/JMS to a chosen queue on tcp://<host>:<port> (default 61616), enabling broker-side deserialization when the message is processed/viewed. For CVE-2016-3088, it performs a PUT to /fileserver/<random>.txt and then a MOVE to file:///etc/cron.d/root, planting a cron entry that launches a Perl reverse shell back to the operator. This is a real exploitation path, not just a detector, but it depends on vulnerable behavior and elevated target privileges. The repository also includes support for CVE-2022-41678 workflows. Although the provided content truncates some of the implementation, the UI and service references clearly show functionality to write a default or custom webshell and then execute commands through it, with selectable methods such as auto, log4j2, and jfr. The included JfrTemplate.java contains a large embedded JFR configuration template, indicating one exploitation path abuses JFR-related file write/config behavior. BeanXmlPanel generates Spring BeanXML payloads using java.lang.ProcessBuilder for arbitrary command execution, likely intended to support XML-based ActiveMQ exploitation such as CVE-2023-46604-style xbean loading. The code also contains logic for a Jolokia-based probe labeled CVE-2026-34197 that sends an addNetworkConnector request with a vm://evil?brokerConfig=xbean:<xmlServer> argument, causing the target to fetch attacker-controlled XML from an external server. Network and fingerprintable artifacts are abundant: HTTP(S) access to the target web console and admin paths, OpenWire TCP access to port 61616, PUT/MOVE requests to /fileserver/, file destinations like file:///etc/cron.d/root, attacker XML hosting URLs, and Basic Authorization headers. The GUI exposes global custom headers and proxy settings, allowing the operator to tune requests and route traffic through a local proxy. Overall, this is an operational multi-CVE ActiveMQ exploitation toolkit with a GUI front end, combining reconnaissance, authenticated checks, payload generation, deserialization delivery, arbitrary file write abuse, XML-based RCE testing, and webshell management.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
7 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Arbitrary code execution in Apache ActiveMQ through improper input validation in the Jolokia JMX-HTTP bridge.
Apache ActiveMQ arbitrary-code-execution vulnerability in the Jolokia JMX-HTTP bridge caused by improper input validation.
A critical remote code execution vulnerability in Apache ActiveMQ involving the exposed Jolokia bridge and overly permissive default access policy, allowing authenticated attackers to execute arbitrary code.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.