RabbitMQ EUVD-2026-101296

Exploitation requires a completed SASL authentication as a low-privilege client (PR:L); the pre-authentication max_heap_size guard in rabbit_amqp_reader.erl is cleared only after login, so the attack is impossible before valid credentials are presented. The broker must be serving AMQP 1.0 clients, and the attacker must be able to craft frames containing AMQP 1.0 arrays whose shared constructor is a zero-width type (null, boolean, uint0, ulong0, list0) with large declared element counts. No non-default configuration is needed - default authenticated AMQP 1.0 access is sufficient. The principal limiting factor is the credential requirement; reliability also depends on sending repeated or concurrent frames to drive the reader heap past the node-wide memory alarm threshold, so a single frame may not suffice.

This is a genuine but bounded availability risk - an authenticated denial-of-service, not a critical RCE. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) and impact of VA:H with VC:N/VI:N agree with the description: a network-reachable, low-complexity attack that requires a valid (low-privilege) account and yields availability-only impact. The AT:P ('attack requirements present') and the description's wording ('repeated or concurrent frames') both indicate the node-wide memory alarm is reached through sustained/amplified sending rather than a single guaranteed-fatal packet, which modestly tempers reliability. No EPSS score was provided, the CVE is NOT in CISA KEV, and no public exploit code is referenced - the only GitHub links are the fix commit, the v4.3.4 release, and the GHSA advisory, which are patch artifacts, not a POC. The key risk gate is authentication: the pre-authentication max_heap_size guard blocks this before login, so an attacker needs working SASL credentials, meaning realistic risk is highest in multi-tenant brokers, environments with weak/shared/default credentials, or where any authenticated client can be compromised. Net: a real patch-worthy issue for exposed or multi-tenant RabbitMQ, but it is a medium-severity authenticated DoS, not a top-priority emergency - treat it as high priority only where untrusted parties hold broker credentials.

An attacker who has obtained any valid low-privilege RabbitMQ account completes SASL authentication, then sends ordinary AMQP 1.0 frames packed with many arrays whose shared constructor is a zero-width type (e.g. null, boolean, uint0), each declaring a huge element count that costs only a few bytes on the wire. The parser materializes every element into the reader-process heap before authorization checks, so a few small frames balloon into gigabytes of memory, triggering the node-wide memory alarm that blocks all publishers. No public exploit code is referenced, but the fix commit and test cases make the technique straightforward to reproduce.