CVE-2026-77406

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.

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.

## Summary A logic and resource exhaustion vulnerability exists in the AMQP client's Quality of Service (`Qos`) configuration method. The `Qos` function accepts signed integers (`int`) for the `prefetchCount` and `prefetchSize` parameters but casts them directly to unsigned integers (`uint16` and `uint32`, respectively) when formatting the wire-level frame. If a developer passes a negative integer (such as `-1`) to these parameters—frequently intended as a sentinel value meaning "no change" or "no limit"—the application performs an implicit signed-to-unsigned conversion. This wraps the values to their absolute maximum limit ($65535$ and $4294967295$). Consequently, a consumer expecting restricted message delivery rates is suddenly flooded with an unlimited volume of messages, potentially exhausting memory resources and crashing the application. --- ## Vulnerability Details ### Mechanism The bug manifests during the structural assignment inside the channel's `Qos` method: ```go // channel.go:795-796 PrefetchCount: uint16(prefetchCount), // -1 wraps to 65535 PrefetchSize: uint32(prefetchSize), // -1 wraps to 4294967295 ``` In Go, converting a negative signed integer to an unsigned integer shifts the value via two's complement arithmetic. Because no boundary validation or signedness check occurs prior to the cast: * Passing `-1` for `prefetchCount` yields a wire value of `65535`. * Passing `-1` for `prefetchSize` yields a wire value of `4294967295`. ### Impact The AMQP broker interprets a `prefetch-count` of `65535` as an instruction to dispatch messages to the consumer with virtually no concurrency limits. If the application is processing heavy payloads or relies on strict rate-limiting to maintain stability, this unexpected flood will cause rapid heap memory growth, unmanageable processing queues, and an eventual Out-Of-Memory (OOM) termination. --- ## Attack Vector An attacker who can manipulate configuration files, environmental variables, or API inputs that dictate client Qos settings can trigger an application-layer Denial of Service: 1. **Malicious Input:** An attacker sets a service's prefetch configuration parameter to `-1`. 2. **Implicit Overflow:** The application initializes the channel, executes `Qos(-1, ...)`, and transmits an unintended maximum-capacity request to the RabbitMQ/AMQP broker. 3. **Consumer Exhaustion:** The broker flushes the entire contents of the queue directly into the client consumer's network buffer, bypassing expected application concurrency barriers and inducing a crash.

## Summary A logic and resource exhaustion vulnerability exists in the AMQP client's Quality of Service (`Qos`) configuration method. The `Qos` function accepts signed integers (`int`) for the `prefetchCount` and `prefetchSize` parameters but casts them directly to unsigned integers (`uint16` and `uint32`, respectively) when formatting the wire-level frame. If a developer passes a negative integer (such as `-1`) to these parameters—frequently intended as a sentinel value meaning "no change" or "no limit"—the application performs an implicit signed-to-unsigned conversion. This wraps the values to their absolute maximum limit ($65535$ and $4294967295$). Consequently, a consumer expecting restricted message delivery rates is suddenly flooded with an unlimited volume of messages, potentially exhausting memory resources and crashing the application. --- ## Vulnerability Details ### Mechanism The bug manifests during the structural assignment inside the channel's `Qos` method: ```go // channel.go:795-796 PrefetchCount: uint16(prefetchCount), // -1 wraps to 65535 PrefetchSize: uint32(prefetchSize), // -1 wraps to 4294967295 ``` In Go, converting a negative signed integer to an unsigned integer shifts the value via two's complement arithmetic. Because no boundary validation or signedness check occurs prior to the cast: * Passing `-1` for `prefetchCount` yields a wire value of `65535`. * Passing `-1` for `prefetchSize` yields a wire value of `4294967295`. ### Impact The AMQP broker interprets a `prefetch-count` of `65535` as an instruction to dispatch messages to the consumer with virtually no concurrency limits. If the application is processing heavy payloads or relies on strict rate-limiting to maintain stability, this unexpected flood will cause rapid heap memory growth, unmanageable processing queues, and an eventual Out-Of-Memory (OOM) termination. --- ## Attack Vector An attacker who can manipulate configuration files, environmental variables, or API inputs that dictate client Qos settings can trigger an application-layer Denial of Service: 1. **Malicious Input:** An attacker sets a service's prefetch configuration parameter to `-1`. 2. **Implicit Overflow:** The application initializes the channel, executes `Qos(-1, ...)`, and transmits an unintended maximum-capacity request to the RabbitMQ/AMQP broker. 3. **Consumer Exhaustion:** The broker flushes the entire contents of the queue directly into the client consumer's network buffer, bypassing expected application concurrency barriers and inducing a crash.