Homepage

Incorrect Privilege Assignment The advisory has been revoked - it doesn't affect any version of package rabbitmq-server  (opens in a new tab)

Threat Intelligence

EPSS
0.23% (14th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-RABBITMQSERVER-20148583
  • published26 Sept 2026
  • disclosed25 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 25 Sep 2026

NewCVE-2026-67420  (opens in a new tab)
CWE-266  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:10.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rabbitmq-server package and not the rabbitmq-server package as distributed by RHEL.

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ OAuth credential refresh retains revoked runtime tags. when an existing AMQP connection refreshes from an OAuth token that grants the impersonator tag to a valid same-username token that no longer grants that tag, RabbitMQ updates the OAuth backend implementation (token/scopes/expiry) but leaves the connection's runtime #user.tags unchanged. rabbitaccesscontrol:checkuserid/2 then still honors the stale impersonator tag, so the connection (including newly opened channels) can continue publishing messages with a foreign AMQP userid after that privilege should have been revoked. A fresh connection using the downgraded token correctly refuses the same publish, proving the defect is stale session state rather than the token Limited to connections that once held impersonator and successfully refresh to a downgraded same-username rabbitauthbackendoauth2 (or an equivalent refresh-capable backend that returns tags) is enabled for This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.