Deps.rs

actix-telepathy 0.7.0

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 actix-telepathy

Dependencies

(21 total, 2 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 actix=0.13.50.13.5up to date
 actix-broker^0.4.30.4.4up to date
 actix_telepathy_derive^0.4.00.4.0up to date
 byteorder^1.31.5.0up to date
 bytes^1.11.11.12.1up to date
 derive_more^2.1.12.1.1up to date
 env_logger^0.110.11.11up to date
 flexbuffers^25.12.1925.12.19up to date
 futures^0.30.3.34up to date
 hickory-proto ⚠️^0.25.20.26.1out of date
 hickory-resolver^0.25.20.26.1out of date
 log^0.40.4.33up to date
 once_cell^1.5.21.21.4up to date
 parking_lot^0.120.12.5up to date
 rand^0.10.00.10.2up to date
 serde^1.01.0.229up to date
 serde_derive^1.01.0.229up to date
 tokio^1.331.53.1up to date
 tokio-stream^0.10.1.19up to date
 tokio-util^0.70.7.19up to date
 uuid^1.01.24.0up to date

Dev dependencies

(5 total, all up-to-date)

CrateRequiredLatestStatus
 actix-rt^2.9.02.11.0up to date
 futures-sink^0.3.210.3.34up to date
 port_scanner^0.1.50.1.5up to date
 rayon^1.5.01.12.0up to date
 testing_logger^0.1.10.1.1up to date

Security Vulnerabilities

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

RUSTSEC-2026-0118

The NSEC3 closest-encloser proof validation in hickory-proto'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.

The affected code was migrated from hickory-proto to hickory-net as part of the 0.26.0 release. The hickory-proto 0.26.x release no longer offers DnssecDnsHandle and so we recommend all affected users update to hickory-net 0.26.1 when the implementation of that type is required.

hickory-proto: CPU exhaustion during message encoding due to O(n²) name compression

RUSTSEC-2026-0119

During message encoding, hickory-proto's BinEncoder stores pointers to labels that are candidates for name compression in a Vec<(usize, Vec<u8>)>. The name compression logic then searches for matches with a linear scan.

A malicious message with many records can both introduce many candidate labels, and invoke this linear scan many times. This can amplify CPU exhaustion in DoS attacks.

This is similar to CVE-2024-8508.

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