NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

CVE-2026-77410 — amqp091-go

Fix: rabbitmq/amqp091-go@91b65fa

CVE-2026-77410 is a CWE-789 vulnerability in github.com/rabbitmq/amqp091-go. A fix is available for github.com/rabbitmq/amqp091-go — see the affected versions and patch details below.

RabbitMQ amqp091-go: Resource Exhaustion (OOM) via Unbounded Body Buffer Allocation

Also known asGHSA-r9c8-gcjp-xfwhGO-2026-6500
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-77410.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs44th percentile — riskier than 44% of all scored CVEsHighest risk
0.02%0.36%0.69%1.02%0.5%0.5%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹github.com/rabbitmq/amqp091-go

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary A flaw in the recvContent function allows a malicious AMQP server to trigger an Out-of-Memory (OOM) error, forcing the host operating system or container runtime to immediately terminate the client process.

Vulnerability Details When receiving message content payloads, the client processes the expected size from the content header framework. The recvContent function attempts to optimize performance by pre-allocating memory for the message body based on the ch.header.Size field, which is a 64-bit unsigned integer (uint64).

// channel.go:495-496
if cap(ch.body) == 0 {
    ch.body = make([]byte, 0, ch.header.Size)  // unbounded
}

The underlying library fails to validate or cap this requested size against any upper boundary—such as the maximum frame size negotiated during connection establishment (FrameMax). If a server specifies an extreme body size (e.g., 2^62 bytes), the Go runtime attempts to allocate an exabyte-scale slice capacity. This immediately exhausts available system memory, causing the operating system's OOM killer to terminate the application.

Attack Vector / Exploitation Scenario

  • Message Delivery Phase: A malicious or compromised AMQP broker sends a standard basic.deliver frame containing a content header with an intentionally inflated body-size variable.
  • Authentication Requirement: No special privileges or authentication bypasses are required; the crash occurs seamlessly during normal message consumption.

Impact

  • Availability: High. Exploded memory consumption results in an instant process termination, destroying application state and availability for all threads sharing the environment.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/rabbitmq/amqp091-goall versions1.13.0go get github.com/rabbitmq/amqp091-go@v1.13.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rabbitmq/amqp091-go, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/rabbitmq/amqp091-go to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-77410 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This vulnerability is rated as having an Important severity for Red Hat products because an untrusted or rogue messaging broker can remotely force client services into an out-of-memory crash, resulting in a denial of service without requiring client-side privileges. In typical Red Hat deployments, AMQP clients connect…

ProductFixed inAdvisory
Red Hat Hardened Imagesopentelemetry-collector-contrib-main-0.161.0-0.1.hum1RHSA-2026:68290
Red Hat Quay 3.10quay/quay-rhel8:1791462428RHSA-2026:79366
Red Hat Quay 3.12quay/quay-rhel8:1791314514RHSA-2026:79546
Red Hat Quay 3.9quay/quay-rhel8:1790808443RHSA-2026:77656

Frequently Asked Questions

**Summary** A flaw in the `recvContent` function allows a malicious AMQP server to trigger an Out-of-Memory (OOM) error, forcing the host operating system or container runtime to immediately terminate the client process. **Vulnerability Details** When receiving message content payloads, the client processes the expected size from the content header framework. The `recvContent` function attempts to optimize performance by pre-allocating memory for the message body based on the `ch.header.Size` field, which is a 64-bit unsigned integer (`uint64`). ```go // channel.go:495-496 if cap(ch.body) ==
O3 Security · Impact-Aware SCA

Is CVE-2026-77410 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-77410: amqp091-go — Fixed in 1.13.0