Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as AMQP 1.0 publisher with write permission
-
DeliveryCraft unknown descriptor with registered body prefix
-
ExploitPublish misclassified body to target queue
-
ExecutionConsumer decodes stored entry on delivery
-
ImpactConsumer protocol process terminates, redelivery repeats failure
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Requires an authenticated AMQP 1.0 publisher holding write permission to a target queue on RabbitMQ 4.0.0 through the fixed releases, using the optimized server_mode AMQP 1.0 parser. Impact is realized only when messages are consumed by a strict AMQP 1.0 consumer (which terminates while decoding the stored entry) or routed through AMQP 0-9-1 / other cross-protocol conversion that performs full body decoding; acknowledgement-required delivery amplifies the effect by redelivering the poisoned message and causing repeated consumer failures. Limiting factors: exploitation needs valid credentials with write permission (not unauthenticated), affects only consumer protocol processes rather than the broker (which stays alive), and sequence/value classifications are normally transported as opaque payloads so the data-misclassification path is the primary DoS vector. |
| Impact | This is a moderate-risk denial-of-service issue, not a high-priority emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 with only a Low availability impact (VA:L) and no confidentiality or integrity impact, which aligns well with the description: an authenticated AMQP 1.0 publisher can crash consumer protocol processes, but the broker itself stays alive and no routing or authorization is bypassed. The PR:L metric confirms exploitation requires an authenticated publisher with write permission, substantially limiting the attacker population to parties who already have legitimate access. No CISA KEV listing and no public exploit were provided, so exploitation status is 'no public exploit identified at time of analysis'; the GitHub-provided source material is the vendor patch diff and regression tests, not weaponized exploit code. EPSS was not supplied. The one notable data conflict is the input Tag 'Authentication Bypass', which directly contradicts the description's explicit statement that the issue does NOT bypass authorization - this tag appears mislabeled and should be treated as a CWE-20 input-validation/DoS issue. Net: a real but bounded, authenticated-only availability bug that merits routine patching rather than emergency response. |
| Exploit ScenarioDerived | An attacker who already holds AMQP 1.0 publisher credentials with write permission to a target queue publishes a well-formed but unknown descriptor whose bytes begin with a registered body descriptor prefix (e.g. 'amqp:data:binary@'), which the optimized server_mode parser misclassifies as a standard body section. When a strict AMQP 1.0 consumer or a cross-protocol (AMQP 0-9-1) conversion path then decodes the stored entry, the consumer's protocol process terminates; with acknowledgement-required delivery the poisoned message is redelivered, causing repeated crashes. No public proof-of-concept was provided, though the vendor patch includes regression tests demonstrating the prefix collision. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Denial of service in RabbitMQ 4.x allows an authenticated AMQP 1.0 publisher holding write permission on a target queue to store a crafted message body that misclassifies under the broker's optimized server_mode AMQP 1.0 parser, causing downstream AMQP 1.0 consumers to terminate while decoding the entry; cross-protocol conversion paths (AMQP 0-9-1 and similar) that perform full body decoding can likewise terminate the consumer protocol process. The broker itself remains alive, routing and authorization are not bypassed, and the defect is confined to consumer-side protocol processes, but acknowledgement-required delivery can redeliver the poisoned message and produce repeated failures. Vendor-released patches ship in RabbitMQ 4.0.24, 4.1.15, 4.2.10, and 4.3.4; no public exploit code was identified at time of analysis and CISA KEV does not list this CVE.
RemediationAI
Apply the vendor-released patch by upgrading to RabbitMQ 4.0.24, 4.1.15, 4.2.10, or 4.3.4 (the 4.3.4 release tag is published at https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.4 and the advisory is at https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-p35w-6mx2-q4pc); these versions validate the encoded symbol length against the registered descriptor lengths of 16, 17, and 23 bytes. If immediate upgrade is not possible, the most effective compensating controls are to remove or tightly scope write permissions for untrusted AMQP 1.0 publishers on queues that feed conversion paths, since exploitation requires an authenticated publisher with write access - this reduces the attack surface but does not eliminate risk from legitimately credentialed users. Additionally, avoid or harden AMQP 1.0 to AMQP 0-9-1 cross-protocol bridging (shovels, federations, and protocol-conversion consumers) for untrusted publishers because that path performs full body decoding and is the primary denial-of-service vector; note that disabling such bridges breaks legitimate interoperability. Switching affected consumers from acknowledgement-required delivery to automatic acknowledgement would prevent repeated redelivery-driven failures at the cost of losing delivery guarantees and risking message loss, so it should be treated only as a short-term measure. Monitoring AMQP 1.0 consumer disconnects and protocol-process restarts for a single queue source can help detect an active attempt. The broker process itself stays alive and routing and authorization are not bypassed, so no broker restart or credential rotation is warranted by this issue alone.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the Erlang module deps/amqp10_common/src/amqp10_binary_parser.erl, which implements the optimized AMQP 1.0 binary parser used when RabbitMQ runs in server_mode. AMQP 1.0 encodes a described type as a 0x00 descriptor byte followed by either a small symbol (0xa3, one-byte length) or a large symbol (0xb3, four-byte length), then the symbol bytes and the described value. The server_mode matcher recognized the three registered body descriptors - amqp:data:binary (16 bytes), amqp:amqp-value:* (17 bytes), and amqp:amqp-sequence:list (23 bytes) - by literal textual prefix but used a wildcard (_S) for the encoded symbol length field instead of the exact length, i.e. it never validated that the declared symbol length equalled the matched literal. This is a classic CWE-20 improper input validation defect: a well-formed but non-registered descriptor such as "amqp:data:binary@" (length 17) or "amqp:amqp-value:*!" (length 18) still prefix-matches, so the parser classifies the entry as the corresponding standard body section (internal body tags 0x75 for data, 0x76 for sequence, 0x77 for value per the upstream test suite) even though the actual described value is of a different, unknown type. The patched code hardcodes 16, 17, and 23 in the sym8 and sym32 match clauses and adds regression tests for both the exact-length case and the prefix-collision case. The mismatch does not affect the broker's own routing or authorization logic, but it stores bytes whose declared semantics disagree with the stored section type, which strict AMQP 1.0 decoders and full-body-decoding conversion paths handle incorrectly.
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
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Network-reachable AMQP 1.0 with low complexity but requires an authenticated publisher with write permission (PR:L); only partial availability impact on consumer processes, no confidentiality or integrity loss.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, the optimized AMQP 1.0 server_mode parser in deps/amqp10_common/src/amqp10_binary_parser.erl matches the textual prefixes of symbolic data, sequence, and value body descriptors without verifying their encoded symbol lengths. An authenticated AMQP 1.0 publisher with write permission can submit a well-formed unknown descriptor that begins with a registered body descriptor, and RabbitMQ misclassifies and stores the bytes as a standard body section. Strict AMQP 1.0 consumers can terminate while decoding the stored entry. For bodies misclassified as data, AMQP 0-9-1 or other cross-protocol conversion performs full body decoding and can terminate the consumer protocol process, with acknowledgement-required delivery permitting repeated failures. Sequence and value classifications are normally transported as opaque encoded payloads on that conversion path. The broker remains alive, and the issue does not bypass routing or authorization. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Sensitive credential disclosure in RabbitMQ affects installations running the management plugin with OAuth 2 configured
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
Denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.30.0) allows a malicious or compromi
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.
Parsing desynchronization in the RabbitMQ amqp091-go AMQP 0.9.1 client library before 1.13.0 lets a malicious or comprom
RabbitMQ's amqp091-go Go client library, in all versions before 1.13.0, builds TLS configuration from amqps:// URIs with
RabbitMQ is a multi-protocol messaging broker. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploita
RabbitMQ brokers that use the OAuth2 plugin can silently fall back to disabled TLS certificate verification when no CA b
Silent AMQP 0.9.1 metadata corruption in the RabbitMQ amqp091-go Go client library prior to 1.13.0 lets an application t
TLS client-authentication bypass in the RabbitMQ trust-store plugin lets a remote unauthenticated attacker whose forged
TLS certificate validation is completely bypassed in the RabbitMQ Java client library (`com.rabbitmq:amqp-client`) prior
Denial of service in the official RabbitMQ Go client library amqp091-go (versions prior to 1.13.0): a malicious, comprom
EUVD-2026-101294
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB