RabbitMQ Server EUVD-2026-85652

Requires an authenticated AMQP 0-9-1 client account that holds publish permission on the target broker (PR:L); no user interaction, no non-default configuration, and no special plugin is needed since AMQP 0-9-1 is the default and most widely used protocol. The attack works against default configurations because the content-header BodySize (uint64) is stored without validation and the max_message_size check runs only at assembly completion, which the attacker prevents by never completing assembly. Limiting factors: valid publish credentials are mandatory (not exploitable pre-auth), and the impact is confined to denial of service - the memory alarm offers partial, reactive mitigation but does not prevent the condition. Affects RabbitMQ prior to 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VA:H only) accurately frames this as a network-reachable, low-complexity, no-user-interaction availability attack requiring only low privilege - a single authenticated AMQP 0-9-1 client with publish permission. Impact is purely availability (VC:N/VI:N/VA:H); there is no confidentiality or integrity exposure. No EPSS score, no CISA KEV listing, and no public exploit are present in the supplied data, so this is 'no public exploit identified at time of analysis' rather than active exploitation. The realistic risk is moderate-to-notable: the flaw is trivially triggerable by any legitimate publisher (a very low bar in multi-tenant brokers) and the impact is cluster-wide - one reader process accumulating unbounded memory degrades all publishers or OOMs the node, and the vendor explicitly notes the memory alarm is only reactive/partial mitigation. The gating factor keeping this out of 'critical' territory is that it requires valid publish credentials (PR:L) and yields DoS only, not code execution or data disclosure. No signals conflict; the 7.1 score is consistent with an authenticated, high-availability-impact DoS.

An attacker holding any valid AMQP 0-9-1 account with publish permission on a RabbitMQ node declares a message content-header with body_size = 2^63-1 and then streams body fragments indefinitely. Because check_msg_size only fires when frame assembly completes, the size limit is never enforced, so the reader process accumulates memory without bound until the memory alarm degrades all cluster publishers or the node exhausts RAM and crashes. No public proof-of-concept is referenced in the available data.