GHSA-3F24-PCVM-5JQC

Vulnerability from github – Published: 2026-03-24 21:51 – Updated: 2026-03-24 21:51
VLAI?
Summary
NATS has mTLS verify_and_map authentication bypass via incorrect Subject DN matching
Details

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

One authentication model supported is mTLS, deriving the NATS client identity from properties of the TLS Client Certificate.

Problem Description

When using mTLS for client identity, with verify_and_map to derive a NATS identity from the client certificate's Subject DN, certain patterns of RDN would not be correctly enforced, allowing for authentication bypass.

This does require a valid certificate from a CA already trusted for client certificates, and DN naming patterns which the NATS maintainers consider highly unlikely.

So this is an unlikely attack. Nonetheless, administrators who have been very sophisticated in their DN construction patterns might conceivably be impacted.

Affected Versions

Fixed in nats-server 2.12.6 & 2.11.15

Workarounds

Developers should review their CA issuing practices.

Severity ?
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0-RC.1"
            },
            {
              "fixed": "2.12.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T21:51:08Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nOne authentication model supported is mTLS, deriving the NATS client identity from properties of the TLS Client Certificate.\n\n### Problem Description\n\nWhen using mTLS for client identity, with `verify_and_map` to derive a NATS identity from the client certificate\u0027s Subject DN, certain patterns of RDN would not be correctly enforced, allowing for authentication bypass.\n\nThis does require a valid certificate from a CA already trusted for client certificates, and `DN` naming patterns which the NATS maintainers consider highly unlikely.\n\nSo this is an unlikely attack. Nonetheless, administrators who have been very sophisticated in their `DN` construction patterns might conceivably be impacted.\n\n### Affected Versions\n\nFixed in nats-server 2.12.6 \u0026 2.11.15\n\n### Workarounds\n\nDevelopers should review their CA issuing practices.",
  "id": "GHSA-3f24-pcvm-5jqc",
  "modified": "2026-03-24T21:51:08Z",
  "published": "2026-03-24T21:51:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-3f24-pcvm-5jqc"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/secnote-2026-13.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NATS has mTLS verify_and_map authentication bypass via incorrect Subject DN matching"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.