Skip to content
Heist/ feed
Back to feed
MediumFix available

RabbitMQ OAuth credential refresh retains revoked runtime tags

Type: advisorySources: OSV

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.

Products
rabbitmq
Affected versions
Not specified
Fixed versions
3.13.19, 4.0.24, 4.1.15, 4.2.10, 4.3.5
CVEs
CVE-2026-67420
Confirmed fixed CVEs
Not specified
Updated in this feed
30 Oct 2026, 23:59 UTC · Revision 1

Source evidence

RabbitMQ OAuth credential refresh retains revoked runtime tags

core-osv · Original source

Published 1 Oct 2026, 09:33 UTC

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.

osv:BIT-rabbitmq-2026-67420

rabbitmq

Fixed versions: 3.13.19, 4.0.24, 4.1.15, 4.2.10, 4.3.5

Complete source record
{
  "id": "a900c8539de548f46283ac65f0cdbd51a50a41e2b5ff87dbb4ce4ac4e9efa8a6",
  "url": "https://osv.dev/vulnerability/BIT-rabbitmq-2026-67420",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "RabbitMQ OAuth credential refresh retains revoked runtime tags",
    "summary": "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.",
    "evidence": "osv:BIT-rabbitmq-2026-67420",
    "products": [
      {
        "name": {
          "value": "rabbitmq",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "3.13.19",
            "evidence": "/affected/0/ranges"
          },
          {
            "value": "4.0.24",
            "evidence": "/affected/0/ranges"
          },
          {
            "value": "4.1.15",
            "evidence": "/affected/0/ranges"
          },
          {
            "value": "4.2.10",
            "evidence": "/affected/0/ranges"
          },
          {
            "value": "4.3.5",
            "evidence": "/affected/0/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "medium",
    "structured": {
      "id": "BIT-rabbitmq-2026-67420",
      "aliases": [
        "BIT-rabbitmq-2026-67420",
        "CVE-2026-67420",
        "GHSA-86fm-44m9-rqjx"
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "SEMVER",
              "events": [
                {
                  "introduced": "3.13.0"
                },
                {
                  "fixed": "3.13.19"
                },
                {
                  "introduced": "4.0.0"
                },
                {
                  "fixed": "4.0.24"
                },
                {
                  "introduced": "4.1.0"
                },
                {
                  "fixed": "4.1.15"
                },
                {
                  "introduced": "4.2.0"
                },
                {
                  "fixed": "4.2.10"
                },
                {
                  "introduced": "4.3.0"
                },
                {
                  "fixed": "4.3.5"
                }
              ]
            }
          ],
          "package": {
            "name": "rabbitmq",
            "purl": "pkg:bitnami/rabbitmq",
            "ecosystem": "Bitnami"
          },
          "severity": [
            {
              "type": "CVSS_V3",
              "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N"
            }
          ],
          "database_specific": {
            "source": "https://github.com/bitnami/vulndb/tree/main/data/rabbitmq/BIT-rabbitmq-2026-67420.json"
          }
        }
      ],
      "modified": "2026-10-17T09:15:02.418533948Z",
      "provider": "osv",
      "references": [
        "https://github.com/rabbitmq/rabbitmq-server/commit/5de287d213765ca592ff5848ad2f6b9b98ee6772",
        "https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.5",
        "https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-86fm-44m9-rqjx",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-67420"
      ],
      "provider_metadata": {
        "cpes": [
          "cpe:2.3:a:vmware:rabbitmq:*:*:*:*:*:*:*:*"
        ],
        "severity": "Medium"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-67420",
        "evidence": "/aliases"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/database_specific/severity"
  },
  "source_id": "core-osv",
  "document_id": 352245,
  "published_at": "2026-10-01T09:33:59.215+00:00"
}