Summary
NATS TLS certificate common name validation bypass
The NATS official Rust clients are vulnerable to MitM when using TLS.
A fix for the nats crate hasn't been released yet. Since the nats crate is going to be deprecated anyway, consider switching to async-nats >= 0.29 which already fixed this vulnerability.
The common name of the server's TLS certificate is validated against the hostname provided by the server's plaintext INFO message during the initial connection setup phase. A MitM proxy can tamper with the host field's value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it.
Reproduction steps
- The NATS Rust client tries to establish a new connection
- The connection is intercepted by a MitM proxy
- The proxy makes a separate connection to the NATS server
- The NATS server replies with an
INFOmessage - The proxy reads the
INFO, alters thehostJSON field and passes the tamperedINFOback to the client - The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client's keychain. In the previous step the
hostwas set to the common name of said certificate rustlsaccepts the certificate, having verified that the common name matches the attacker-controlled value it was given- The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate
Impact
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-WVC4-J7G5-4F79? GHSA-WVC4-J7G5-4F79 is a medium-severity security vulnerability in nats (rust), affecting versions >= 0.9.0, <= 0.24.0. It is fixed in 0.24.1.
- Which versions of nats are affected by GHSA-WVC4-J7G5-4F79? nats (rust) versions >= 0.9.0, <= 0.24.0 is affected.
- Is there a fix for GHSA-WVC4-J7G5-4F79? Yes. GHSA-WVC4-J7G5-4F79 is fixed in 0.24.1. Upgrade to this version or later.
- Is GHSA-WVC4-J7G5-4F79 exploitable, and should I be worried? Whether GHSA-WVC4-J7G5-4F79 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-WVC4-J7G5-4F79 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-WVC4-J7G5-4F79? Upgrade
natsto 0.24.1 or later.