Critical Amq CVEs
7 CVEs, 3 protected by Waratek
Overview 7 matches · 3 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
3
42.9%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
4
57.1%
blocked by ARMR today
3
42.9%
partly blocked
0
0.0%
not blocked
4
57.1%
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
7
100.0%
split by
peak 3 / year
20161
No exploit published1
Critical1
not blocked1
No public exploit1
20172
Protected by Waratek2
Critical2
blocked by ARMR today2
No public exploit2
20180
20190
20203
No exploit published3
Critical3
not blocked3
No public exploit3
20210
20220
20230
20240
20250
20261
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
20162017201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-40860 | Critical | 2026-04-27 | Protected by Waratek | No public exploit | JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-family components built on JmsComponent such as camel-activemq and camel-activemq6. This issue affects Apache Camel: from 3.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2. |
| CVE-2020-16971 | Critical | 2020-12-10 | No exploit published | No public exploit | Azure SDK for Java Security Feature Bypass Vulnerability |
| CVE-2019-20445 | Critical | 2020-01-29 | No exploit published | No public exploit | HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header. |
| CVE-2019-20444 | Critical | 2020-01-29 | No exploit published | No public exploit | HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an "invalid fold." |
| CVE-2017-8045 | Critical | 2017-11-27 | Protected by Waratek | No public exploit | In Pivotal Spring AMQP versions prior to 1.7.4, 1.6.11, and 1.5.7, an org.springframework.amqp.core.Message may be unsafely deserialized when being converted into a string. A malicious payload could be crafted to exploit this and enable a remote code execution attack. |
| CVE-2016-2173 | Critical | 2017-04-21 | Protected by Waratek | No public exploit | org.springframework.core.serializer.DefaultDeserializer in Spring AMQP before 1.5.5 allows remote attackers to execute arbitrary code. |
| CVE-2016-4432 | Critical | 2016-06-01 | No exploit published | No public exploit | The AMQP 0-8, 0-9, 0-91, and 0-10 connection handling in Apache Qpid Java before 6.0.3 might allow remote attackers to bypass authentication and consequently perform actions via vectors related to connection state logging. |