WaratekVRT Sign in

Critical Org.apache.activemq CVEs

7 CVEs, 2 exploited, 6 protected by Waratek

Reset
More filters (1)
Columns
Vendor org.apache.activemq✕
Overview 7 matches · 6 protected · 2 exploited · 2 CISA KEV · 3 public PoC · 2 EPSS ≥ 0.5
7matches 6protected85.7% 2exploited28.6% 2CISA KEV28.6% 3public PoC42.9% 2EPSS ≥ 0.528.6%
Protected by Waratek 6 85.7% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 1 14.3%
Critical 7 100.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 6 85.7% partly blocked 0 0.0% not blocked 1 14.3% not established 0 0.0% unrecorded 0 0.0%
Exploited 2 28.6% Working exploit published 0 0.0% Proof of concept only 1 14.3% Forecast only 0 0.0% No public exploit 4 57.1%
split by peak 2 / year
No exploit published: 1Protected by Waratek: 6 Critical: 7 not blocked: 1blocked by ARMR today: 6 No public exploit: 4Proof of concept only: 1Exploited: 2
20162 Protected by Waratek2 Critical2 blocked by ARMR today2 Exploited1 Proof of concept only1 20172 Protected by Waratek2 Critical2 blocked by ARMR today2 No public exploit2 20180 20190 20201 Protected by Waratek1 Critical1 blocked by ARMR today1 No public exploit1 20210 20220 20231 Protected by Waratek1 Critical1 blocked by ARMR today1 Exploited1 20240 20250 20261 No exploit published1 Critical1 not blocked1 No public exploit1
20162017201820192020202120222023202420252026
7 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
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-2023-46604 Critical 2023-10-27 Protected by Waratek Exploited The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution. This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the classpath. Users are recommended to upgrade both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3 which fixes this issue.
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.
CVE-2016-3088 Critical 2016-06-01 Protected by Waratek Exploited The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows remote attackers to upload and execute arbitrary files via an HTTP PUT followed by an HTTP MOVE request.
CVE-2015-5254 Critical 2016-01-08 Protected by Waratek Proof of concept only Apache ActiveMQ 5.x before 5.13.0 does not restrict the classes that can be serialized in the broker, which allows remote attackers to execute arbitrary code via a crafted serialized Java Message Service (JMS) ObjectMessage object.