CVE-2026-59320 in Spring AMQP
Summary
by MITRE • 08/27/2026
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
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability described in CVE-2024-39658 represents a resource exhaustion flaw within the RabbitMQ connection handling logic of Spring AMQP version 4.1.0, specifically affecting scenarios where container-level error handlers are configured to manage message processing failures. This issue is closely related to finding 221000 and highlights a critical gap in how link credits are managed during exception propagation paths. In the Advanced Message Queuing Protocol (AMQP), particularly AMQP 0-9-1 which Spring AMQP primarily targets, flow control relies on link credits to regulate message delivery from the broker to the consumer. The receiver maintains a credit balance that dictates how many messages it is willing to accept at any given time. When an application configures a container-level ErrorHandler as a mitigation strategy for handling processing exceptions, the expectation is often that errors are caught and managed without disrupting the overall flow of the listener or connection. However, in this specific implementation flaw, every delivery that results in a thrown exception during processing permanently consumes one link credit from the receiver's allowance.
This behavior creates a silent denial-of-service condition for the application rather than an immediate crash. The system does not throw an explicit error to alert developers of the resource leak; instead, it silently depletes the available credits. By default, Spring AMQP initializes listeners with 100 initial credits. Consequently, after exactly one hundred messages fail processing due to exceptions that trigger this flawed credit consumption logic, the receiver's credit balance drops to zero. Once the credit reaches zero, the RabbitMQ broker adheres to standard protocol behavior by ceasing further message deliveries to that specific consumer link. This results in a state where the listener appears active because its internal isRunning() method continues to return true, giving developers a false sense of operational status while no new messages are actually being processed or delivered.
The impact of this vulnerability extends beyond simple service interruption. It leads to a gradual degradation of system throughput and eventual complete stagnation of message consumption without any visible alarms or exceptions in the application logs that would typically indicate a connection failure or broker rejection. This makes debugging particularly difficult, as standard health checks may report the listener as healthy while it is effectively deadlocked due to credit exhaustion. From a security perspective, this flaw aligns with CWE-400: Uncontrolled Resource Consumption, where an attacker or even normal operational error patterns can exhaust system resources leading to service unavailability. It also reflects aspects of CWE-755: Improper Handling of Unexpected Data Condition, as the framework fails to properly account for resource state changes during exceptional execution paths.
To mitigate this vulnerability and prevent silent stalls in message processing environments, developers must ensure they are not relying solely on container-level error handlers that allow exceptions to propagate without explicitly managing link credits or resetting them after failure handling. Upgrading to a patched version of Spring AMQP where the credit consumption logic is corrected for exception paths is the primary remediation strategy. Additionally, implementing custom monitoring solutions that track consumer lag and message processing rates can help detect this stall condition earlier than relying on standard health indicators. Ensuring that error handlers either successfully process messages without throwing exceptions or explicitly handle resource cleanup including link state management is crucial for maintaining robustness in high-throughput messaging architectures.