Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package ztunnel-fips version 1.25.5-r0 fixes 8 vulnerabilities: ghsa-rr8g-9fpq-6wmg, ghsa-xwfj-jgwm-7wp5, ghsa-2gh3-rmm4-6rq5, ghsa-37wc-h8xc-5hc4, ghsa-v7pc-74h8-xq2h...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "ztunnel-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.25.5-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.25.5-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package ztunnel-fips version 1.25.5-r0 fixes 8 vulnerabilities: ghsa-rr8g-9fpq-6wmg, ghsa-xwfj-jgwm-7wp5, ghsa-2gh3-rmm4-6rq5, ghsa-37wc-h8xc-5hc4, ghsa-v7pc-74h8-xq2h...",
"id": "CLEANSTART-2026-CG30093",
"modified": "2026-07-30T09:34:55Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/istio/ztunnel"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in ztunnel-fips 1.25.5-r0",
"upstream": [
"ghsa-rr8g-9fpq-6wmg",
"ghsa-xwfj-jgwm-7wp5",
"ghsa-2gh3-rmm4-6rq5",
"ghsa-37wc-h8xc-5hc4",
"ghsa-v7pc-74h8-xq2h",
"ghsa-4p46-pwfr-66x6",
"ghsa-c86p-w88r-qvqr",
"ghsa-pg9f-39pc-qf8g"
]
}
GHSA-2GH3-RMM4-6RQ5
Vulnerability from github – Published: 2025-03-07 20:02 – Updated: 2025-08-01 19:20Affected version of this crate did not properly parse unknown fields when parsing a user-supplied input.
This allows an attacker to cause a stack overflow when parsing the message on untrusted data.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53605"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-07T20:02:37Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Affected version of this crate did not properly parse unknown fields when parsing a user-supplied input.\n\nThis allows an attacker to cause a stack overflow when parsing the message on untrusted data.",
"id": "GHSA-2gh3-rmm4-6rq5",
"modified": "2025-08-01T19:20:19Z",
"published": "2025-03-07T20:02:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53605"
},
{
"type": "WEB",
"url": "https://github.com/stepancheg/rust-protobuf/issues/749"
},
{
"type": "WEB",
"url": "https://github.com/stepancheg/rust-protobuf/commit/f06992f46771c0a092593b9ebf7afd48740b3ed6"
},
{
"type": "PACKAGE",
"url": "https://github.com/stepancheg/rust-protobuf"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0437.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Crash due to uncontrolled recursion in protobuf crate"
}
GHSA-37WC-H8XC-5HC4
Vulnerability from github – Published: 2025-02-10 17:46 – Updated: 2025-02-10 19:51Summary
The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.
Details
verify_dnskey_rrset() will return Ok(true) if any record's public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.
Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but this is only checking that one key is authenticated by a DS in the parent zone's delegation point. This time, after control flow returns to verify_rrset(), it will call verify_default_rrset(). The special handling for DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey() using each KSK DNSKEY record, and if one call succeeds, return its Proof. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut verify_default_rrset() out of DNSKEY RRset validation entirely.
PoC
The proof of concepts have been integrated into the conformance test suite, as resolver::dnssec::scenarios::bogus::bogus_zone_plus_trust_anchor_dnskey and resolver::dnssec::scenarios::bogus::bogus_zone_plus_ds_covered_dnskey.
Impact
This impacts Hickory DNS users relying on DNSSEC verification in the client library, stub resolver, or recursive resolver.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "hickory-proto"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "0.24.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-25188"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-10T17:46:00Z",
"nvd_published_at": "2025-02-10T18:15:35Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.\n\n### Details\n`verify_dnskey_rrset()` will return `Ok(true)` if any record\u0027s public key matches a trust anchor. This results in `verify_rrset()` returning a `Secure` proof. This ultimately results in successfully verifying a response containing DNSKEY records. `verify_default_rrset()` looks up DNSKEY records by calling `handle.lookup()`, which takes the above code path. There\u0027s a comment following this that says \"DNSKEYs were already validated by the inner query in the above lookup\", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in `verify_default_rrset()`, `verify_rrset_with_dnskey()` is called multiple times with different keys and signatures, and if any call succeeds, then its `Proof` is returned.\n\nSimilarly, `verify_dnskey_rrset()` returns `Ok(false)` if any DNSKEY record is covered by a DS record. A comment says \"If all the keys are valid, then we are secure\", but this is only checking that one key is authenticated by a DS in the parent zone\u0027s delegation point. This time, after control flow returns to `verify_rrset()`, it will call `verify_default_rrset()`. The special handling for DNSKEYs in `verify_default_rrset()` will then call `verify_rrset_with_dnskey()` using each KSK DNSKEY record, and if one call succeeds, return its `Proof`. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside `verify_dnskey_rrset()` and cut `verify_default_rrset()` out of DNSKEY RRset validation entirely.\n\n### PoC\nThe proof of concepts have been integrated into the conformance test suite, as `resolver::dnssec::scenarios::bogus::bogus_zone_plus_trust_anchor_dnskey` and `resolver::dnssec::scenarios::bogus::bogus_zone_plus_ds_covered_dnskey`.\n\n### Impact\nThis impacts Hickory DNS users relying on DNSSEC verification in the client library, stub resolver, or recursive resolver.",
"id": "GHSA-37wc-h8xc-5hc4",
"modified": "2025-02-10T19:51:23Z",
"published": "2025-02-10T17:46:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-37wc-h8xc-5hc4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25188"
},
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/commit/e118c6eec569f4340421f86ee0686714010c63e9"
},
{
"type": "PACKAGE",
"url": "https://github.com/hickory-dns/hickory-dns"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Hickory DNS\u0027s DNSSEC validation may accept broken authentication chains"
}
GHSA-4P46-PWFR-66X6
Vulnerability from github – Published: 2025-03-07 16:23 – Updated: 2025-12-29 21:37ring::aead::quic::HeaderProtectionKey::new_mask() may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 2**32 packets sent and/or received.
On 64-bit targets operations using ring::aead::{AES_128_GCM, AES_256_GCM} may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk.
Overflow checking is not enabled in release mode by default, but RUSTFLAGS="-C overflow-checks" or overflow-checks = true in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ring"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-4432"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-07T16:23:50Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "`ring::aead::quic::HeaderProtectionKey::new_mask()` may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 2**32 packets sent and/or received.\n\nOn 64-bit targets operations using `ring::aead::{AES_128_GCM, AES_256_GCM}` may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk.\n\nOverflow checking is not enabled in release mode by default, but `RUSTFLAGS=\"-C overflow-checks\"` or `overflow-checks = true` in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.",
"id": "GHSA-4p46-pwfr-66x6",
"modified": "2025-12-29T21:37:23Z",
"published": "2025-03-07T16:23:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4432"
},
{
"type": "WEB",
"url": "https://github.com/briansmith/ring/pull/2447"
},
{
"type": "WEB",
"url": "https://github.com/briansmith/ring/commit/ec2d3cf1d91f148c84e4806b4f0b3c98f6df3b38"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-4432"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2350655"
},
{
"type": "PACKAGE",
"url": "https://github.com/briansmith/ring"
},
{
"type": "WEB",
"url": "https://github.com/briansmith/ring/blob/main/RELEASES.md#version-01712-2025-03-05"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0009.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Some AES functions may panic when overflow checking is enabled in ring"
}
GHSA-C86P-W88R-QVQR
Vulnerability from github – Published: 2025-05-09 18:30 – Updated: 2025-12-29 21:36Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-4p46-pwfr-66x6. This link is maintained to preserve external references.
Original Description
A flaw was found in Rust's Ring package. A panic may be triggered when overflow checking is enabled. In the QUIC protocol, this flaw allows an attacker to induce this panic by sending a specially crafted packet. It will likely occur unintentionally in 1 out of every 2**32 packets sent or received.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "ring"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-09T19:42:41Z",
"nvd_published_at": "2025-05-09T16:15:25Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-4p46-pwfr-66x6. This link is maintained to preserve external references.\n\n### Original Description\nA flaw was found in Rust\u0027s Ring package. A panic may be triggered when overflow checking is enabled. In the QUIC protocol, this flaw allows an attacker to induce this panic by sending a specially crafted packet. It will likely occur unintentionally in 1 out of every 2**32 packets sent or received.",
"id": "GHSA-c86p-w88r-qvqr",
"modified": "2025-12-29T21:36:51Z",
"published": "2025-05-09T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4432"
},
{
"type": "WEB",
"url": "https://github.com/briansmith/ring/pull/2447"
},
{
"type": "WEB",
"url": "https://github.com/briansmith/ring/commit/ec2d3cf1d91f148c84e4806b4f0b3c98f6df3b38"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-4432"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2350655"
},
{
"type": "PACKAGE",
"url": "https://github.com/briansmith/ring"
},
{
"type": "WEB",
"url": "https://github.com/briansmith/ring/blob/main/RELEASES.md#version-01712-2025-03-05"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0009.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: ring has some AES functions that may panic when overflow checking is enabled in",
"withdrawn": "2025-12-29T21:36:51Z"
}
GHSA-PG9F-39PC-QF8G
Vulnerability from github – Published: 2025-04-10 14:30 – Updated: 2025-09-25 21:13The internal Channel type's Drop method has a race
which could, in some circumstances, lead to a double-free.
This could result in memory corruption.
Quoting from the upstream description in merge request #1187:
The problem lies in the fact that
dicard_all_messagescontained two paths that could lead tohead.blockbeing read but only one of them would swap the value. This meant thatdicard_all_messagescould end up observing a non-null block pointer (and therefore attempting to free it) without settinghead.blockto null. This would then lead toChannel::dropmaking a second attempt at dropping the same pointer.
The bug was introduced while fixing a memory leak, in upstream MR #1084, first published in 0.5.12.
The fix is in upstream MR #1187 and has been published in 0.5.15
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "crossbeam-channel"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.12"
},
{
"fixed": "0.5.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-4574"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-10T14:30:39Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The internal `Channel` type\u0027s `Drop` method has a race\nwhich could, in some circumstances, lead to a double-free.\nThis could result in memory corruption.\n\nQuoting from the\n[upstream description in merge request \\#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187#issue-2980761131):\n\n\u003e The problem lies in the fact that `dicard_all_messages` contained two paths that could lead to `head.block` being read but only one of them would swap the value. This meant that `dicard_all_messages` could end up observing a non-null block pointer (and therefore attempting to free it) without setting `head.block` to null. This would then lead to `Channel::drop` making a second attempt at dropping the same pointer.\n\nThe bug was introduced while fixing a memory leak, in\nupstream [MR \\#1084](https://github.com/crossbeam-rs/crossbeam/pull/1084),\nfirst published in 0.5.12.\n\nThe fix is in\nupstream [MR \\#1187](https://github.com/crossbeam-rs/crossbeam/pull/1187)\nand has been published in 0.5.15",
"id": "GHSA-pg9f-39pc-qf8g",
"modified": "2025-09-25T21:13:01Z",
"published": "2025-04-10T14:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4574"
},
{
"type": "WEB",
"url": "https://github.com/crossbeam-rs/crossbeam/pull/1187"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-4574"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2358890"
},
{
"type": "PACKAGE",
"url": "https://github.com/crossbeam-rs/crossbeam"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0024.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "crossbeam-channel Vulnerable to Double Free on Drop"
}
GHSA-RR8G-9FPQ-6WMG
Vulnerability from github – Published: 2025-04-07 21:12 – Updated: 2025-04-07 21:12The broadcast channel internally calls clone on the stored value when receiving it, and only requires T:Send. This means that using the broadcast channel with values that are Send but not Sync can trigger unsoundness if the clone implementation makes use of the value being !Sync.
Thank you to Austin Bonander for finding and reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tokio"
},
"ranges": [
{
"events": [
{
"introduced": "1.44.0"
},
{
"fixed": "1.44.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "tokio"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.5"
},
{
"fixed": "1.38.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "tokio"
},
"ranges": [
{
"events": [
{
"introduced": "1.39.0"
},
{
"fixed": "1.43.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-664"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-07T21:12:50Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`.\n\nThank you to Austin Bonander for finding and reporting this issue.",
"id": "GHSA-rr8g-9fpq-6wmg",
"modified": "2025-04-07T21:12:50Z",
"published": "2025-04-07T21:12:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tokio/pull/7232"
},
{
"type": "PACKAGE",
"url": "https://github.com/tokio-rs/tokio"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0023.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Tokio broadcast channel calls clone in parallel, but does not require `Sync`"
}
GHSA-V7PC-74H8-XQ2H
Vulnerability from github – Published: 2025-02-10 21:52 – Updated: 2025-02-10 21:52Summary
The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.
Details
verify_dnskey_rrset() will return Ok(true) if any record's public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There's a comment following this that says "DNSKEYs were already validated by the inner query in the above lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.
Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says "If all the keys are valid, then we are secure", but this is only checking that one key is authenticated by a DS in the parent zone's delegation point. This time, after control flow returns to verify_rrset(), it will call verify_default_rrset(). The special handling for DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey() using each KSK DNSKEY record, and if one call succeeds, return its Proof. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut verify_default_rrset() out of DNSKEY RRset validation entirely.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "hickory-proto"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "0.24.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "hickory-proto"
},
"ranges": [
{
"events": [
{
"introduced": "0.25.0-alpha.1"
},
{
"fixed": "0.25.0-alpha.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-10T21:52:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Summary\n\nThe DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.\n\nDetails\n\nverify_dnskey_rrset() will return Ok(true) if any record\u0027s public key matches a trust anchor. This results in verify_rrset() returning a Secure proof. This ultimately results in successfully verifying a response containing DNSKEY records. verify_default_rrset() looks up DNSKEY records by calling handle.lookup(), which takes the above code path. There\u0027s a comment following this that says \"DNSKEYs were already validated by the inner query in the above lookup\", but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is called multiple times with different keys and signatures, and if any call succeeds, then its Proof is returned.\n\nSimilarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is covered by a DS record. A comment says \"If all the keys are valid, then we are secure\", but this is only checking that one key is authenticated by a DS in the parent zone\u0027s delegation point. This time, after control flow returns to verify_rrset(), it will call verify_default_rrset(). The special handling for DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey() using each KSK DNSKEY record, and if one call succeeds, return its Proof. If there are multiple KSK DNSKEYs in the RRset, then this leads to another authentication break. We need to either pass the authenticated DNSKEYs from the DS covering check to the RRSIG validation, or we need to perform this RRSIG validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut verify_default_rrset() out of DNSKEY RRset validation entirely.",
"id": "GHSA-v7pc-74h8-xq2h",
"modified": "2025-02-10T21:52:29Z",
"published": "2025-02-10T21:52:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-37wc-h8xc-5hc4"
},
{
"type": "PACKAGE",
"url": "https://github.com/hickory-dns/hickory-dns"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0006.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Hickory DNS failure to verify self-signed RRSIG for DNSKEYs"
}
GHSA-XWFJ-JGWM-7WP5
Vulnerability from github – Published: 2025-08-29 20:33 – Updated: 2025-09-02 16:35Impact
Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:
- Manipulate terminal title bars
- Clear screens or modify terminal display
- Potentially mislead users through terminal manipulation
In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.
Patches
tracing-subscriber version 0.3.20 fixes this vulnerability by escaping ANSI control characters in when writing events to destinations that may be printed to the terminal.
Workarounds
Avoid printing logs to terminal emulators without escaping ANSI control sequences.
References
https://www.packetlabs.net/posts/weaponizing-ansi-escape-sequences/
Acknowledgments
We would like to thank zefr0x who responsibly reported the issue at security@tokio.rs.
If you believe you have found a security vulnerability in any tokio-rs project, please email us at security@tokio.rs.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "tracing-subscriber"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58160"
],
"database_specific": {
"cwe_ids": [
"CWE-150"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-29T20:33:56Z",
"nvd_published_at": "2025-08-29T22:15:32Z",
"severity": "LOW"
},
"details": "### Impact\n\nPrevious versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:\n\n- Manipulate terminal title bars\n- Clear screens or modify terminal display\n- Potentially mislead users through terminal manipulation\n\nIn isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.\n\n### Patches\n\n`tracing-subscriber` version 0.3.20 fixes this vulnerability by escaping ANSI control characters in when writing events to destinations that may be printed to the terminal.\n\n### Workarounds\n\nAvoid printing logs to terminal emulators without escaping ANSI control sequences.\n\n### References\n\nhttps://www.packetlabs.net/posts/weaponizing-ansi-escape-sequences/\n\n\n### Acknowledgments\n\nWe would like to thank [zefr0x](http://github.com/zefr0x) who responsibly reported the issue at `security@tokio.rs`.\n\nIf you believe you have found a security vulnerability in any tokio-rs project, please email us at `security@tokio.rs`.",
"id": "GHSA-xwfj-jgwm-7wp5",
"modified": "2025-09-02T16:35:51Z",
"published": "2025-08-29T20:33:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tokio-rs/tracing/security/advisories/GHSA-xwfj-jgwm-7wp5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58160"
},
{
"type": "PACKAGE",
"url": "https://github.com/tokio-rs/tracing"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0055.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": " Tracing logging user input may result in poisoning logs with ANSI escape sequences"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.