EUVD-2026-43019Severity by source
Sources disagree (Medium–Critical)AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
AC:H because exploitation needs a non-default PROXY-protocol path plus loopback-bound listener; PR:N since the default guest/guest account is effectively unauthenticated; full broker access gives C/I/A:H, scope unchanged.
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Lifecycle Timeline
8DescriptionNVD
RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
AnalysisAI
Authentication bypass in RabbitMQ (broker versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6) lets a loopback-restricted account such as the default guest user authenticate from a remote network when the broker sits behind a trusted PROXY-protocol path and the backend listener is loopback-bound. Because the loopback check evaluates the listener-side socket address (which appears as 127.0.0.1 to the local proxy) instead of the real client source carried in the PROXY header, the 'local only' restriction on guest is silently defeated across AMQP 0-9-1, AMQP 1.0, and the Stream Protocol. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires a specific deployment: the broker must accept traffic through a trusted PROXY-protocol path (proxy_protocol = true) AND the backend AMQP 0-9-1 / AMQP 1.0 / Stream listener must be loopback-bound, so the listener-side socket address reads as 127.0.0.1. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The signals conflict and must be weighed carefully. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A RabbitMQ cluster runs behind an HAProxy/Envoy load balancer that speaks PROXY protocol to broker listeners bound to 127.0.0.1, with the default guest account still present. A remote attacker on the network connects through the load balancer to the AMQP or Stream port and authenticates as guest/guest; the broker reads the proxy's loopback socket address, treats the session as local, and grants access. … |
| Remediation | Vendor-released patch: upgrade to RabbitMQ 3.13.15, 4.0.20, 4.1.11, or 4.2.6 (or later) as appropriate for your branch, per advisory GHSA-36m6-588r-vqcw and PRs #15936/#15940 (commits 7273c9e and 9f8c39f). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all RabbitMQ deployments and confirm versions in use, paying particular attention to instances deployed behind load balancers or proxy infrastructure. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
More in Rabbitmq Server
View allPivotal 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
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.
RabbitMQ is a messaging and streaming broker. In versions 3.13.7 and prior, RabbitMQ is logging authorization headers in
Sensitive credential disclosure in RabbitMQ affects installations running the management plugin with OAuth 2 configured
An issue was discovered in these Pivotal RabbitMQ versions: all 3.4.x versions, all 3.5.x versions, and 3.6.x versions p
RabbitMQ installers on Windows prior to version 3.8.16 do not harden plugin directory permissions, potentially allowing
Memory-exhaustion denial of service in RabbitMQ server prior to 4.2.6 allows an unauthenticated remote client to crash o
Stored cross-site scripting in the RabbitMQ management UI (versions prior to 4.2.5) lets a user holding queue/exchange d
Uncontrolled resource consumption in the RabbitMQ Management plugin's HTTP API lets an authenticated client crash or deg
Authorization bypass in RabbitMQ topic permissions lets an authenticated user with restricted topic rights publish to or
Improper authorization in RabbitMQ broker (versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6) allows an authenticated
Server-side request forgery and NTLM credential exposure in the RabbitMQ management plugin (versions 4.1.0 to before 4.1
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today