Critical Org.apache.activemq CVEs with no public exploit
4 CVEs, 3 protected by Waratek
Overview 4 matches · 3 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
3
75.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
1
25.0%
blocked by ARMR today
3
75.0%
partly blocked
0
0.0%
not blocked
1
25.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
4
100.0%
split by
peak 2 / year
2017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-27446 | Critical | 2026-03-04 | No exploit published | No public exploit | Missing Authentication for Critical Function (CWE-306) vulnerability in Apache Artemis, Apache ActiveMQ Artemis. An unauthenticated remote attacker can use the Core protocol to force a target broker to establish an outbound Core federation connection to an attacker-controlled rogue broker. This could potentially result in message injection into any queue and/or message exfiltration from any queue via the rogue broker. This impacts environments that allow both: - incoming Core protocol connections from untrusted sources to the broker - outgoing Core protocol connections from the broker to untrusted targets This issue affects: - Apache Artemis from 2.50.0 through 2.51.0 - Apache ActiveMQ Artemis from 2.11.0 through 2.44.0. Users are recommended to upgrade to Apache Artemis version 2.52.0, which fixes the issue. The issue can be mitigated by one of the following: - Remove Core protocol support from any acceptor receiving connections from untrusted sources. Incoming Core protocol connections are supported by default via the "artemis" acceptor listening on port 61616. See the "protocols" URL parameter configured for the acceptor. An acceptor URL without this parameter supports all protocols by default, including Core. - Use two-way SSL (i.e. certificate-based authentication) in order to force every client to present the proper SSL certificate when establishing a connection before any message protocol handshake is attempted. This will prevent unauthenticated exploitation of this vulnerability. - Implement and deploy a Core interceptor to deny all Core downstream federation connect packets. Such packets have a type of (int) -16 or (byte) 0xfffffff0. Documentation for interceptors is available at https://artemis.apache.org/components/artemis/documentation/latest/intercepting-operations.html . |
| CVE-2020-11998 | Critical | 2020-09-10 | Protected by Waratek | No public exploit | A regression has been introduced in the commit preventing JMX re-bind. By passing an empty environment map to RMIConnectorServer, instead of the map that contains the authentication credentials, it leaves ActiveMQ open to the following attack: https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html "A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code." Mitigation: Upgrade to Apache ActiveMQ 5.15.13 |
| CVE-2014-3600 | Critical | 2017-10-27 | Protected by Waratek | No public exploit | XML external entity (XXE) vulnerability in Apache ActiveMQ 5.x before 5.10.1 allows remote consumers to have unspecified impact via vectors involving an XPath based selector when dequeuing XML messages. |
| CVE-2014-3579 | Critical | 2017-10-27 | Protected by Waratek | No public exploit | XML external entity (XXE) vulnerability in Apache ActiveMQ Apollo 1.x before 1.7.1 allows remote consumers to have unspecified impact via vectors involving an XPath based selector when dequeuing XML messages. |