WaratekVRT Sign in

Medium Vmware Spring Advanced Message Queuing Protocol CVEs

10 CVEs, 3 protected by Waratek

Reset
More filters (2)
Columns
Vendor vmware✕Product spring advanced message queuing protocol✕
Overview 10 matches · 3 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
10matches 3protected30.0% 0exploited0.0% 0CISA KEV0.0% 1public PoC10.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 3 30.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 7 70.0%
Critical 0 0.0% High 0 0.0% Medium 10 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 3 30.0% partly blocked 0 0.0% not blocked 7 70.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 10.0% Forecast only 0 0.0% No public exploit 9 90.0%
split by peak 5 / quarter
No exploit published: 7Protected by Waratek: 3 Medium: 10 not blocked: 7blocked by ARMR today: 3 No public exploit: 9Proof of concept only: 1
Q4 212 Protected by Waratek2 Medium2 blocked by ARMR today2 No public exploit2 Q1 220 Q2 220 Q3 220 Q4 220 Q1 230 Q2 230 Q3 230 Q4 231 Protected by Waratek1 Medium1 blocked by ARMR today1 Proof of concept only1 Q1 240 Q2 240 Q3 240 Q4 240 Q1 250 Q2 250 Q3 250 Q4 250 Q1 260 Q2 262 No exploit published2 Medium2 not blocked2 No public exploit2 Q3 265 No exploit published5 Medium5 not blocked5 No public exploit5
Q1 22Q3 22Q1 23Q3 23Q1 24Q3 24Q1 25Q3 25Q1 26Q3 26
10 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.