This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate trust-dns-server

Dependencies

(23 total, 9 outdated, 2 insecure)

CrateRequiredLatestStatus
 async-trait^0.1.430.1.92up to date
 bytes^11.12.1up to date
 cfg-if^11.0.5up to date
 drain^0.1.10.2.1out of date
 enum-as-inner^0.60.7.0out of date
 futures-executor^0.3.50.3.34up to date
 futures-util^0.3.50.3.34up to date
 h2 ⚠️^0.3.00.4.20insecure
 http^0.21.5.0out of date
 openssl^0.10.550.10.82up to date
 rusqlite^0.29.00.42.0out of date
 rustls ⚠️^0.21.00.23.46insecure
 serde^1.01.0.229up to date
 thiserror^1.0.202.0.21out of date
 time^0.30.3.55up to date
 tokio^1.211.54.1up to date
 tokio-openssl^0.6.00.6.5up to date
 tokio-rustls^0.24.00.26.6out of date
 toml^0.71.2.1+spec-1.1.0out of date
 tracing^0.1.300.1.44up to date
 trust-dns-proto^0.23.20.23.2up to date
 trust-dns-recursor^0.23.20.23.2up to date
 trust-dns-resolver^0.23.20.23.2up to date

Dev dependencies

(2 total, all up-to-date)

CrateRequiredLatestStatus
 tokio^1.211.54.1up to date
 tracing-subscriber^0.30.3.23up to date

Security Vulnerabilities

h2: h2 unbounded empty DATA frames

RUSTSEC-2026-0258

The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit. If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.

Low severity.

Patched in v0.4.16.

rustls: `Debug` impls for client session values expose TLS secrets

RUSTSEC-2026-0346

The Debug implementations of Tls12ClientSessionValue and Tls13ClientSessionValue were derived, and so included the TLS 1.2 master secret or TLS 1.3 resumption PSK in their output.

Custom ClientSessionStore implementations that format these values with Debug (for example, when logging) could disclose these secrets to readers of the logs. This conflicts with rustls's key-material redaction policy.

Ordinary connection and built-in session cache Debug output is redacted and is not affected.

rustls: Unauthenticated ServerHello can downgrade later connections to classical key exchange

RUSTSEC-2026-0349

The client recorded the server-selected key exchange group for each server name when processing the ServerHello, before the server was authenticated. This record is used to predict which key share to send in future ClientHellos to that server name.

A network attacker can answer one connection attempt with a ServerHello selecting X25519, and then close the connection. Later ClientHellos for that name carry only an X25519 key share, while supported_groups still lists X25519MLKEM768 first. If the genuine server accepts that share rather than sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical-only key exchange and no error. This persists for as long as the entry stays in the client's session store.

The impact is loss of post-quantum confidentiality for affected connections ("harvest now, decrypt later"). There is no key compromise and no authentication bypass.

The following are not affected:

  • connections to servers which send a HelloRetryRequest for their preferred group,
  • clients with resumption disabled (as nothing is stored), and
  • other server names.

This behaviour is discussed in draft-ietf-tls-key-share-prediction, so the practical impact depends largely on server policy.