EUVD-2026-85632Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain monitoring-tagged account
-
DeliveryReach Management API over network
-
ExploitSend DELETE /api/auth/attempts/:node
-
ExecutionReset per-node auth-attempt counters
-
ImpactErase brute-force evidence
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the RabbitMQ Management plugin to be enabled and the attacker to hold a valid account carrying the 'monitoring' tag; with those in place the actor issues DELETE /api/auth/attempts/:node to reset that node's authentication-attempt counters. Limiting factors: it is authenticated (PR:L, monitoring-tagged user, not anonymous), the impact is confined to in-memory counters (no actual log or audit-record erasure), and the analogous reset via wm_reset already correctly requires administrator - so a hardened deployment that does not grant monitoring tags to untrusted users is not meaningfully exposed. |
| Impact | This is a genuinely low-priority issue whose signals are internally consistent - the low real risk is not a false-negative. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N) yields only 2.3, and every impact metric except Integrity is None, matching the description's own framing that the impact is 'cosmetic (counters only, no log erasure).' The requirement of a valid monitoring-tagged account (PR:L) plus the Management plugin being enabled bounds the attacker population to already-provisioned internal users. No EPSS score, no CISA KEV listing, and no POC are provided, so exploitation status is 'no public exploit identified at time of analysis'; nothing here conflicts. The single caveat worth flagging is the CWE and tagging: the description and CWE-862 (missing authorization) describe an authorization inconsistency - the DELETE handler reuses is_authorized_monitor while the analogous rabbit_mgmt_wm_reset.erl endpoint requires admin - not an 'Authentication Bypass' as the input tag claims. Bottom line: real but marginal, a forensic/evidence-tampering hardening fix rather than an exploitable path to compromise; patch during normal maintenance, not as an emergency. |
| Exploit ScenarioDerived | An insider or a compromised low-privilege account holding only the RabbitMQ 'monitoring' tag sends DELETE /api/auth/attempts/:node against a node's management API, resetting rabbit_core_metrics authentication-attempt counters. This lets an attacker who has been (or is) brute-forcing credentials wipe the per-node counter evidence of that activity, hindering detection. No public POC is identified, and actual logs are not erased - only the in-memory counters. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 23, 2026
Authenticated RabbitMQ users that hold the 'monitoring' tag can erase a node's authentication-attempt counters by sending DELETE /api/auth/attempts/:node through the Management plugin HTTP API, removing a signal that operators would use to notice brute-force activity. Only deployments running RabbitMQ prior to 4.1.13, 4.2.7 or 4.3.0 with the Management plugin enabled and monitoring credentials issued to a non-administrative or untrusted account are exposed, and exploitation requires the attacker to already possess that valid account. The impact is limited to in-memory metrics (no log or audit-record deletion) and no public exploit code has been identified at time of analysis; EPSS data was not supplied and the issue is not in CISA KEV, consistent with its very low assessed severity.
RemediationAI
Vendor-released patch: upgrade to RabbitMQ 4.1.13, 4.2.7, or 4.3.0 (or a later maintenance release in the respective series), which removes the missing-admin check on DELETE /api/auth/attempts/:node; consult GHSA-fhwq-9rvh-prj2 and the release notes at https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.7 and https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.0 before upgrading, and note that 4.2.x nodes will fail to start on Erlang releases below the supported minimum. Where immediate upgrade is not possible, the practical compensating control is authorization hygiene: audit accounts carrying the 'monitoring' tag and remove it from any principal that is not fully trusted, on the basis that a deployment without monitoring-tagged untrusted users is not meaningfully exposed; the trade-off is that legitimate monitoring and dashboards relying on that tag will lose Management API visibility. Because the deleted data is only in-memory counters, forward authentication-failure telemetry to an external sink (log shipper, SIEM) so brute-force evidence survives a counter reset, and alert on DELETE requests to /api/auth/attempts/:node from any non-administrator, accepting that this detects rather than prevents the reset. Restricting the Management plugin's network reachability to trusted administrative networks reduces the attack surface but does not address a malicious insider who already holds a monitoring account.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages 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 is a missing-authorization case (CWE-862) in the RabbitMQ Management plugin's HTTP API authorization layer. The endpoint handler for DELETE /api/auth/attempts/:node performs its access check through is_authorized/2, which routes all HTTP methods to is_authorized_monitor; the DELETE branch consequently accepts any principal carrying the 'monitoring' tag instead of requiring administrator rights. That DELETE path calls rabbit_core_metrics:reset_auth_attempt_metrics(), zeroing per-node authentication-attempt counters. The sibling reset endpoint implemented in rabbit_mgmt_wm_reset.erl guards the analogous operation with an administrator check, so the discrepancy is an inconsistency between two handlers rather than a design-wide weakness. The affected component is the management/HTTP-API surface of cpe:2.3:a:rabbitmq:rabbitmq-server, and the weakness is confined to metrics state, explaining the integrity-only (VI:L) scoring in both the CVSS 4.0 vector (2.3, AT:P) and the independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N).
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:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Network-reachable Management API with a monitoring-tagged account (PR:L, AC:L); only low integrity impact from resetting counters, no confidentiality or availability effect.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
RabbitMQ is a messaging and streaming broker. Prior to versions 4.1.13, 4.2.7, and 4.3.0, is_authorized/2 uses is_authorized_monitor for all methods. DELETE resets rabbit_core_metrics:reset_auth_attempt_metrics(). Impact is cosmetic (counters only, no log erasure), but inconsistent with rabbit_mgmt_wm_reset.erl which requires admin for the analogous operation. A monitoring-tagged user can reset the per-node authentication-attempt counters via DELETE /api/auth/attempts/:node, erasing evidence of brute-force activity. The sibling endpoint wm_reset requires administrator. Preconditions include Management plugin enabled monitoring tag. This issue is fixed in versions 4.1.13, 4.2.7, and 4.3.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
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
Exploit-DB