CVE-2026-77406 in amqp091-go
Summary
by MITRE • 09/16/2026
RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.Qos in channel.go accepts negative prefetchCount and prefetchSize integers and casts them directly to uint16 and uint32 fields in the basic.qos method because validateQos is absent. Values such as -1 therefore wrap to 65535 or 4294967295 instead of being rejected. An application that permits untrusted configuration of these Qos values can unintentionally request extremely large prefetch limits, allowing a broker to deliver enough queued messages to exhaust client memory and disrupt processing. This issue is fixed in version 1.13.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the RabbitMQ amqp091-go library prior to version 1.13.0 stems from an improper input validation mechanism within the Channel.Qos function located in channel.go. This Go-based client for AMQP 0.9.1 is designed to manage message flow control between applications and message brokers by setting quality of service parameters, specifically prefetch count and prefetch size. The core technical flaw lies in the absence of a validateQos check before these integer values are processed. When an application passes negative integers for prefetchCount or prefetchSize, the library does not reject them as invalid inputs. Instead, it proceeds to cast these signed 32-bit integers directly into unsigned 16-bit and 32-bit fields respectively within the basic.qos method frame construction. This type conversion results in integer underflow behavior typical of two's complement arithmetic systems, where negative values wrap around to their maximum positive equivalents. Consequently, a value such as -1 is interpreted not as an error condition but as the largest possible unsigned integer, resulting in prefetch limits of 65535 for count and 4294967295 for size.
This technical defect creates a significant operational risk when applications allow untrusted or dynamic configuration of these QoS parameters without rigorous server-side validation on the broker side alone. By requesting an excessively large number of messages to be prefetched, a malicious actor or misconfigured client can cause the RabbitMQ broker to deliver a massive volume of queued messages to the client application in rapid succession. The immediate impact is severe resource exhaustion on the consumer end. The sudden influx of message objects consumes available memory rapidly, potentially leading to out-of-memory errors that crash the consuming process. Beyond simple crashes, this behavior disrupts normal processing workflows and can lead to denial of service conditions for other consumers sharing resources or affecting overall system stability due to excessive garbage collection pressure and context switching overhead associated with handling millions of pending messages simultaneously.
From a security classification perspective, this vulnerability aligns closely with CWE-20 Improper Input Validation, as the software fails to verify that user-supplied input falls within expected bounds before processing it. It also relates to CWE-190 Integer Overflow or Wraparound, specifically involving signed-to-unsigned conversion issues that lead to unexpected large values. In terms of attack vectors and tactics, this flaw facilitates resource exhaustion attacks which are categorized under the Defense Evasion and Impact categories in the MITRE ATT&CK framework, particularly relating to Denial of Service via consumption of resources such as memory or bandwidth. The vulnerability allows an attacker to leverage standard messaging protocols to trigger a denial of service without needing elevated privileges on the broker itself, relying instead on the client's compliance with the malformed QoS request.
Mitigation for this issue requires immediate upgrading to version 1.13.0 or later of the amqp091-go library where the validateQos function has been implemented to explicitly check and reject negative values before they are cast to unsigned types. For applications that cannot immediately upgrade, defensive programming practices must be adopted within the application layer. Developers should implement explicit range checks on prefetchCount and prefetchSize parameters prior to invoking client methods, ensuring these values remain non-negative and within reasonable operational limits defined by business logic or broker constraints. Additionally, organizations should review their message queue configurations to ensure that brokers enforce strict limits on prefetch sizes regardless of what clients request, providing a secondary layer of defense against such resource exhaustion attempts. Regular security audits of third-party library dependencies are essential to identify similar integer handling vulnerabilities in other components of the software supply chain.