https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 03:07:27 +0000 https://cve.radiocsirt.org/vuln/ghsa-wvc4-j7g5-4f79 <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&#39;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&#39;s TLS certificate is validated against the `host`name provided by the server&#39;s plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field&#39;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&#39;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> <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&#39;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&#39;s TLS certificate is validated against the `host`name provided by the server&#39;s plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field&#39;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&#39;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> https://cve.radiocsirt.org/vuln/ghsa-wvc4-j7g5-4f79