This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate cyper-hickory

Dependencies

(15 total, 1 possibly insecure)

CrateRequiredLatestStatus
 async-trait^0.10.1.92up to date
 compio^0.19.00.19.2up to date
 compio-log^0.2.00.2.1up to date
 cyper-core^0.9.00.9.0up to date
 futures-channel^0.3.290.3.34up to date
 futures-util^0.3.300.3.34up to date
 hickory-net ⚠️^0.260.26.2maybe insecure
 hickory-resolver^0.260.26.2up to date
 http^1.0.01.5.0up to date
 http-body-util^0.1.00.1.5up to date
 hyper^1.4.11.11.1up to date
 hyper-util^0.1.200.1.20up to date
 quinn^0.110.11.11up to date
 send_wrapper^0.60.6.0up to date
 tower-service^0.3.20.3.3up to date

Dev dependencies

(7 total, 1 possibly insecure)

CrateRequiredLatestStatus
 compio^0.19.00.19.2up to date
 futures-channel^0.3.290.3.34up to date
 hickory-resolver^0.260.26.2up to date
 hickory-server^0.260.26.2up to date
 rcgen^0.140.14.10up to date
 tokio ⚠️^11.53.1maybe insecure
 tokio-util^0.70.7.19up to date

Security Vulnerabilities

tokio: reject_remote_clients Configuration corruption

RUSTSEC-2023-0001

On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);

hickory-net: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

RUSTSEC-2026-0120

The NSEC3 closest-encloser proof validation in hickory-net's DnssecDnsHandle walks from the QNAME up to the SOA owner name, building a list of candidate encloser names. The iterator used assumes the QNAME is a descendant of the SOA owner, terminating only when the current candidate equals the SOA name. When the SOA in a response's authority section is not an ancestor of the QNAME, the loop stalls at the DNS root and never terminates, repeatedly calling Name::base_name() and pushing newly allocated Name and hashed-name entries into the candidate Vec.

The bug is reachable by any caller of DnssecDnsHandle — including the resolver, recursor, and client — when built with the dnssec-ring or dnssec-aws-lc-rs feature and configured to perform DNSSEC validation. It is triggered while validating a NoData or NXDomain response whose authority section contains an SOA record from a zone other than an ancestor of the QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice this can be reached through an insecure CNAME chain that crosses zone boundaries into a DNSSEC-signed zone returning NoData, but the minimum condition is just a mismatched SOA owner on a response requiring NSEC3 validation.

A debug_assert_ne!(name, Name::root()) guards the loop body, so debug builds abort with a panic on the first iteration past the root. Release builds compile the assertion out and run the loop unbounded, allocating until the process exhausts available memory (OOM). A reachable upstream attacker who can return such a response can therefore crash a debug-built validator or exhaust memory on a release-built one.

We recommend all affected users update to hickory-net 0.26.1 for the fix.