WaratekVRT Sign in
Reset
More filters (2)
Columns
Including CVEs outside Waratek scope✕Vendor vmware✕Product spring advanced message queuing protocol✕
Overview 11 matches · 4 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
11matches 4protected36.4% 0exploited0.0% 0CISA KEV0.0% 1public PoC9.1% 0EPSS ≥ 0.50.0%
Protected by Waratek 4 36.4% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 7 63.6% Outside Waratek scope 0 0.0% Not applicable 0 0.0% Withdrawn CVE 0 0.0%
Critical 1 9.1% High 0 0.0% Medium 10 90.9% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 4 36.4% partly blocked 0 0.0% not blocked 7 63.6% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 9.1% Forecast only 0 0.0% No public exploit 10 90.9%
split by peak 7 / year
No exploit published: 7Protected by Waratek: 4 Medium: 10Critical: 1 not blocked: 7blocked by ARMR today: 4 No public exploit: 10Proof of concept only: 1
20171 Protected by Waratek1 Critical1 blocked by ARMR today1 No public exploit1 20180 20190 20200 20212 Protected by Waratek2 Medium2 blocked by ARMR today2 No public exploit2 20220 20231 Protected by Waratek1 Medium1 blocked by ARMR today1 Proof of concept only1 20240 20250 20267 No exploit published7 Medium7 not blocked7 No public exploit7
2017201820192020202120222023202420252026
11 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-59320 Medium 2026-08-27 No exploit published No public exploit When a container-level ErrorHandler is configured (the mitigation for finding 221000), each delivery whose processing throws still permanently consumes one link credit. After initialCredits (default 100) failing messages the receiver's credit reaches zero and the broker stops delivering, leaving the listener silently stalled while isRunning() remains true. Spring AMQP 4.1.0
CVE-2026-59275 Medium 2026-08-27 No exploit published No public exploit A single hostile AMQP message can terminate the entire consumer JVM (System.exit(99)), not just the listener thread — full availability loss for every workload co-located in that process. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier
CVE-2026-59272 Medium 2026-08-27 No exploit published No public exploit Any application shipping logs to RabbitMQ over TLS via the Log4j2 appender, relying on the documented default, is exposed to man-in-the-middle interception of every log event. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier
CVE-2026-59271 Medium 2026-08-27 No exploit published No public exploit When the RabbitMQ management aliveness check fails, the configured admin password is embedded in cleartext in the thrown exception message. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier
CVE-2026-47860 Medium 2026-08-27 No exploit published No public exploit An attacker who can publish to a queue consumed by an application that has enabled message decompression can crash the consumer JVM with a single ~1 MB message. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier
CVE-2026-41714 Medium 2026-06-10 No exploit published No public exploit Applications that configure their broker connection via RabbitConnectionFactoryBean.setUri("amqps://...") without also calling setUseSSL(true) get TLS encryption with no certificate validation and no hostname verification. Affected versions: Spring AMQP 4.0.0 through 4.0.3; 3.2.0 through 3.2.10; 3.1.0 through 3.1.15; 2.4.0 through 2.4.17.
CVE-2026-41701 Medium 2026-06-10 No exploit published No public exploit Correlation IDs for replies in the RabbitTemplate.sendAndReceive() with the fixed reply queue are predictable due to internal simple counter. Affected versions: Spring AMQP 4.0.0 through 4.0.3; 3.2.0 through 3.2.10; 3.1.0 through 3.1.15; 2.4.0 through 2.4.17.
CVE-2023-34050 Medium 2023-10-19 Protected by Waratek Proof of concept only In spring AMQP versions 1.0.0 to 2.4.16 and 3.0.0 to 3.0.9 , allowed list patterns for deserializable class names were added to Spring AMQP, allowing users to lock down deserialization of data in messages from untrusted sources; however by default, when no allowed list was provided, all classes could be deserialized. Specifically, an application is vulnerable if * the SimpleMessageConverter or SerializerMessageConverter is used * the user does not configure allowed list patterns * untrusted message originators gain permissions to write messages to the RabbitMQ broker to send malicious content
CVE-2021-22095 Medium 2021-11-30 Protected by Waratek No public exploit In Spring AMQP versions 2.2.0 - 2.2.19 and 2.3.0 - 2.3.11, the Spring AMQP Message object, in its toString() method, will create a new String object from the message body, regardless of its size. This can cause an OOM Error with a large message
CVE-2021-22097 Medium 2021-10-28 Protected by Waratek No public exploit In Spring AMQP versions 2.2.0 - 2.2.18 and 2.3.0 - 2.3.10, the Spring AMQP Message object, in its toString() method, will deserialize a body for a message with content type application/x-java-serialized-object. It is possible to construct a malicious java.util.Dictionary object that can cause 100% CPU usage in the application if the toString() method is called.
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.