<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T03:07:28.532654+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-wvc4-j7g5-4f79</id>
    <title>GHSA-wvc4-j7g5-4f79 — NATS TLS certificate common name validation bypass</title>
    <updated>2026-10-08T03:07:28.533743+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: nats</p>
<p>The NATS official Rust clients are vulnerable to MitM when using TLS.</p>
<p>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` `&gt;= 0.29` which already fixed this vulnerability.</p>
<p>The common name of the server's TLS certificate is validated against the `host`name 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.</p>
<p>## Reproduction steps</p>
<p>1. The NATS Rust client tries to establish a new connection
2. The connection is intercepted by a MitM proxy
3. The proxy makes a separate connection to the NATS server
4. The NATS server replies with an `INFO` message
5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client
6. 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 `host` was set to the common name of said certificate
7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given
9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-wvc4-j7g5-4f79"/>
  </entry>
</feed>
