NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

async-nats vulnerable to TLS certificate common name validation bypassGHSA-f5v5-ccqc-6w36

Fix: nats-io/nats.rs@817a7b9

GHSA-f5v5-ccqc-6w36 is a security vulnerability in async-nats. A fix is available for async-nats — see the affected versions and patch details below.

Also known asRUSTSEC-2023-0027
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 8, 2023 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🦀async-nats

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

The NATS official Rust clients are vulnerable to MitM when using TLS.

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

  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
  8. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.ioasync-natsall versions0.29.0cargo update -p async-nats --precise 0.29.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for async-nats, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update async-nats to 0.29.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f5v5-ccqc-6w36 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

The NATS official Rust clients are vulnerable to MitM when using TLS. 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. ## Reproduction steps 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 NAT
O3 Security · Impact-Aware SCA

Is GHSA-f5v5-ccqc-6w36 in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works
async-nats vulnerable to TLS certificate common name…