{"id":"GHSA-wvc4-j7g5-4f79","aliases":["RUSTSEC-2023-0029"],"status":"published","title":"NATS TLS certificate common name validation bypass","description":"The NATS official Rust clients are vulnerable to MitM when using TLS.\n\nA 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` `\u003e= 0.29` which already fixed this vulnerability.\n\nThe 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.\n\n## Reproduction steps\n\n1. The NATS Rust client tries to establish a new connection\n2. The connection is intercepted by a MitM proxy\n3. The proxy makes a separate connection to the NATS server\n4. The NATS server replies with an `INFO` message\n5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client\n6. 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\n7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given\n9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate","facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-347"],"published":"2023-03-24T12:00:00Z","modified":"2023-11-08T17:39:22Z","fixes":[{"ecosystem":"crates.io","package":"nats","fixed_in":["0.24.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"nats","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.9.0"},{"last_affected":"0.24.0"},{"fixed":"0.24.1"}]}]},{"source":"osv","ecosystem":"crates.io","package":"nats","ranges":[{"type":"SEMVER","events":[{"introduced":"0.9.0"},{"fixed":"0.24.1"}]}]},{"source":"osv","ecosystem":"crates.io","package":"nats","ranges":[{"type":"SEMVER","events":[{"introduced":"0.9.0"},{"fixed":"0.24.1"}]}]}],"references":[{"url":"https://github.com/nats-io/nats.rs/pull/881","tags":["web"]},{"url":"https://github.com/nats-io/nats.rs/pull/887","tags":["web"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2023-0029.html","tags":["web","advisory"]},{"url":"https://github.com/nats-io/nats.rs/commit/9bacb86a480803ece9d1a45aa443081cf1eb815c","tags":["web"]},{"url":"https://github.com/advisories/GHSA-wvc4-j7g5-4f79"},{"url":"https://github.com/nats-io/nats.rs","tags":["package"]},{"url":"https://crates.io/crates/nats","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-wvc4-j7g5-4f79","title":"NATS TLS certificate common name validation bypass","description":"The NATS official Rust clients are vulnerable to MitM when using TLS.\n\nA 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` `\u003e= 0.29` which already fixed this vulnerability.\n\nThe 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.\n\n## Reproduction steps\n\n1. The NATS Rust client tries to establish a new connection\n2. The connection is intercepted by a MitM proxy\n3. The proxy makes a separate connection to the NATS server\n4. The NATS server replies with an `INFO` message\n5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client\n6. 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\n7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given\n9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate\n","status":"published","published":"2023-03-27T21:12:24Z","modified":"2023-11-08T17:39:22Z","cwes":["CWE-347"],"updated_at":"2026-11-02T14:37:17.64478Z"}],"osv":[{"id":"GHSA-wvc4-j7g5-4f79","title":"NATS TLS certificate common name validation bypass","description":"The NATS official Rust clients are vulnerable to MitM when using TLS.\n\nA 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` `\u003e= 0.29` which already fixed this vulnerability.\n\nThe 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.\n\n## Reproduction steps\n\n1. The NATS Rust client tries to establish a new connection\n2. The connection is intercepted by a MitM proxy\n3. The proxy makes a separate connection to the NATS server\n4. The NATS server replies with an `INFO` message\n5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client\n6. 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\n7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given\n9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate\n","status":"published","published":"2023-03-27T21:12:24Z","modified":"2023-11-08T04:24:00.164703Z","cwes":["CWE-347"],"updated_at":"2026-11-02T15:46:59.131095Z"},{"id":"RUSTSEC-2023-0029","title":"TLS certificate common name validation bypass","description":"The NATS official Rust clients are vulnerable to MitM when using TLS.\n\nThe common name of the server's TLS certificate is validated against\nthe `host`name provided by the server's plaintext `INFO` message\nduring the initial connection setup phase. A MitM proxy can tamper with\nthe `host` field's value by substituting it with the common name of a\nvalid certificate it controls, fooling the client into accepting it.\n\n## Reproduction steps\n\n1. The NATS Rust client tries to establish a new connection\n2. The connection is intercepted by a MitM proxy\n3. The proxy makes a separate connection to the NATS server\n4. The NATS server replies with an `INFO` message\n5. The proxy reads the `INFO`, alters the `host` JSON field and passes\n   the tampered `INFO` back to the client\n6. The proxy upgrades the client connection to TLS, presenting a certificate issued\n   by a certificate authority present in the client's keychain.\n   In the previous step the `host` was set to the common name of said certificate\n7. `rustls` accepts the certificate, having verified that the common name matches the\n   attacker-controlled value it was given\n9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate","status":"published","published":"2023-03-24T12:00:00Z","modified":"2023-11-08T09:57:41Z","updated_at":"2026-11-02T15:53:39.971022Z"}]}}