Skip to main content

RabbitMQ amqp091-go CVE-2026-77410

| EUVDEUVD-2026-80810 HIGH
Memory Allocation with Excessive Size Value (CWE-789)
2026-09-16 GitHub_M GHSA-r9c8-gcjp-xfwh
8.9
CVSS 4.0 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Control or compromise the AMQP broker
  2. Delivery
    Send content header with extreme declared body Size
  3. Exploit
    Client recvContent preallocates uint64-sized slice
  4. Execution
    Go runtime attempts oversized allocation
  5. Impact
    Memory exhausted, client process terminates

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
Exploitation Conditions

Exploitation requires the vulnerable amqp091-go client (prior to 1.13.0) to establish an AMQP 0.9.1 connection to a broker that is malicious or has been compromised (or to a broker connection an attacker can actively tamper with); the attacker-controlled broker must send a content header frame with an extreme declared body Size. The AT:P attack requirement means this is a broker-attacks-its-clients threat model, not exploitation by an arbitrary unauthenticated network attacker - the primary limiting factor is that the victim must be talking to an untrusted or subverted broker. No special client configuration is needed; the flaw affects default behavior because the preallocation was never capped to the negotiated Connection.Config.FrameSize (note: a FrameSize of 0 means unlimited, which removes the cap entirely even after the fix).

Impact

This is a client-side denial-of-service in the official RabbitMQ Go AMQP 0.9.1 client library, not a server-side or arbitrary-code flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H = 8.9 High) correctly captures that the only impact is availability (VC:N/VI:N) via memory exhaustion, and importantly includes AT:P - an attack requirement - reflecting that exploitation depends on the client connecting to a malicious or compromised broker rather than any arbitrary internet attacker. The 8.9 score appears inflated: SA:H (subsequent-system availability) double-counts what is really a single-process crash of the vulnerable client itself, and the AT:P broker-trust precondition materially limits real-world reach, since a broker that is already malicious/compromised can typically disrupt or lie to its clients through many other means. There is no CISA KEV listing, no public exploit code identified, and no EPSS score in the provided data, so there is no evidence of exploitation - this is a code-quality/robustness fix, not an urgent externally-driven threat. The provided vector is CVSS 4.0 only; no CVSS 3.1 vector was supplied. Realistic priority is moderate-to-low: patch as part of normal dependency hygiene, prioritizing services that connect to brokers outside your trust boundary (multi-tenant, third-party, or internet-exposed brokers).

Exploit ScenarioDerived

An attacker who controls or has compromised an AMQP broker (or performs an active man-in-the-middle on an unauthenticated/untrusted broker connection) sends a content header frame declaring an extreme uint64 body size. The amqp091-go client (<1.13.0) calls recvContent and preallocates a byte slice of that declared size before any body data arrives, forcing the Go runtime into a huge allocation that exhausts memory and terminates the client process. No public exploit code is identified, and exploitation requires the victim to be connected to an attacker-influenced broker (AT:P).

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 16, 2026

Memory-exhaustion denial of service in the official RabbitMQ Go AMQP 0.9.1 client library (amqp091-go) prior to 1.13.0 lets a malicious or compromised broker kill client processes: when a content header frame arrives, the client preallocates the message body buffer using the broker-declared 64-bit body size without capping that hint to the negotiated Connection.Config.FrameSize, so an extreme declared size drives a correspondingly huge Go heap allocation before any body bytes are received, exhausting memory and terminating the process. The exploitation model is broker-attacks-its-clients rather than exploitation by an arbitrary network attacker (CVSS 4.0 8.9 with AT:P, and the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning the victim application must connect to a broker that is hostile, subverted, or on a path an attacker can tamper with; no client credentials or unusual configuration are needed, and a FrameSize of 0 ("unlimited") removes the cap entirely even after patching. There is no CISA KEV entry and no public exploit identified at time of analysis, but the upstream fix commit, test case, and 1.13.0 release are all public.

RemediationAI

Upgrade the dependency to the vendor-released patched version, amqp091-go 1.13.0 (or later), which caps the body preallocation at the negotiated Connection.Config.FrameSize; see the release at https://github.com/rabbitmq/amqp091-go/releases/tag/v1.13.0, the advisory at https://github.com/rabbitmq/amqp091-go/security/advisories/GHSA-r9c8-gcjp-xfwh, and the fix in https://github.com/rabbitmq/amqp091-go/pull/346 (commit 91b65fa0096a99a580cf51a31b24028ff1c60382) - no patched version other than 1.13.0 should be assumed to contain the fix. Because the vulnerable code path allocates before any body data arrives, there is no pre-patch code-level workaround that fully prevents the allocation; the practical mitigations are boundary controls: connect only to brokers you trust and authenticate, and where the broker is remote, enforce mutual TLS with certificate validation/pinning so a man-in-the-middle cannot impersonate the broker (trade-off: added certificate lifecycle management, and it does not protect against a genuinely compromised broker); restrict client egress to the known broker host and port to shrink the set of reachable hostile endpoints; and if you cannot patch immediately, explicitly set Config.FrameSize to a small non-zero value that matches your broker's actual frame limits, since after the fix the cap derives from FrameSize and a FrameSize of 0 means "unlimited" and disables the cap entirely (trade-off: a value smaller than the broker's negotiated frame size can break large-message handling, and this only helps once the code is patched). Run clients under a memory cgroup/container limit so an oversized allocation triggers an OOM kill of the container or process instead of degrading the whole host (trade-off: availability loss is contained but the client still dies and must restart). Monitor for repeated client OOM kills or abrupt disconnects as a signal of a hostile broker, and treat any broker whose content headers declare implausibly large body sizes as compromised.

Affected VersionsENISA

amqp091-go < 1.13.0

Affected Packages

go github.com/rabbitmq/amqp091-go fix: 1.13.0
euvd amqp091_go fix: 1.13.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is a CWE-789 (memory allocation with excessive size value) issue in the AMQP 0.9.1 client protocol implementation. An AMQP 0.9.1 message transfer is split into a method frame (Basic.Deliver/Basic.GetOk), a content header frame whose Body Size field is a 64-bit unsigned integer describing the total body length, and one or more body frames. In channel.go, Channel.recvContent handles the header by doing ch.body = make([]byte, 0, ch.header.Size), using the peer-supplied size directly as the slice capacity hint; the Go runtime therefore commits or attempts to reserve that much address space/backing store immediately, long before the body frames corroborate the declared length. Because the value is fully broker-controlled and uncorrelated with the connection's negotiated maximum frame payload (default 131072 bytes, i.e. 128 KiB, per Config.FrameSize), a single crafted header can demand gigabytes. The upstream fix in PR 346 (commit 91b65fa0096a99a580cf51a31b24028ff1c60382) clamps the hint: it copies ch.header.Size into a local, and if FrameSize is greater than zero and the declared size exceeds it, the preallocation is reduced to FrameSize - preserving the optimization for normal-sized messages while bounding the worst-case allocation. The accompanying unit test TestRecvContentBodyPreallocationIsCappedToFrameSize verifies that a 1 MiB declared body on a 128 KiB connection caps at 131072, that equal/smaller declared sizes are used verbatim, and that FrameSize == 0 (documented as unlimited) falls back to the declared header size, meaning the mitigating cap does not apply to connections configured with FrameSize 0.

Know when Rabbitmq gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 8.9 HIGH
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
vuln.today AI 5.9 MEDIUM

AC:H because exploitation requires the client to be connected to a malicious/compromised broker (a trust precondition, mapping the 4.0 AT:P); impact is client-process crash only, so C:N/I:N/A:H.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE 5.9 MEDIUM
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Red Hat 7.5 HIGH

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
None
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
High

Lifecycle Timeline

2
Patch available
Sep 16, 2026 - 16:04 EUVD
CVE Published
Sep 16, 2026 - 14:39 cve.org
HIGH 8.9

DescriptionCVE.org

RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.recvContent in channel.go preallocates the message body slice with the uint64 ch.header.Size value supplied by an AMQP content header without capping the allocation to the negotiated Connection.Config.FrameSize value. A malicious or compromised broker can send an extreme declared body size and cause the Go runtime to attempt a correspondingly large allocation before body data is received. The allocation can exhaust memory and terminate the client process. This issue is fixed in version 1.13.0.

Technical POC Analysis

CWE-789: Memory Allocation with Excessive Size Value.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

The official RabbitMQ Go client library (amqp091-go, versions prior to 1.13.0) can be driven to exhaust memory and terminate by a broker that is hostile, compromised, or reachable by a tampering attacker, so any Go service, worker, or microservice built on this library inherits the risk of an abrupt outage. No client credentials or unusual configuration are required - in fact a FrameSize setting of 0 removes the safeguard entirely - which means the exposure is concentrated in organizations whose applications connect to brokers outside their direct control or across paths an attacker could intercept. Leadership should treat this as an availability risk to dependent services rather than a data-breach risk, since there is no reported confidentiality or integrity impact and the attack requires an adversarial or subverted broker.

Business Impact: Medium
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: set Connection.Config.FrameSize to a bounded non-zero value (never 0, which removes the cap), avoid connecting clients to untrusted or third-party-controlled brokers, enforce TLS (amqps) with certificate validation and certificate pinning for all broker connections to block on-path tampering, segment and firewall client egress to approved broker endpoints only, and apply container or process-level memory limits with automatic restart and alerting so a memory-exhaustion kill is contained and visible; plan to upgrade to 1.13.0 or later once that release is verified as the fixed version.

Threat Intelligence Overview

EPSS Score
0.4%
Top 65% exploitable
Prevalence
Medium
official RabbitMQ Go client, common in Go microservices but scoped to RabbitMQ users
Threat Intel
1
1 sources
Data Quality
7 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
Medium
Technical Impact
Partial

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0
CVE-2026-57219 HIGH POC
8.7 Jul 10

Sensitive credential disclosure in RabbitMQ affects installations running the management plugin with OAuth 2 configured

CVE-2019-11287 HIGH POC
7.5 Nov 23

Pivotal RabbitMQ, versions 3.7.x prior to 3.7.21 and 3.8.x prior to 3.8.1, and RabbitMQ for Pivotal Platform, 1.16.x ver

CVE-2026-63335 MEDIUM POC
6.3 Aug 18

Denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.30.0) allows a malicious or compromi

CVE-2016-9877 CRITICAL
9.8 Dec 29

An issue was discovered in Pivotal RabbitMQ 3.x before 3.5.8 and 3.6.x before 3.6.6 and RabbitMQ for PCF 1.5.x before 1.

CVE-2026-77411 CRITICAL
9.5 Sep 16

Parsing desynchronization in the RabbitMQ amqp091-go AMQP 0.9.1 client library before 1.13.0 lets a malicious or comprom

CVE-2026-77405 CRITICAL
9.4 Sep 16

RabbitMQ's amqp091-go Go client library, in all versions before 1.13.0, builds TLS configuration from amqps:// URIs with

CVE-2021-32718 MEDIUM POC
5.4 Jun 28

RabbitMQ is a multi-protocol messaging broker. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploita

CVE-2026-67404 CRITICAL
9.2 Sep 23

RabbitMQ brokers that use the OAuth2 plugin can silently fall back to disabled TLS certificate verification when no CA b

CVE-2026-77408 CRITICAL
9.1 Sep 16

Silent AMQP 0.9.1 metadata corruption in the RabbitMQ amqp091-go Go client library prior to 1.13.0 lets an application t

CVE-2026-67231 CRITICAL
9.1 Sep 23

TLS client-authentication bypass in the RabbitMQ trust-store plugin lets a remote unauthenticated attacker whose forged

CVE-2026-63336 MEDIUM POC
5.1 Aug 18

TLS certificate validation is completely bypassed in the RabbitMQ Java client library (`com.rabbitmq:amqp-client`) prior

CVE-2026-77412 HIGH
8.9 Sep 16

Denial of service in the official RabbitMQ Go client library amqp091-go (versions prior to 1.13.0): a malicious, comprom

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Module for SAP Applications 15 SP7 Affected
SUSE Linux Enterprise Server for SAP Applications 15 SP7 Affected
SUSE Linux Enterprise Server for SAP applications 16.0 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
openSUSE Leap 16.0 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy