The flaw occurs in client authentication when NATS Server uses the verify_and_map method to map a client’s identity from their certificate’s Subject Distinguished Name (DN). The logic that validates the DN does not correctly enforce certain relative DN (RDN) patterns, allowing a certificate that nominally conforms to the trusted CA requirements but contains an unexpected RDN arrangement to be accepted. An attacker who can obtain a certificate issued by a trusted CA and craft the DN to exploit the pattern regression can trick the server into creating a NATS identity that matches a legitimate user, thereby bypassing authentication and gaining ownership of that identity’s messaging permissions. Although the vulnerability requires a valid CA‑issued certificate and a highly unlikely DN pattern, the impact for affected deployments is that an unauthorized party could impersonate any user whose identity is derivable from the client’s DN. This could compromise confidentiality, integrity, and availability of the messaging system, especially in sensitive or multi‑tenant environments. The CVE notes that the vulnerability is unlikely in practice but acknowledges that very sophisticated DN construction could expose an environment to exploitation.

The vulnerability affects NATS.io NATS Server versions older than 2.11.15 and 2.12.6. All builds of the server that use the verify_and_map authentication method for mTLS client certificates are susceptible unless upgraded to one of the patched releases.

The CVSS score of 4.2 indicates moderate severity. The EPSS probability is listed as less than 1 % and the issue is not currently in the CISA KEV catalog, suggesting a low likelihood of already exposed exploitation. However, the attack path requires a properly issued client certificate from a trusted CA and carefully constructed DN fields that match the server’s (now flawed) validation logic. Attackers would need to maintain a valid certificate authority or compromise one, and craft the subject DN to mimic an existing user’s pattern. While the vector is remote—any external client that can establish an mTLS session—it is contingent on existing trust relationships.