{"id":"CVE-2026-77406","aliases":["AZL-103188","AZL-103287","DEBIAN-CVE-2026-77406","EUVD-2026-80808","GHSA-rm6m-hrcw-jw33","GO-2026-6502","RHSA-2026:68290","ROOT-APP-GOBINARY-CVE-2026-77406","UBUNTU-CVE-2026-77406"],"status":"published","title":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration","description":"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.","severity":{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00524,"percentile":0.44762,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-195"],"published":"2026-09-16T14:37:36Z","modified":"2026-11-02T14:15:39Z","fixes":[{"ecosystem":"Go","package":"github.com/rabbitmq/amqp091-go","fixed_in":["1.13.0"],"sources":["ghsa","osv"]},{"ecosystem":"Azure Linux:3","package":"telegraf","fixed_in":["1.31.0-34"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"golang-github-rabbitmq-amqp091-go","fixed_in":["1.14.0-1"],"sources":["osv"]},{"ecosystem":"Root:Go","package":"github.com/rabbitmq/amqp091-go","fixed_in":["v1.10.0-aikido.7","v1.12.0-aikido.3","v1.12.0-aikido.4","v1.12.0-aikido.5","v1.12.0-aikido.6","v1.11.0-aikido.1"],"sources":["osv"]},{"ecosystem":"Root:Go","package":"rootio-github.com/rabbitmq/amqp091-go","fixed_in":["v1.10.0-root.io.7","v1.12.0-root.io.3","v1.12.0-root.io.4","v1.12.0-root.io.5","v1.12.0-root.io.6","v1.11.0-root.io.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/rabbitmq/amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.13.0"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"keda","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.14.1-19"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"telegraf","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.31.0-34"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"golang-github-rabbitmq-amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.10.0-1","1.11.0-1","1.12.0-1","1.14.0-1","1.15.0-1","1.5.0-2","1.8.1-1","1.8.1-2","1.9.0-1"]},{"source":"osv","ecosystem":"Debian:13","package":"golang-github-rabbitmq-amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.10.0-1","1.11.0-1","1.12.0-1","1.14.0-1","1.15.0-1"]},{"source":"osv","ecosystem":"Debian:14","package":"golang-github-rabbitmq-amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.14.0-1"}]}],"versions":["1.10.0-1","1.11.0-1","1.12.0-1"]},{"source":"osv","ecosystem":"Go","package":"github.com/rabbitmq/amqp091-go","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.13.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/rabbitmq/amqp091-go","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.13.0"}]}]},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"opentelemetry-collector-contrib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:0.161.0-0.1.hum1"}]}],"bundled":10},{"source":"osv","ecosystem":"Root:Go","package":"github.com/rabbitmq/amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"v1.10.0-aikido.7"},{"fixed":"v1.12.0-aikido.3"},{"fixed":"v1.12.0-aikido.4"},{"fixed":"v1.12.0-aikido.5"},{"fixed":"v1.12.0-aikido.6"},{"fixed":"v1.11.0-aikido.1"}]}]},{"source":"osv","ecosystem":"Root:Go","package":"rootio-github.com/rabbitmq/amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"v1.10.0-root.io.7"},{"fixed":"v1.12.0-root.io.3"},{"fixed":"v1.12.0-root.io.4"},{"fixed":"v1.12.0-root.io.5"},{"fixed":"v1.12.0-root.io.6"},{"fixed":"v1.11.0-root.io.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"golang-github-rabbitmq-amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.8.1-2","1.9.0-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"golang-github-rabbitmq-amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.10.0-1","1.11.0-1","1.12.0-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"golang-github-rabbitmq-amqp091-go","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.10.0-1"]}],"products":[{"vendor":"rabbitmq","product":"amqp091-go"}],"references":[{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-rm6m-hrcw-jw33","tags":["x_refsource_CONFIRM","advisory","web","article","report"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/351","tags":["x_refsource_MISC","fix","web","article","report"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/3b879e1d1d25b544e26b3bc3d7db3213203c0f3b","tags":["x_refsource_MISC","fix","web","article","report"]},{"url":"https://github.com/rabbitmq/amqp091-go/releases/tag/v1.13.0","tags":["x_refsource_MISC","web","article"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77406","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-rm6m-hrcw-jw33"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/77xxx/CVE-2026-77406.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-77406","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go","tags":["package"]},{"url":"https://access.redhat.com/errata/RHSA-2026:68290","tags":["advisory"]},{"url":"https://images.redhat.com/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-81872","tags":["report"]},{"url":"https://access.redhat.com/security/updates/classification/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77404","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77412","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77403","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77410","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77409","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77406","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-77407","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-93450","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-63209","tags":["report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_68290.json","tags":["advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2543236","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-63209","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63209","tags":["advisory"]},{"url":"https://github.com/klauspost/compress/commit/539243b8823ee8f03e49969823d57c348c917536","tags":["article"]},{"url":"https://github.com/klauspost/compress/releases/tag/v1.18.7","tags":["article"]},{"url":"https://github.com/klauspost/compress/security/advisories/GHSA-259r-337f-4rfw","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535498","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77403","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77403","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/2e0a919b89f337dbf58db2bb34ab206dac354a06","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/353","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-xwwf-m8fg-p9q2","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535489","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77404","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77404","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/743d488e46955fe7ffc55506fe2c401d01216783","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/352","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-465g-fh3v-9jw4","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535493","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77406","tags":["advisory","report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535487","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77407","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77407","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/fa013b8447eb60988db3c9281ff6b981e4d2fb4f","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/350","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-27gv-rfvv-22mv","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535494","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77409","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77409","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/5b0ccbb8d7bc3dfa18129d9b0f9256d656809494","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/349","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-wxx3-cj7g-w73j","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535500","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77410","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77410","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/91b65fa0096a99a580cf51a31b24028ff1c60382","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/346","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-r9c8-gcjp-xfwh","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535499","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-77412","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-77412","tags":["advisory"]},{"url":"https://github.com/rabbitmq/amqp091-go/commit/669b42bf7b1db76bc6d4973e3634247f680accbf","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/pull/344","tags":["article"]},{"url":"https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-4v58-74mf-rjx3","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2535727","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-81872","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-81872","tags":["advisory"]},{"url":"https://github.com/open-telemetry/opentelemetry-go/commit/ba71b09e6ed272e93a669aeaec1e98b1df4cc582","tags":["article"]},{"url":"https://github.com/open-telemetry/opentelemetry-go/issues/6797","tags":["article"]},{"url":"https://github.com/open-telemetry/opentelemetry-go/pull/8620","tags":["article"]},{"url":"https://github.com/open-telemetry/opentelemetry-go/releases/tag/sdk/log/v0.21.0","tags":["article"]},{"url":"https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hjf4-fphr-2h65","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2538979","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-93450","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93450","tags":["advisory"]},{"url":"https://github.com/go-openapi/swag","tags":["article"]},{"url":"https://github.com/go-openapi/swag/blob/v0.27.0/jsonutils/adapters/stdlib/json/adapter.go#L68","tags":["article"]},{"url":"https://github.com/go-openapi/swag/blob/v0.27.0/jsonutils/adapters/stdlib/json/ordered_map.go#L214","tags":["article"]},{"url":"https://github.com/go-openapi/swag/commit/0c24346ced59a25811e8694a915e7131d25ccb0e","tags":["article"]},{"url":"https://github.com/go-openapi/swag/security/advisories/GHSA-xh24-9qpg-8w28","tags":["article"]},{"url":"https://www.vulncheck.com/advisories/go-openapi-swag-jsonutils-before-0.27.1-uncontrolled-recursion-in-ordered-json-marshal-and-unmarshal","tags":["article"]},{"url":"https://ubuntu.com/security/CVE-2026-77406","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-77406","title":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration","description":"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.","status":"published","published":"2026-09-16T14:37:36.55Z","modified":"2026-09-16T18:35:40.903Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high","assessor":"cna"}],"cwes":["CWE-195"],"updated_at":"2026-11-02T14:20:15.712761Z"}],"euvd":[{"id":"EUVD-2026-80808","description":"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.","status":"published","published":"2026-09-16T14:37:36Z","modified":"2026-09-16T18:35:40Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high"}],"updated_at":"2026-11-02T17:28:14.33177Z"}],"ghsa":[{"id":"GHSA-rm6m-hrcw-jw33","title":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration","description":"## Summary\nA 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.\n\nIf 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.\n\n---\n\n## Vulnerability Details\n\n### Mechanism\nThe bug manifests during the structural assignment inside the channel's `Qos` method:\n\n```go\n// channel.go:795-796\nPrefetchCount: uint16(prefetchCount),  // -1 wraps to 65535\nPrefetchSize:  uint32(prefetchSize),   // -1 wraps to 4294967295\n```\n\nIn 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:\n* Passing `-1` for `prefetchCount` yields a wire value of `65535`.\n* Passing `-1` for `prefetchSize` yields a wire value of `4294967295`.\n\n### Impact\nThe AMQP broker interprets a `prefetch-count` of `65535` as an instruction to dispatch messages to the consumer with virtually no concurrency limits. \n\nIf 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.\n\n---\n\n## Attack Vector\nAn attacker who can manipulate configuration files, environmental variables, or API inputs that dictate client Qos settings can trigger an application-layer Denial of Service:\n\n1. **Malicious Input:** An attacker sets a service's prefetch configuration parameter to `-1`.\n2. **Implicit Overflow:** The application initializes the channel, executes `Qos(-1, ...)`, and transmits an unintended maximum-capacity request to the RabbitMQ/AMQP broker.\n3. **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.","status":"published","published":"2026-09-17T17:04:05Z","modified":"2026-09-17T17:04:07Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high"}],"cwes":["CWE-195"],"updated_at":"2026-11-02T14:41:18.357514Z"}],"nvd":[{"id":"CVE-2026-77406","description":"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.","status":"published","published":"2026-09-16T15:17:49.07Z","modified":"2026-09-23T18:19:19.803Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-195"],"updated_at":"2026-11-02T14:12:48.630594Z"}],"osv":[{"id":"CVE-2026-77406","title":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration","description":"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.","status":"published","published":"2026-09-16T14:37:36.55Z","modified":"2026-10-28T02:30:54.900330737Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high"}],"cwes":["CWE-195"],"updated_at":"2026-11-02T15:45:17.102988Z"},{"id":"DEBIAN-CVE-2026-77406","description":"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.","status":"published","published":"2026-09-16T15:17:49.07Z","modified":"2026-09-24T08:47:34.729051577Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"}],"updated_at":"2026-11-02T15:46:03.502256Z"},{"id":"GHSA-rm6m-hrcw-jw33","title":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration","description":"## Summary\nA 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.\n\nIf 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.\n\n---\n\n## Vulnerability Details\n\n### Mechanism\nThe bug manifests during the structural assignment inside the channel's `Qos` method:\n\n```go\n// channel.go:795-796\nPrefetchCount: uint16(prefetchCount),  // -1 wraps to 65535\nPrefetchSize:  uint32(prefetchSize),   // -1 wraps to 4294967295\n```\n\nIn 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:\n* Passing `-1` for `prefetchCount` yields a wire value of `65535`.\n* Passing `-1` for `prefetchSize` yields a wire value of `4294967295`.\n\n### Impact\nThe AMQP broker interprets a `prefetch-count` of `65535` as an instruction to dispatch messages to the consumer with virtually no concurrency limits. \n\nIf 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.\n\n---\n\n## Attack Vector\nAn attacker who can manipulate configuration files, environmental variables, or API inputs that dictate client Qos settings can trigger an application-layer Denial of Service:\n\n1. **Malicious Input:** An attacker sets a service's prefetch configuration parameter to `-1`.\n2. **Implicit Overflow:** The application initializes the channel, executes `Qos(-1, ...)`, and transmits an unintended maximum-capacity request to the RabbitMQ/AMQP broker.\n3. **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.","status":"published","published":"2026-09-17T17:04:05Z","modified":"2026-10-01T20:56:09.404088832Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high"}],"cwes":["CWE-195"],"updated_at":"2026-11-02T15:46:56.281047Z"},{"id":"RHSA-2026:68290","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update","status":"published","published":"2026-09-22T10:19:11Z","modified":"2026-10-20T10:43:37.203533689Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:53:22.406388Z"},{"id":"UBUNTU-CVE-2026-77406","description":"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.","status":"published","published":"2026-09-16T15:17:00Z","modified":"2026-10-28T20:17:35.311596763Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L","level":"high"}],"updated_at":"2026-11-02T16:57:18.015985Z"},{"id":"AZL-103188","title":"CVE-2026-77406 affecting package keda 2.14.1-19","description":"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.","status":"published","published":"2026-09-16T15:17:49Z","modified":"2026-10-31T05:32:45Z","updated_at":"2026-11-02T15:28:00.794214Z"},{"id":"AZL-103287","title":"CVE-2026-77406 affecting package telegraf for versions less than 1.31.0-34","description":"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.","status":"published","published":"2026-09-16T15:17:49Z","modified":"2026-11-02T14:15:39.642738474Z","updated_at":"2026-11-02T15:28:00.794214Z"},{"id":"GO-2026-6502","title":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration in github.com/rabbitmq/amqp091-go","description":"RabbitMQ amqp091-go: Consumer Message Flooding via Signed-to-Unsigned Integer Casting in Qos Configuration in github.com/rabbitmq/amqp091-go","status":"published","published":"2026-10-01T20:23:56Z","modified":"2026-10-01T20:45:11.270199573Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"ROOT-APP-GOBINARY-CVE-2026-77406","title":"CVE-2026-77406 in github.com/rabbitmq/amqp091-go - Patched by Root","description":"Root has patched CVE-2026-77406 in the github.com/rabbitmq/amqp091-go package for Root:Go. Multiple fixed versions available.","status":"published","published":"2026-10-20T12:55:23Z","modified":"2026-10-20T13:15:03.012115119Z","updated_at":"2026-11-02T15:53:26.76659Z"}]}}