RabbitMQ EUVD-2026-85660

Requires an authenticated account holding the management tag (PR:L) - the use_regex=true option on management list endpoints (e.g. list queues/exchanges) is a supported feature reachable through normal API use, so no non-default configuration is needed. Impact scales with the size of the result set: the description's worked example assumes roughly 5000 resources, so a broker with many queues/exchanges is required for a single request to consume 12+ minutes of CPU (this is the AT:P attack requirement). On a sparsely populated broker the per-request cost is far lower. No user interaction and no confidentiality/integrity exposure; the limiting factors are the management-tag requirement and a resource-rich deployment.

This is a genuine but bounded availability risk, not a headline-grade critical. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) with VA:H and a 6.0 (MEDIUM) score aligns with the CWE-1333 inefficient-regex-complexity mechanism: a management-tagged (low-privilege but authenticated, PR:L) user can force the broker to run an unbounded-runtime regular expression once per resource on list endpoints via use_regex=true, consuming 12+ minutes of scheduler CPU per request and saturating schedulers with parallel requests. Confidentiality and integrity are untouched (VC:N/VI:N) - pure DoS. No EPSS score, no CISA KEV listing, and no public PoC are present in the data, so there is no signal of active or imminent exploitation; risk is a self-service DoS by any account already trusted with the management tag rather than a wormable pre-auth threat. The vendor's AT:P (attack-requirement present) reflects the need for a populated broker (the example cites 5000 queues) - on a broker with few resources the CPU cost per request drops and impact is limited, which is a meaningful real-world mitigant. Signals are internally consistent; no conflicts to flag. Priority: patch on a normal maintenance cadence, higher if untrusted parties hold management-tag accounts.

A user holding only the management tag issues a normal list-resources API call (e.g. list queues) with use_regex=true and a name filter regex against a broker holding thousands of queues; the regex executes once per queue with no match_limit tuning, burning many minutes of CPU on a single request. Firing several such requests concurrently saturates all Erlang schedulers and denies service to legitimate AMQP/management traffic. No public PoC is identified in the provided data.