CVE-2026-59320: In Spring AMQP the link credit never replenished on listener exception path

Published Aug 27, 2026
·
Updated

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

Affected Software

1 affected component
Spring Spring AMQP=4.1.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Spring AMQP to a version that resolves this vulnerability.

    Fixed in 4.1.0
  2. Configuration

    Since configuring a container-level ErrorHandler (mitigation for finding 221000) causes each delivery whose processing throws to permanently consume one link credit (link credit never replenished on the listener exception path), adjust the ErrorHandler configuration so thrown-processing deliveries do not permanently exhaust link credit (e.g., remove/avoid the container-level ErrorHandler mitigation if not required, or change exception handling so the listener exception path does not trigger this behavior).

    Spring AMQP container-level ErrorHandler (mitigation for finding 221000) = avoid/disable if possible for listener exception path

Event History

Aug 27, 2026
CVE Published
via MITRE·06:04 PM
Data Sourced
via MITRE·06:04 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·08:17 PM
DescriptionSeverity

Frequently Asked Questions

1

Which deployments are affected?

Affected deployments use Spring AMQP 4.1.0 with a container-level ErrorHandler configured and have listener deliveries whose processing throws exceptions. The issue occurs on the exception path, where each failed delivery consumes link credit permanently.

2

How quickly can a listener stall under the default credit setting?

The default initialCredits value is 100. A listener can stall after 100 failing messages, when its available receiver credit reaches zero and the broker stops delivering messages.

3

How can operators recognize that this condition has occurred?

The listener will stop receiving deliveries because the broker has no remaining credit to send messages. The container can still report isRunning() as true, so a running-state check alone will not identify the stall.

4

What exploitation conditions are indicated by the provided severity data?

The supplied vector indicates network access, low attack complexity, low privileges required, and no user interaction. The recorded impact is availability only, with no confidentiality or integrity impact listed.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203