CISA added CVE-2026-34197 to its KEV catalog on April 16 after confirmed active exploitation. Over 6,400 Apache ActiveMQ instances are publicly reachable and vulnerable, with 1,334 in Europe alone. Here is what the attack looks like and what to fix.
Apache ActiveMQ Classic — a widely deployed open-source message broker used in enterprise middleware, financial services systems, and ERP integrations — has a critical remote code execution vulnerability that has been latent for over a decade. CVE-2026-34197 was publicly disclosed in early April 2026, added to the CISA Known Exploited Vulnerabilities catalog on April 16, and federal agencies were given until April 30 to remediate. The CVSS base score is 8.8.
What makes this case technically significant is that the exploit path runs through Jolokia — the JMX-HTTP bridge that ActiveMQ Classic exposes at /api/jolokia/ on its web console. This interface has been a standard part of ActiveMQ deployments for years, rarely scrutinized by network defenders because it is treated as an internal management component rather than an attack surface. The Shadowserver Foundation identified 6,364 vulnerable and publicly reachable ActiveMQ instances on April 19 alone. Europe accounts for 1,334 of those.
The Jolokia API by default permits exec operations on all ActiveMQ MBeans matching org.apache.activemq:*. This includes BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). An attacker who can reach the /api/jolokia/ endpoint sends a crafted POST request invoking one of these management operations with a URI pointing to an attacker-controlled server. ActiveMQ then fetches a remote Spring XML configuration file from that location and instantiates all bean definitions in it, which allows arbitrary Java execution — including OS command execution.
In practical terms: if the web console is internet-facing, or reachable from a compromised internal host, an attacker sends one HTTP request and receives a shell. There is a particularly dangerous combination here. ActiveMQ versions 6.0.0 through 6.1.1 are affected by a separate vulnerability, CVE-2024-32114, which removes the /api/* path from the web console security constraints — leaving Jolokia completely unauthenticated. On those versions, CVE-2026-34197 enables fully unauthenticated RCE with a single request. Fortinet FortiGuard Labs telemetry shows exploitation attempts peaking on April 14, two days before the KEV listing.
ActiveMQ is not a niche tool. It holds roughly 3.8% of the enterprise application integration market and is deployed across more than 7,000 organizations globally, with heavy representation in financial services, IT services, and manufacturing — all sectors with significant DACH presence. In mid-market infrastructure, message brokers like ActiveMQ often appear in integration layers between ERP systems, HR platforms, and external data feeds. These components frequently run with elevated service account privileges and broad internal network access. If compromised, they offer lateral movement potential well beyond the broker itself.
The European exposure count of 1,334 servers reflects a common deployment pattern: ActiveMQ instances deployed as "internal" middleware whose web console was left reachable from the internet during initial setup and never restricted. BSI-Grundschutz and NIS2 Article 21 both require organizations to actively manage network exposure for critical infrastructure components. A publicly reachable management interface on a production message broker fails that standard directly. For NIS2-relevant organizations, this event also has a documentation dimension: the inability to quickly determine which ActiveMQ versions are deployed where is itself a reportable gap in asset management.
Start with inventory. Map all ActiveMQ Classic instances across your environment, including instances running in containerized workloads and cloud-hosted integration platforms. For each instance, determine: the exact version, whether the web console port (typically 8161) is reachable from untrusted networks, and whether the /api/jolokia/ endpoint responds to unauthenticated requests. A simple check using curl -s http://<host>:8161/api/jolokia/version can confirm whether Jolokia is exposed and unauthenticated. Any response other than a 401 or 403 is a problem.
Temporary containment while patching is underway: restrict network access to the ActiveMQ web console (port 8161) to specific internal management hosts only. If the application does not require Jolokia at all, disable the endpoint by modifying the jetty.xml configuration to remove the /api/* path entirely from the web application context. Review access logs for the /api/jolokia/ path for POST requests made in the past 30 days — particularly those referencing external URIs in the request body — as these are strong indicators of exploitation attempts or successful compromise.
Apache has released patches for both active branches. For the 5.x branch, upgrade to ActiveMQ Classic 5.19.4 or later. For the 6.x branch, upgrade to 6.2.3 or later. Consult the official Apache ActiveMQ Security Advisories page to confirm the latest patched release before applying. After patching, the fix restricts the set of MBeans accessible via Jolokia exec operations, preventing the addNetworkConnector and addConnector calls from accepting external URIs.
Post-patch hygiene matters as much as the patch itself. Rotate credentials associated with the ActiveMQ service account. If your investigation identified any external HTTP requests originating from the broker process to unexpected destinations, treat those instances as compromised and initiate incident response. Check for unexpected JAR files, Spring XML configs, or scheduled tasks on the broker host. Preserve system logs from the last 30 days before applying changes, as forensic reconstruction of any compromise window will require them.
Finally, document what this event revealed about your asset management. If you could not answer within one hour which ActiveMQ versions are deployed and which are internet-facing, that gap needs structural remediation — not just a one-off check. External attack surface monitoring that continuously enumerates exposed management interfaces provides the visibility needed to move faster on the next KEV event. The 13-year lag between introduction and discovery of this vulnerability is a useful reminder: management interfaces treated as internal-only rarely stay that way in practice.
Get a comprehensive threat briefing for your organization — exposures, breached credentials, and actionable recommendations.
CISA has KEV-listed CVE-2026-20131 after active exploitation. Security teams should treat Cisco firewall management exposure as an immediate remediation priority.
Thousands of FortiGate firewalls are still running with factory default credentials. Here's why this keeps happening and what attackers do with that access.
NIS2 Article 21 requires organizations to implement risk-based vulnerability management — but most teams focus on the scanning side and miss the exposure side. Here is what the directive actually demands, where the gap is, and how to close it.