vuln-osv update 2026-11-13T18:44:15Z
This commit is contained in:
Vulnerability Bot committed
1 parent
0808e998f0
commit
9c8703d76c
67 files changed
+85
-38
No files matched your search
@@ -1 +1 @@
|
||||
{"schema_version":"1.9.0","id":"GHSA-5hq8-qhww-jm7q","published":"2026-09-15T20:01:17Z","modified":"2026-09-15T20:15:04.814697144Z","aliases":["CVE-2026-61544"],"summary":"libp2p-quic: Remote panic via certificate expiry race during QUIC handshake","details":"### Summary\n\n`libp2p-quic` can panic on an inbound QUIC handshake if a malicious peer presents a valid, short lived libp2p TLS certificate and delays the final TLS 1.3 handshake fragment until the certificate expires.\n\nThis is remotely reachable by a network peer and can crash applications exposing a libp2p QUIC listener.\n\n### Details\nDuring the TLS handshake, `libp2p-tls` parses and validates the peer certificate. After Quinn reports handshake completion, `libp2p-quic` re-parses the same certificate in the post-handshake upgrade path and assumes this cannot fail:\n\nhttps://github.com/libp2p/rust-libp2p/blob/969b707bf1177ebebd1febc285c3fd22793b95c5/transports/quic/src/connection/connecting.rs#L65-L66\n\nHowever, `libp2p_tls::certificate::parse()` re-runs certificate verification on every call, including a wall-clock validity check. A certificate that was valid during the first handshake time parse can expire before the second post-handshake parse, causing the `expect(...)` to panic.\n\n\n### PoC\nA malicious peer can trigger this by:\n1. Opening a QUIC connection to a libp2p QUIC listener.\n2. Presenting a valid libp2p TLS certificate with a very short lifetime.\n3. Allowing the initial handshake-time certificate validation to succeed.\n4. Withholding the final client handshake fragment packet until after the certificate expires, but before the QUIC handshake timeout elapses.\n5. The listener completes the handshake and hits the post-handshake certificate re-parse, which panics.\n\n### Impact\nRemote unauthenticated denial of service. Any application exposing an affected `libp2p-quic` listener can be crashed by a network peer that performs a valid-looking QUIC/TLS handshake with attacker-controlled timing. No malformed packets are required.","affected":[{"package":{"name":"libp2p-quic","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-quic"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.13.1"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-5hq8-qhww-jm7q/GHSA-5hq8-qhww-jm7q.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-5hq8-qhww-jm7q"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/pull/6525"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/212f3774af048e2cecfb2e6b1e08477685e52b22"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/e8f35e12c2418b04df6e9cdf036005e8aee3c7a2"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":[],"github_reviewed":true,"github_reviewed_at":"2026-09-15T20:01:17Z","nvd_published_at":null,"severity":"HIGH"},"severity":[{"type":"CVSS_V4","score":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"}]}
|
||||
{"schema_version":"1.9.0","id":"GHSA-5hq8-qhww-jm7q","published":"2026-09-15T20:01:17Z","modified":"2026-11-13T12:56:08.635291670Z","aliases":["CVE-2026-61544","RUSTSEC-2026-0525"],"summary":"libp2p-quic: Remote panic via certificate expiry race during QUIC handshake","details":"### Summary\n\n`libp2p-quic` can panic on an inbound QUIC handshake if a malicious peer presents a valid, short lived libp2p TLS certificate and delays the final TLS 1.3 handshake fragment until the certificate expires.\n\nThis is remotely reachable by a network peer and can crash applications exposing a libp2p QUIC listener.\n\n### Details\nDuring the TLS handshake, `libp2p-tls` parses and validates the peer certificate. After Quinn reports handshake completion, `libp2p-quic` re-parses the same certificate in the post-handshake upgrade path and assumes this cannot fail:\n\nhttps://github.com/libp2p/rust-libp2p/blob/969b707bf1177ebebd1febc285c3fd22793b95c5/transports/quic/src/connection/connecting.rs#L65-L66\n\nHowever, `libp2p_tls::certificate::parse()` re-runs certificate verification on every call, including a wall-clock validity check. A certificate that was valid during the first handshake time parse can expire before the second post-handshake parse, causing the `expect(...)` to panic.\n\n\n### PoC\nA malicious peer can trigger this by:\n1. Opening a QUIC connection to a libp2p QUIC listener.\n2. Presenting a valid libp2p TLS certificate with a very short lifetime.\n3. Allowing the initial handshake-time certificate validation to succeed.\n4. Withholding the final client handshake fragment packet until after the certificate expires, but before the QUIC handshake timeout elapses.\n5. The listener completes the handshake and hits the post-handshake certificate re-parse, which panics.\n\n### Impact\nRemote unauthenticated denial of service. Any application exposing an affected `libp2p-quic` listener can be crashed by a network peer that performs a valid-looking QUIC/TLS handshake with attacker-controlled timing. No malformed packets are required.","affected":[{"package":{"name":"libp2p-quic","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-quic"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.13.1"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/09/GHSA-5hq8-qhww-jm7q/GHSA-5hq8-qhww-jm7q.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-5hq8-qhww-jm7q"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/pull/6525"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/212f3774af048e2cecfb2e6b1e08477685e52b22"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/e8f35e12c2418b04df6e9cdf036005e8aee3c7a2"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":[],"github_reviewed":true,"github_reviewed_at":"2026-09-15T20:01:17Z","nvd_published_at":null,"severity":"HIGH"},"severity":[{"type":"CVSS_V4","score":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"}]}
|
||||
@@ -1 +1 @@
|
||||
{"schema_version":"1.9.0","id":"GHSA-cqfx-gf56-8x59","published":"2026-04-04T06:33:46Z","modified":"2026-06-09T10:45:13.923189467Z","aliases":["CVE-2026-35405"],"summary":"libp2p-rendezvous: Unlimited namespace registrations per peer enables OOM DoS on rendezvous servers","details":"### Summary\nfound that `libp2p-rendezvous` server has no limit on how many namespaces a single peer can register. a malicious peer can just keep registering unique namespaces in a loop and the server happily accepts every single one allocating memory for each registration with no pushback. keep doing this long enough (or with multiple sybil peers) and the server process gets OOM killed.\n\nno auth required. any peer on the network can do this.\n\n\n\n### Details\n\nthe bug is in `Registrations::add()` inside `protocols/rendezvous/src/server.rs`.\n\nthe store uses a BiMap keyed on `(PeerId, Namespace)` so yes, a peer can't register the *same* namespace twice. but there's nothing stopping it from registering 10,000 *different* namespaces. each unique one gets its own entry in:\n\n- `registrations_for_peer` (BiMap)\n- `registrations` (HashMap)\n- `next_expiry` (FuturesUnordered a new heap-allocated BoxFuture per registration)\n\nnamespace strings are only validated for length (`MAX_NAMESPACE = 255`), not count. there's no `max_registrations_per_peer` anywhere in `Config` or the rest of the codebase.\n\nmaking it worse `MAX_TTL = 72 hours`. so every registration just sits there for up to 3 days. disconnecting doesn't clean anything up either, entries only go away when the TTL fires.\n\n```\nprotocols/rendezvous/src/server.rs\n └── Registrations::add() ← no per-peer count check anywhere\n\nprotocols/rendezvous/src/lib.rs\n ├── MAX_NAMESPACE = 255 ← length capped, count is not\n └── MAX_TTL = 72h ← entries persist a long time\n```\n\nfix would be adding something like `max_registrations_per_peer` to `Config` and checking it at the top of `add()` before inserting anything.\n\n\n\n### PoC\n\ntested on `libp2p v0.56.1`, built from source.\n\n**step 1** - start the rendezvous server (uses the example from the repo):\n```bash\ncargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example\n```\n\n**step 2** - run the flood client (attached as `rzv-flood.rs`):\n```bash\ncargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood\n```\n\nit connects as a single peer and registers 10,000 unique namespaces (`flood-00000000` through `flood-00009999`), chaining each registration on the confirmed `Registered` event from the previous one.\n\nserver accepted every single one. not one rejection.\n\nmemory on the server side (via `ps aux` RSS column):\n\n```\nbaseline: ~18 MB\nmid flood: ~26 MB \nafter 10k regs: ~28 MB\n```\n\nthat's from one peer. scale to 100 sybil peers doing the same thing and you're looking at ~1GB. 1000 peers and the server is dead.\n\n<img width=\"1032\" height=\"124\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f778f179-2aa1-4485-940c-25e218733fa8\" />\n\n*server RSS climbing during the flood*\n\n<img width=\"553\" height=\"760\" alt=\"image\" src=\"https://github.com/user-attachments/assets/691b0f52-dda0-443f-a3c2-98c8c6336f2f\" />\n\n*10,000 registrations confirmed, zero rejected*\n\n\n\n### Impact\n\nany node running libp2p-rendezvous server-side is affected. rendezvous servers are typically well-known, publicly reachable nodes taking one down disrupts peer discovery for all clients depending on it. any rust-libp2p based project that deploys a rendezvous point is at risk.\n\nno special position on the network needed. no crypto work. just open a connection and send REGISTER in a loop.\n\n## **Researchers**\n\n**Discovered by:**\n- Ramesh Adhikari (CoE-CNDS Lab, VJTI, Mumbai, India)\n- Dr. Faruk Kazi (CoE-CNDS Lab, VJTI, Mumbai, India)\n\n\n\n**Organization:** Centre of Excellence in Complex & Nonlinear Dynamical Systems (CoE-CNDS Lab), Veermata Jijabai Technological Institute (VJTI), Mumbai, India\n\n---\n\nWe have not disclosed this to any other vendor or made it public. We are reporting directly to the [rust-libp2p](https://github.com/libp2p/rust-libp2p) security team through this advisory.","affected":[{"package":{"name":"libp2p-rendezvous","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-rendezvous"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.17.1"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-cqfx-gf56-8x59/GHSA-cqfx-gf56-8x59.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-cqfx-gf56-8x59"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-35405"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-770"],"github_reviewed":true,"github_reviewed_at":"2026-04-04T06:33:46Z","nvd_pLine truncated
|
||||
{"schema_version":"1.9.0","id":"GHSA-cqfx-gf56-8x59","published":"2026-04-04T06:33:46Z","modified":"2026-11-13T12:55:58.239822452Z","aliases":["CVE-2026-35405","RUSTSEC-2026-0526"],"summary":"libp2p-rendezvous: Unlimited namespace registrations per peer enables OOM DoS on rendezvous servers","details":"### Summary\nfound that `libp2p-rendezvous` server has no limit on how many namespaces a single peer can register. a malicious peer can just keep registering unique namespaces in a loop and the server happily accepts every single one allocating memory for each registration with no pushback. keep doing this long enough (or with multiple sybil peers) and the server process gets OOM killed.\n\nno auth required. any peer on the network can do this.\n\n\n\n### Details\n\nthe bug is in `Registrations::add()` inside `protocols/rendezvous/src/server.rs`.\n\nthe store uses a BiMap keyed on `(PeerId, Namespace)` so yes, a peer can't register the *same* namespace twice. but there's nothing stopping it from registering 10,000 *different* namespaces. each unique one gets its own entry in:\n\n- `registrations_for_peer` (BiMap)\n- `registrations` (HashMap)\n- `next_expiry` (FuturesUnordered a new heap-allocated BoxFuture per registration)\n\nnamespace strings are only validated for length (`MAX_NAMESPACE = 255`), not count. there's no `max_registrations_per_peer` anywhere in `Config` or the rest of the codebase.\n\nmaking it worse `MAX_TTL = 72 hours`. so every registration just sits there for up to 3 days. disconnecting doesn't clean anything up either, entries only go away when the TTL fires.\n\n```\nprotocols/rendezvous/src/server.rs\n └── Registrations::add() ← no per-peer count check anywhere\n\nprotocols/rendezvous/src/lib.rs\n ├── MAX_NAMESPACE = 255 ← length capped, count is not\n └── MAX_TTL = 72h ← entries persist a long time\n```\n\nfix would be adding something like `max_registrations_per_peer` to `Config` and checking it at the top of `add()` before inserting anything.\n\n\n\n### PoC\n\ntested on `libp2p v0.56.1`, built from source.\n\n**step 1** - start the rendezvous server (uses the example from the repo):\n```bash\ncargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example\n```\n\n**step 2** - run the flood client (attached as `rzv-flood.rs`):\n```bash\ncargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood\n```\n\nit connects as a single peer and registers 10,000 unique namespaces (`flood-00000000` through `flood-00009999`), chaining each registration on the confirmed `Registered` event from the previous one.\n\nserver accepted every single one. not one rejection.\n\nmemory on the server side (via `ps aux` RSS column):\n\n```\nbaseline: ~18 MB\nmid flood: ~26 MB \nafter 10k regs: ~28 MB\n```\n\nthat's from one peer. scale to 100 sybil peers doing the same thing and you're looking at ~1GB. 1000 peers and the server is dead.\n\n<img width=\"1032\" height=\"124\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f778f179-2aa1-4485-940c-25e218733fa8\" />\n\n*server RSS climbing during the flood*\n\n<img width=\"553\" height=\"760\" alt=\"image\" src=\"https://github.com/user-attachments/assets/691b0f52-dda0-443f-a3c2-98c8c6336f2f\" />\n\n*10,000 registrations confirmed, zero rejected*\n\n\n\n### Impact\n\nany node running libp2p-rendezvous server-side is affected. rendezvous servers are typically well-known, publicly reachable nodes taking one down disrupts peer discovery for all clients depending on it. any rust-libp2p based project that deploys a rendezvous point is at risk.\n\nno special position on the network needed. no crypto work. just open a connection and send REGISTER in a loop.\n\n## **Researchers**\n\n**Discovered by:**\n- Ramesh Adhikari (CoE-CNDS Lab, VJTI, Mumbai, India)\n- Dr. Faruk Kazi (CoE-CNDS Lab, VJTI, Mumbai, India)\n\n\n\n**Organization:** Centre of Excellence in Complex & Nonlinear Dynamical Systems (CoE-CNDS Lab), Veermata Jijabai Technological Institute (VJTI), Mumbai, India\n\n---\n\nWe have not disclosed this to any other vendor or made it public. We are reporting directly to the [rust-libp2p](https://github.com/libp2p/rust-libp2p) security team through this advisory.","affected":[{"package":{"name":"libp2p-rendezvous","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-rendezvous"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.17.1"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-cqfx-gf56-8x59/GHSA-cqfx-gf56-8x59.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-cqfx-gf56-8x59"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-35405"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-770"],"github_reviewed":true,"github_reviewed_at":"2026-04-Line truncated
|
||||
@@ -1 +1 @@
|
||||
{"schema_version":"1.9.0","id":"GHSA-gc42-3jg7-rxr2","published":"2026-03-18T19:54:12Z","modified":"2026-03-20T21:34:48.742824Z","aliases":["CVE-2026-33040"],"summary":"Gossipsub PRUNE.backoff Duration Overflow","details":"### Summary\nThe Rust libp2p Gossipsub implementation accepts attacker-controlled PRUNE backoff values and may perform unchecked time arithmetic when storing backoff state.\nA specially crafted PRUNE control message with an extremely large backoff (e.g. u64::MAX) can lead to Duration/Instant overflow during backoff update logic, triggering a panic in the networking state machine. This is remotely reachable over a normal libp2p connection and does not require authentication.\n\n### Attack Scenario\nAn attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending a single crafted PRUNE control message:\n1. Establish a standard libp2p transport session and negotiate a stream multiplexer.\n2. Open a Gossipsub stream and negotiate the meshsub protocol.\n3. Send one protobuf RPC containing ControlPrune with a very large backoff value (e.g. 18446744073709551615 / u64::MAX).\nWhen processed, the oversized backoff can reach time-update logic that adds Duration::from_secs(backoff) to Instant::now(), causing overflow and panic.\n\n### Impact\nRemote unauthenticated denial of service.\nAny application exposing a libp2p Gossipsub listener and using the affected backoff-handling path can be crashed by a network attacker that can reach the service port. The attack can be repeated by reconnecting and replaying the crafted control message.\n### Patches\nUsers should upgrade to a release that hardens Gossipsub backoff handling.\n\nThis vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.49.3"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/03/GHSA-gc42-3jg7-rxr2/GHSA-gc42-3jg7-rxr2.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-gc42-3jg7-rxr2"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-33040"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-190"],"github_reviewed":true,"github_reviewed_at":"2026-03-18T19:54:12Z","nvd_published_at":"2026-03-20T06:16:12Z","severity":"HIGH"},"severity":[{"type":"CVSS_V4","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"}]}
|
||||
{"schema_version":"1.9.0","id":"GHSA-gc42-3jg7-rxr2","published":"2026-03-18T19:54:12Z","modified":"2026-11-13T12:56:06.349370229Z","aliases":["CVE-2026-33040","RUSTSEC-2026-0535"],"summary":"Gossipsub PRUNE.backoff Duration Overflow","details":"### Summary\nThe Rust libp2p Gossipsub implementation accepts attacker-controlled PRUNE backoff values and may perform unchecked time arithmetic when storing backoff state.\nA specially crafted PRUNE control message with an extremely large backoff (e.g. u64::MAX) can lead to Duration/Instant overflow during backoff update logic, triggering a panic in the networking state machine. This is remotely reachable over a normal libp2p connection and does not require authentication.\n\n### Attack Scenario\nAn attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending a single crafted PRUNE control message:\n1. Establish a standard libp2p transport session and negotiate a stream multiplexer.\n2. Open a Gossipsub stream and negotiate the meshsub protocol.\n3. Send one protobuf RPC containing ControlPrune with a very large backoff value (e.g. 18446744073709551615 / u64::MAX).\nWhen processed, the oversized backoff can reach time-update logic that adds Duration::from_secs(backoff) to Instant::now(), causing overflow and panic.\n\n### Impact\nRemote unauthenticated denial of service.\nAny application exposing a libp2p Gossipsub listener and using the affected backoff-handling path can be crashed by a network attacker that can reach the service port. The attack can be repeated by reconnecting and replaying the crafted control message.\n### Patches\nUsers should upgrade to a release that hardens Gossipsub backoff handling.\n\nThis vulnerability was originally submitted by @revofusion to the Ethereum Foundation bug bounty program","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.49.3"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/03/GHSA-gc42-3jg7-rxr2/GHSA-gc42-3jg7-rxr2.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-gc42-3jg7-rxr2"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-33040"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-190"],"github_reviewed":true,"github_reviewed_at":"2026-03-18T19:54:12Z","nvd_published_at":"2026-03-20T06:16:12Z","severity":"HIGH"},"severity":[{"type":"CVSS_V4","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"}]}
|
||||
@@ -1 +1 @@
|
||||
{"schema_version":"1.9.0","id":"GHSA-v5hw-cv9c-rpg7","published":"2026-04-04T06:34:29Z","modified":"2026-04-07T20:21:43.969674Z","aliases":["CVE-2026-35457"],"summary":"libp2p-rendezvous: Unbounded rendezvous DISCOVER cookies enable remote memory exhaustion","details":"### Summary\nThe rendezvous server stores pagination cookies without bounds. An unauthenticated peer can repeatedly issue `DISCOVER` requests and force unbounded memory growth.\n\n### Details\n\nPagination state is stored in:\n\n```rs\nHashMap<Cookie, HashSet<RegistrationId>>\n```\n\nOn `Message::Discover`:\n\n```\nremote peer\n→ DISCOVER\n→ handle_request\n→ registrations.get(...)\n→ new cookie generated\n→ cookie inserted into Registrations::cookies\n```\n\nThere is **no upper bound or eviction policy**, so repeated DISCOVER requests grow this map indefinitely.\n\n\n### PoC\nA reproduction test and minimal harness will be provided in a private fork in a follow-up comment.\n\n### Impact\n\n**Remote state amplification leading to memory exhaustion.**\n\n\nProperties:\n\n- etwork reachable\n- no authentication required\n- low attack complexity\n- protocol-compliant traffic\n\nImpacts rendezvous nodes exposed to untrusted peers.\n---\n\n### Possible Fixes\n\n1. **Global cap + eviction**\n\nBound cookie storage (`MAX_COOKIES_TRACKED`) with FIFO/expiry aware eviction. \nTradeoff: attacker can churn cookies and evict legitimate pagination state.\n\n2. **Stateless cookies**\n\nEncode pagination state in authenticated cookies instead of storing server-side state. \nTradeoff: more complex implementation.\n\n3. **Rate limiting / per-peer quotas**\n\nLimit cookie creation per peer. \nTradeoff: requires peer tracking.","affected":[{"package":{"name":"libp2p-rendezvous","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-rendezvous"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.17.1"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-v5hw-cv9c-rpg7/GHSA-v5hw-cv9c-rpg7.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-v5hw-cv9c-rpg7"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-35457"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-770"],"github_reviewed":true,"github_reviewed_at":"2026-04-04T06:34:29Z","nvd_published_at":"2026-04-07T15:17:43Z","severity":"HIGH"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H"}]}
|
||||
{"schema_version":"1.9.0","id":"GHSA-v5hw-cv9c-rpg7","published":"2026-04-04T06:34:29Z","modified":"2026-11-13T12:55:33.337873475Z","aliases":["CVE-2026-35457","RUSTSEC-2026-0527"],"summary":"libp2p-rendezvous: Unbounded rendezvous DISCOVER cookies enable remote memory exhaustion","details":"### Summary\nThe rendezvous server stores pagination cookies without bounds. An unauthenticated peer can repeatedly issue `DISCOVER` requests and force unbounded memory growth.\n\n### Details\n\nPagination state is stored in:\n\n```rs\nHashMap<Cookie, HashSet<RegistrationId>>\n```\n\nOn `Message::Discover`:\n\n```\nremote peer\n→ DISCOVER\n→ handle_request\n→ registrations.get(...)\n→ new cookie generated\n→ cookie inserted into Registrations::cookies\n```\n\nThere is **no upper bound or eviction policy**, so repeated DISCOVER requests grow this map indefinitely.\n\n\n### PoC\nA reproduction test and minimal harness will be provided in a private fork in a follow-up comment.\n\n### Impact\n\n**Remote state amplification leading to memory exhaustion.**\n\n\nProperties:\n\n- etwork reachable\n- no authentication required\n- low attack complexity\n- protocol-compliant traffic\n\nImpacts rendezvous nodes exposed to untrusted peers.\n---\n\n### Possible Fixes\n\n1. **Global cap + eviction**\n\nBound cookie storage (`MAX_COOKIES_TRACKED`) with FIFO/expiry aware eviction. \nTradeoff: attacker can churn cookies and evict legitimate pagination state.\n\n2. **Stateless cookies**\n\nEncode pagination state in authenticated cookies instead of storing server-side state. \nTradeoff: more complex implementation.\n\n3. **Rate limiting / per-peer quotas**\n\nLimit cookie creation per peer. \nTradeoff: requires peer tracking.","affected":[{"package":{"name":"libp2p-rendezvous","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-rendezvous"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.17.1"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-v5hw-cv9c-rpg7/GHSA-v5hw-cv9c-rpg7.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-v5hw-cv9c-rpg7"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-35457"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-770"],"github_reviewed":true,"github_reviewed_at":"2026-04-04T06:34:29Z","nvd_published_at":"2026-04-07T15:17:43Z","severity":"HIGH"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H"}]}
|
||||
@@ -1 +1 @@
|
||||
{"schema_version":"1.9.2","id":"GHSA-v653-r55g-hcmg","published":"2026-02-27T09:30:29Z","modified":"2026-11-04T06:45:04.325296987Z","aliases":["CVE-2025-13327","GHSA-pqhf-p39g-3x64","PYSEC-2026-2295"],"summary":"uv has ZIP payload obfuscation through parsing differentials","details":"A flaw was found in uv. This vulnerability allows an attacker to execute malicious code during package resolution or installation via specially crafted ZIP (Zipped Information Package) archives that exploit parsing differentials, requiring user interaction to install an attacker-controlled package.","affected":[{"package":{"name":"uv","ecosystem":"crates.io","purl":"pkg:cargo/uv"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.9.6"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/02/GHSA-v653-r55g-hcmg/GHSA-v653-r55g-hcmg.json"}}],"references":[{"type":"WEB","url":"https://github.com/astral-sh/uv/security/advisories/GHSA-pqhf-p39g-3x64"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-13327"},{"type":"WEB","url":"https://github.com/astral-sh/uv/commit/da659fee4898a73dbc75070f3e82d49f745e4628"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:91219"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:91232"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:91236"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:94459"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:94476"},{"type":"WEB","url":"https://access.redhat.com/security/cve/CVE-2025-13327"},{"type":"WEB","url":"https://bugzilla.redhat.com/show_bug.cgi?id=2407263"},{"type":"PACKAGE","url":"https://github.com/astral-sh/uv"}],"database_specific":{"cwe_ids":["CWE-1286"],"github_reviewed":true,"github_reviewed_at":"2026-03-01T01:03:07Z","nvd_published_at":"2026-02-27T08:17:04Z","severity":"MODERATE"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H"}]}
|
||||
{"schema_version":"1.9.2","id":"GHSA-v653-r55g-hcmg","published":"2026-02-27T09:30:29Z","modified":"2026-11-13T15:45:05.127359529Z","aliases":["CVE-2025-13327","GHSA-pqhf-p39g-3x64","PYSEC-2026-2295"],"summary":"uv has ZIP payload obfuscation through parsing differentials","details":"A flaw was found in uv. This vulnerability allows an attacker to execute malicious code during package resolution or installation via specially crafted ZIP (Zipped Information Package) archives that exploit parsing differentials, requiring user interaction to install an attacker-controlled package.","affected":[{"package":{"name":"uv","ecosystem":"crates.io","purl":"pkg:cargo/uv"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.9.6"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/02/GHSA-v653-r55g-hcmg/GHSA-v653-r55g-hcmg.json"}}],"references":[{"type":"WEB","url":"https://github.com/astral-sh/uv/security/advisories/GHSA-pqhf-p39g-3x64"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-13327"},{"type":"WEB","url":"https://github.com/astral-sh/uv/commit/da659fee4898a73dbc75070f3e82d49f745e4628"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:91219"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:91232"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:91236"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:94459"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:94476"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:96400"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:96403"},{"type":"WEB","url":"https://access.redhat.com/errata/RHSA-2026:96406"},{"type":"WEB","url":"https://access.redhat.com/security/cve/CVE-2025-13327"},{"type":"WEB","url":"https://bugzilla.redhat.com/show_bug.cgi?id=2407263"},{"type":"PACKAGE","url":"https://github.com/astral-sh/uv"}],"database_specific":{"cwe_ids":["CWE-1286"],"github_reviewed":true,"github_reviewed_at":"2026-03-01T01:03:07Z","nvd_published_at":"2026-02-27T08:17:04Z","severity":"MODERATE"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H"}]}
|
||||
@@ -1 +1 @@
|
||||
{"schema_version":"1.9.0","id":"GHSA-xqmp-fxgv-xvq5","published":"2026-03-30T13:04:03Z","modified":"2026-04-06T23:34:56.143916Z","aliases":["CVE-2026-34219"],"summary":"libp2p-gossipsub: Remote crash via unchecked Instant overflow in heartbeat backoff expiry handling","details":"## Description\n### Summary\nThe Rust libp2p Gossipsub implementation contains a remotely reachable panic in `backoff` expiry handling. \nAfter a peer sends a crafted `PRUNE` control message with an attacker-controlled, near-maximum `backoff` value, the value is accepted and stored as an `Instant` near the representable upper bound. On a later heartbeat, the implementation performs unchecked `Instant + Duration` arithmetic (`backoff_time + slack`), which can overflow and panic with:\n`overflow when adding duration to instant`\nThis issue is reachable from any Gossipsub peer over normal `TCP + Noise + mplex/yamux` connectivity and requires no further authentication beyond becoming a protocol peer.\n### Attack Scenario\nAn attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending crafted `PRUNE` control data:\n1. Establish a standard libp2p session (`TCP + Noise`) and negotiate a stream multiplexer (`mplex`/`yamux`).\n2. Open a Gossipsub stream and send an RPC containing `ControlPrune` with a very large `backoff` (chosen near boundary conditions, e.g. `~ i64::MAX - victim_uptime_seconds`; example observed: `9223372036854674580` for ~28h uptime).\n3. The value is parsed from protobuf and passed through `Behaviour::handle_prune()` into mesh/backoff update logic.\n4. Initial storage path uses checked addition (`Instant::now().checked_add(...)`), so the malicious near-max value is retained.\n5. On the next heartbeat (typically within ~43–74s), expiry logic computes `backoff_time + slack` using unchecked addition, which overflows and panics.\n### Impact\nRemote unauthenticated denial of service (critical). \nAny application exposing an affected `libp2p-gossipsub` listener can be crashed by a network-reachable peer that sends crafted `PRUNE` backoff values. The crash is triggered during heartbeat processing (not immediately at PRUNE parse time), and can be repeated by reconnecting and replaying the message.\n\n### Differences from CVE-2026-33040\nThis advisory is related to CVE-2026-33040 but it is not the same defect. CVE-2026-33040 addressed overflow during backoff insertion by adding checked arithmetic when converting PRUNE backoff into an Instant. The issue in this advisory occurs at a different location and at a different time: a near-maximum backoff can still be stored successfully, and the crash happens later in the heartbeat path when slack is added to that stored Instant using unchecked arithmetic. This report covers a distinct secondary overflow path in heartbeat expiry handling that remained reachable after the original insertion-side hardening.\n\nThis vulnerability was originally reported by the Security team of the Ethereum Foundation.","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.49.4"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/03/GHSA-xqmp-fxgv-xvq5/GHSA-xqmp-fxgv-xvq5.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-xqmp-fxgv-xvq5"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34219"},{"type":"ADVISORY","url":"https://github.com/advisories/GHSA-gc42-3jg7-rxr2"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-190","CWE-617"],"github_reviewed":true,"github_reviewed_at":"2026-03-30T13:04:03Z","nvd_published_at":"2026-03-31T16:16:31Z","severity":"HIGH"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"},{"type":"CVSS_V4","score":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"}]}
|
||||
{"schema_version":"1.9.0","id":"GHSA-xqmp-fxgv-xvq5","published":"2026-03-30T13:04:03Z","modified":"2026-11-13T12:55:56.691928632Z","aliases":["CVE-2026-34219","RUSTSEC-2026-0537"],"summary":"libp2p-gossipsub: Remote crash via unchecked Instant overflow in heartbeat backoff expiry handling","details":"## Description\n### Summary\nThe Rust libp2p Gossipsub implementation contains a remotely reachable panic in `backoff` expiry handling. \nAfter a peer sends a crafted `PRUNE` control message with an attacker-controlled, near-maximum `backoff` value, the value is accepted and stored as an `Instant` near the representable upper bound. On a later heartbeat, the implementation performs unchecked `Instant + Duration` arithmetic (`backoff_time + slack`), which can overflow and panic with:\n`overflow when adding duration to instant`\nThis issue is reachable from any Gossipsub peer over normal `TCP + Noise + mplex/yamux` connectivity and requires no further authentication beyond becoming a protocol peer.\n### Attack Scenario\nAn attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending crafted `PRUNE` control data:\n1. Establish a standard libp2p session (`TCP + Noise`) and negotiate a stream multiplexer (`mplex`/`yamux`).\n2. Open a Gossipsub stream and send an RPC containing `ControlPrune` with a very large `backoff` (chosen near boundary conditions, e.g. `~ i64::MAX - victim_uptime_seconds`; example observed: `9223372036854674580` for ~28h uptime).\n3. The value is parsed from protobuf and passed through `Behaviour::handle_prune()` into mesh/backoff update logic.\n4. Initial storage path uses checked addition (`Instant::now().checked_add(...)`), so the malicious near-max value is retained.\n5. On the next heartbeat (typically within ~43–74s), expiry logic computes `backoff_time + slack` using unchecked addition, which overflows and panics.\n### Impact\nRemote unauthenticated denial of service (critical). \nAny application exposing an affected `libp2p-gossipsub` listener can be crashed by a network-reachable peer that sends crafted `PRUNE` backoff values. The crash is triggered during heartbeat processing (not immediately at PRUNE parse time), and can be repeated by reconnecting and replaying the message.\n\n### Differences from CVE-2026-33040\nThis advisory is related to CVE-2026-33040 but it is not the same defect. CVE-2026-33040 addressed overflow during backoff insertion by adding checked arithmetic when converting PRUNE backoff into an Instant. The issue in this advisory occurs at a different location and at a different time: a near-maximum backoff can still be stored successfully, and the crash happens later in the heartbeat path when slack is added to that stored Instant using unchecked arithmetic. This report covers a distinct secondary overflow path in heartbeat expiry handling that remained reachable after the original insertion-side hardening.\n\nThis vulnerability was originally reported by the Security team of the Ethereum Foundation.","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.49.4"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/03/GHSA-xqmp-fxgv-xvq5/GHSA-xqmp-fxgv-xvq5.json"}}],"references":[{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-xqmp-fxgv-xvq5"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34219"},{"type":"ADVISORY","url":"https://github.com/advisories/GHSA-gc42-3jg7-rxr2"},{"type":"PACKAGE","url":"https://github.com/libp2p/rust-libp2p"}],"database_specific":{"cwe_ids":["CWE-190","CWE-617"],"github_reviewed":true,"github_reviewed_at":"2026-03-30T13:04:03Z","nvd_published_at":"2026-03-31T16:16:31Z","severity":"HIGH"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"},{"type":"CVSS_V4","score":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"}]}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0523","published":"2026-09-30T12:00:00Z","modified":"2026-11-13T12:45:04.789912316Z","aliases":["GHSA-53rm-773f-4q8c"],"summary":"MAX_STREAM_DATA frame can open streams beyond the stream limit","details":"When a MAX_STREAM_DATA frame named a peer-initiated bidirectional stream that was not open yet, `received_max_stream_data` treated the stream, and every lower-numbered stream, as opened without checking the stream ID against the limit advertised to the peer. RFC 9000 section 4.6 requires closing the connection with `STREAM_LIMIT_ERROR` in this case, and the STREAM and RESET_STREAM handlers already did so.\n\nAfter the handshake, a peer can send one small MAX_STREAM_DATA frame naming a very large stream index, and `accept` then yields every stream up to that index. In `quinn`, a loop that keeps calling `accept_bi` can be handed more than 2^40 streams. Depending on the runtime, the endpoint runs out of memory, stops accepting new connections, or keeps busy indefinitely, even after the peer has gone away. Clients and servers that accept peer-initiated bidirectional streams are affected. Unidirectional streams are not.\n\nThe fix validates the stream ID in `received_max_stream_data` and adds a defensive check where streams are opened implicitly. It is in 0.11.19.","affected":[{"package":{"name":"quinn-proto","ecosystem":"crates.io","purl":"pkg:cargo/quinn-proto"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.11.0"},{"fixed":"0.11.19"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0523.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/quinn-proto"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0523.html"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/3eb7465d9e11d7a245e99cde1a4eb872ec26d264"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/73114d8289d42bd536c790fa00a9beed05a4e5fa"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0524","published":"2026-09-30T12:00:00Z","modified":"2026-11-13T12:45:06.127108520Z","aliases":["GHSA-wppq-2f6r-wfvm"],"summary":"Long Retry token can panic or exhaust memory in a QUIC client","details":"A client kept the token from a Retry packet without any length limit and put it into the header of every Initial packet it sent afterwards. Initial datagrams are 1200 bytes. When the token and connection IDs left no room for the minimum payload, `PacketBuilder::new` computed a minimum packet size larger than the maximum, which only a debug assertion checked. On the next `poll_transmit`, debug builds panic, and release builds try to allocate more than 10 GiB in one call. With longer tokens the allocation fails and the process aborts.\n\nA matching Retry packet can be built from the client's first Initial alone. The attacker can therefore be the server being contacted, or anyone who sees that Initial and can answer before the server does. Every application that makes outgoing connections with `quinn-proto` is affected, including all `quinn` clients. Servers do not process Retry packets.\n\nThe fix closes the connection with `PROTOCOL_VIOLATION` when an Initial token leaves too little room for frames. That covers Retry tokens and cached address-validation tokens, since both come from the peer. It also reserves room for CONNECTION_CLOSE after large Initial headers. Both changes are in 0.11.19.","affected":[{"package":{"name":"quinn-proto","ecosystem":"crates.io","purl":"pkg:cargo/quinn-proto"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.11.0"},{"fixed":"0.11.19"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0524.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/quinn-proto"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0524.html"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/3bba467893ceff64d6cda0b3a2c51a1429e10372"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/d45b5136ed1d5b2b04ff6456443c0662acf1d0d3"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/74c33ff75281d7751488e410e21e4f030782b655"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/a6e78d1c8bf28630f1e92fbcc38f60e0a134b01a"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0525","published":"2026-07-10T12:00:00Z","modified":"2026-11-13T12:45:06.635369072Z","aliases":["CVE-2026-61544","GHSA-5hq8-qhww-jm7q"],"summary":"Remote panic when a peer certificate expires during the QUIC handshake","details":"After the QUIC handshake finished, the peer's libp2p TLS certificate was parsed a second time to get its peer ID, and the result was unwrapped with `expect`, on the assumption that it could not fail because the certificate had already been validated. Parsing checks the certificate's validity period again against the current time. A remote peer can present a certificate that is about to expire and delay the end of the handshake until it has expired, so the second parse fails and the process panics. No authentication is needed; any application with a reachable QUIC listener is affected.\n\nThe fix returns a connection error instead of panicking when the peer identity or certificate cannot be read after the handshake. It is in 0.13.1, and was backported to the main branch in libp2p/rust-libp2p#6525 for 0.14.0.","affected":[{"package":{"name":"libp2p-quic","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-quic"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.13.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0525.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-quic"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0525.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/212f3774af048e2cecfb2e6b1e08477685e52b22"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/pull/6525"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0526","published":"2026-04-02T12:00:00Z","modified":"2026-11-13T12:45:06.633405487Z","aliases":["CVE-2026-35405","GHSA-cqfx-gf56-8x59"],"summary":"Rendezvous server accepted unlimited registrations per peer","details":"The rendezvous server's registration store did not limit how many namespaces a single peer could register, or how many registrations it held in total. Each registration stays until its TTL expires, up to 72 hours, and is not removed when the peer disconnects. An unauthenticated peer can send REGISTER requests for new namespaces in a loop, and many peers together can exhaust the server's memory, cutting off discovery for every client that relies on it.\n\nThe fix adds limits on registrations per peer (32 by default) and in total (10,000 by default), configurable through `Config`, and answers requests over the limit with an `Unavailable` error. It is in 0.17.1.","affected":[{"package":{"name":"libp2p-rendezvous","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-rendezvous"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.17.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0526.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-rendezvous"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0526.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/8fde2dc0fae8b433f97c6cdf9ee24f59d51a359c"}],"database_specific":{"license":"CC0-1.0"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"}]}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0527","published":"2026-04-02T12:00:00Z","modified":"2026-11-13T12:45:06.396596735Z","aliases":["CVE-2026-35457","GHSA-v5hw-cv9c-rpg7"],"summary":"Rendezvous server stored an unlimited number of DISCOVER cookies","details":"Each DISCOVER request to a rendezvous server creates a pagination cookie, which the server kept in a map together with the registrations already returned for it. Entries were never evicted or capped, so an unauthenticated peer sending ordinary DISCOVER requests can make the server's memory grow without bound.\n\nThe fix keeps cookies in a fixed-size LRU cache (10,000 entries by default, configurable through `Config`). It is in 0.17.1.","affected":[{"package":{"name":"libp2p-rendezvous","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-rendezvous"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.17.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H","informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0527.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-rendezvous"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0527.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/8fde2dc0fae8b433f97c6cdf9ee24f59d51a359c"}],"database_specific":{"license":"CC0-1.0"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H"}]}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0528","published":"2026-11-12T12:00:00Z","modified":"2026-11-13T12:45:06.399026502Z","summary":"UB can be reached from safe code","details":"The variance of `RefSwap` and `OptionRefSwap` were incorrect, possibly allowing use-after-free.\n\n`OptionRefSwap::into_inner` did not check for null.\n\nThe fix is to make `RefSwap` and `OptionRefSwap` invariant, and to change `OptionRefSwap::into_inner` to return an option.\nIt is available in version 0.1.3.\nIf your project still compiles with 0.1.3 then it is not affected by the unsoundness on version 0.1.2","affected":[{"package":{"name":"ref-swap","ecosystem":"crates.io","purl":"pkg:cargo/ref-swap"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.1.3"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["memory-corruption"],"cvss":null,"informational":"unsound","source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0528.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/ref-swap"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0528.html"},{"type":"WEB","url":"https://github.com/Nitrokey/ref-swap/releases/tag/v0.1.3"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0529","published":"2026-11-13T12:00:00Z","modified":"2026-11-13T12:45:06.795392066Z","aliases":["GHSA-mj2m-jxgv-r446"],"summary":"KVStoreInterpreter::verify_signature_legacy answers true for every token and every key","details":"`KVStoreInterpreter::verify_signature_legacy(&PushDrop, &PublicKey)`, public\nand deprecated since 0.2.0 (the crate's first release), read neither argument\nand answered `true`. A KVStore token signed by nobody, a signed token checked\nagainst a key other than its controller's, and a PushDrop with no fields each\npassed. Its documentation said it delegated to the `KVStoreFields`-based\nverifier; it did not.\n\nAn application that checks, with this function, a KVStore token it did not\nwrite (an overlay lookup's answer, or a transaction output a peer hands it) and\nacts on `true` accepts a value no controller signed, attributed to whatever\ncontroller the token names. No caller in the crate itself uses the function.\nThis was run on 0.2.0, 0.5.0, 0.8.0, 0.8.7, 0.8.8, 0.9.0-beta.1 and\n0.9.0-beta.7 as crates.io serves them, and the source of all 63 published\nversions carries the same constant body (the yanked 0.3.21 included).\n\n0.8.9 answers `true` only for a token whose controller field is the\ngiven key and whose last field is that key's signature over the others (the\n0.9 line's next prerelease carries the same fix). There is no workaround:\nupgrade to 0.8.9, or, on the 0.9 line, to its next prerelease.","affected":[{"package":{"name":"bsv-rs","ecosystem":"crates.io","purl":"pkg:cargo/bsv-rs"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.8.9"},{"introduced":"0.9.0-beta.1"},{"fixed":"0.9.0-beta.7.0"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":["bsv_rs::kvstore::KVStoreInterpreter::verify_signature_legacy"],"os":[]}},"database_specific":{"categories":["crypto-failure"],"cvss":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0529.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/bsv-rs"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0529.html"},{"type":"WEB","url":"https://github.com/Calhooon/bsv-rs/blob/v0.8.9/CHANGELOG.md"}],"database_specific":{"license":"CC0-1.0"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N"}]}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0530","published":"2026-09-03T12:00:00Z","modified":"2026-11-13T12:55:36.653610929Z","aliases":["CVE-2026-123596","GHSA-3r6v-f3jh-vvqm","RUSTSEC-2026-0539"],"summary":"Parent-side NSEC at a zone cut accepted as proof of nonexistence (hickory-proto)","details":"Up to 0.26.0-alpha.1, hickory-proto's DNSSEC validation accepted the NSEC record that a parent zone signs at a delegation as proof that names below the zone cut, or other types at the cut, do not exist. Such a record only proves that no DS record exists there (RFC 6840 section 4.1). Someone who can answer or modify DNS responses could replay the parent's genuine signed records to get a denial for an existing name in the child zone accepted as secure.\n\nFrom 0.26.0-beta.1 the DNSSEC validation code lives in the hickory-net crate, where this was fixed in hickory-net 0.26.2. No hickory-proto release contains a fix. Users of DNSSEC validation in older hickory-proto releases (directly or through hickory-resolver or hickory-recursor) should move to the 0.26.2 or later releases, which validate through hickory-net.","affected":[{"package":{"name":"hickory-proto","ecosystem":"crates.io","purl":"pkg:cargo/hickory-proto"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.26.0-beta.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["privilege-escalation"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0530.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/hickory-proto"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0530.html"},{"type":"WEB","url":"https://github.com/hickory-dns/hickory-dns/commit/2e3c829ea45000b1c409a64a03bd422618372471"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0531","published":"2026-09-03T12:00:00Z","modified":"2026-11-13T12:55:54.316294846Z","aliases":["CVE-2026-123591","GHSA-7php-9j59-g3ch","RUSTSEC-2026-0540"],"summary":"Child-side NSEC or NSEC3 record accepted as proof that a delegation has no DS record (hickory-proto)","details":"Up to 0.26.0-alpha.1, hickory-proto's DNSSEC validation accepted an NSEC or NSEC3 record from the child side of a zone cut, which has the SOA bit set, as proof that the parent has no DS record for the delegation (RFC 4035 section 5.2, RFC 6840 section 4.4). Someone who can answer or modify DNS responses could make a secure delegation look insecure and then forge records in the child zone.\n\nFrom 0.26.0-beta.1 the DNSSEC validation code lives in the hickory-net crate, where this was fixed in hickory-net 0.26.2. No hickory-proto release contains a fix. Users of DNSSEC validation in older hickory-proto releases (directly or through hickory-resolver or hickory-recursor) should move to the 0.26.2 or later releases, which validate through hickory-net.","affected":[{"package":{"name":"hickory-proto","ecosystem":"crates.io","purl":"pkg:cargo/hickory-proto"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.26.0-beta.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["privilege-escalation"],"cvss":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0531.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/hickory-proto"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0531.html"},{"type":"WEB","url":"https://github.com/hickory-dns/hickory-dns/commit/ec98851f4d175d97b61701bc539523ff63ddbb00"}],"database_specific":{"license":"CC0-1.0"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"}]}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0532","published":"2026-09-03T12:00:00Z","modified":"2026-11-13T12:55:46.260287377Z","aliases":["CVE-2026-123595","GHSA-624w-vvww-xvpw","RUSTSEC-2026-0541"],"summary":"Parent-side NSEC3 at a zone cut accepted as proof of nonexistence (hickory-proto 0.25)","details":"In hickory-proto 0.25.0 through 0.26.0-alpha.1, NSEC3 validation picked the closest encloser by hashed owner name alone and accepted the NSEC3 record that a parent zone signs at a delegation as proof that names at or below the zone cut do not exist. Such a record only proves that no DS record exists there (RFC 6840 section 4.1, RFC 5155 section 8.3). Someone who can answer or modify DNS responses could replay the parent's genuine signed records to get a denial for an existing name in the child zone accepted as secure.\n\nFrom 0.26.0-beta.1 the DNSSEC validation code lives in the hickory-net crate, where this was fixed in hickory-net 0.26.2. No hickory-proto release contains a fix. Users of DNSSEC validation in hickory-proto 0.25 (directly or through hickory-resolver or hickory-recursor 0.25) should move to the 0.26.2 or later releases, which validate through hickory-net.","affected":[{"package":{"name":"hickory-proto","ecosystem":"crates.io","purl":"pkg:cargo/hickory-proto"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.25.0"},{"fixed":"0.26.0-beta.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["privilege-escalation"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0532.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/hickory-proto"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0532.html"},{"type":"WEB","url":"https://github.com/hickory-dns/hickory-dns/commit/889801333d7f18d59a4468100e8cd1859e083d43"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0533","published":"2026-11-12T12:00:00Z","modified":"2026-11-13T12:45:09.009911487Z","aliases":["GHSA-934p-vp7m-gx3c"],"summary":"Incorrect handling of embedded SVG and MathML leads to mutation XSS","details":"The MathML text integration points (`mi`, `mo`, `mn`, `ms`, `mtext`) and SVG `foreignObject` can be made to contain a tag in the other one's namespace (a MathML integration point with a child in the SVG namespace, or vice versa) without the root tag that switches out of the HTML namespace. If the attacker can construct input that parses differently in as HTML than as foreign XML, they can inject arbitrary JavaScript code into the user's browser.\n\nFor example:\n\n- The user writes `<math><mi><svg><gadget></svg></mi></math>`.\n- The application enables `math`, `mi`, and the gadget, but not `svg`.\n- Ammonia filters the input to `<math><mi><gadget></mi></math>`.\n- Because svg is now gone, the gadget switches from being parsed as SVG to being parsed as HTML.\n- The gadget is written in such a way that it exploits the parsing differences between HTML and MathML.\n\nAs far as we know, the gadget can only be written using a tag that is parsed as raw text in HTML. These [elements] are:\n\n- title\n- textarea\n- xmp\n- iframe\n- noembed\n- noframes\n- plaintext\n- noscript\n- style\n- script\n\nApplications that do not explicitly allow any of these tags should not be affected, since none are allowed by default.\n\n[elements]: https://github.com/servo/html5ever/blob/a027c2835472d518893c906dc29c42200af3c960/html5ever/src/tree_builder/rules.rs\n\n---\n\nThis vulnerability was reported by Roger Meyer.","affected":[{"package":{"name":"ammonia","ecosystem":"crates.io","purl":"pkg:cargo/ammonia"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"3.3.5"},{"introduced":"4.0.0"},{"fixed":"4.1.9"},{"introduced":"4.2.0"},{"fixed":"4.2.5"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["format-injection"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0533.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/ammonia"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0533.html"},{"type":"WEB","url":"https://github.com/rust-ammonia/ammonia/pull/269"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0534","published":"2026-10-19T12:00:00Z","modified":"2026-11-13T12:45:07.339789114Z","aliases":["GHSA-vrx6-jcp8-vm7m"],"summary":"Unbounded backoff state from PRUNE messages for unknown topics","details":"A PRUNE control message names topics and asks for a backoff on each. The handler recorded a backoff for every named topic, including topics the local node had never joined. A peer can send PRUNEs naming many new short topic IDs with a long backoff. Each pair is kept until the backoff expires, up to an hour, even after the peer disconnects, so a stream of PRUNEs, possibly from many peer IDs, can use up the node's memory. Peer scoring does not penalise these messages.\n\nThe fix ignores PRUNE entries for topics that are not in the node's mesh. It is in 0.50.1, and was backported to the main branch in libp2p/rust-libp2p#6707.","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.50.1"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0534.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-gossipsub"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0534.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/9c647828abea0dfc0b4e827dff1e176ec8b44752"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/pull/6707"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0535","published":"2026-03-18T12:00:00Z","modified":"2026-11-13T12:45:08.544187115Z","aliases":["CVE-2026-33040","GHSA-gc42-3jg7-rxr2"],"summary":"Remote panic from an oversized PRUNE backoff","details":"When a peer sent a PRUNE control message, the backoff it asked for was turned into an expiry time with `Instant::now() + Duration::from_secs(backoff)`. That addition panics on overflow, so a peer that sends a PRUNE with a very large backoff, such as `u64::MAX`, crashes the node. No authentication is needed beyond an ordinary libp2p connection with the gossipsub protocol, and the attacker can repeat it after every restart.\n\nThe fix uses `Instant::checked_add` in `BackoffStorage::update_backoff` and ignores a backoff that would overflow. It is in 0.49.3.","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.49.3"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0535.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-gossipsub"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0535.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/84153a559bdbcb92a48413dd2a31035800cb882d"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0536","published":"2026-09-05T12:00:00Z","modified":"2026-11-13T12:45:02.747808849Z","aliases":["CVE-2026-95859","GHSA-g3g5-x568-qvqx"],"summary":"Unbounded memory growth from GRAFT messages for unsubscribed topics","details":"When a GRAFT control message arrived, every topic it named was added to that peer's set of topics, on the assumption that a peer grafting us must be subscribed. Nothing checked that the peer had subscribed, and subscription filters only apply to SUBSCRIBE messages. A peer can keep sending GRAFTs with new short topic IDs over one connection, and the set grows until the peer unsubscribes or disconnects. Memory grows without bound and the node can be killed for running out of memory.\n\nThe fix no longer records topics from GRAFT messages and drops a GRAFT for a topic the peer has not subscribed to. It also makes `MaxCountSubscriptionFilter` the default subscription filter. It is in 0.49.5, and was backported to the 0.50 line before 0.50.0.","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.49.5"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0536.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-gossipsub"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0536.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/51ed5f00e1b0620ded3444ecadf18477052148ea"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/pull/6608"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0537","published":"2026-03-27T12:00:00Z","modified":"2026-11-13T12:45:07.345999345Z","aliases":["CVE-2026-34219","GHSA-xqmp-fxgv-xvq5"],"summary":"Remote panic in the heartbeat from a large PRUNE backoff","details":"The 0.49.3 fix stopped an overflow when a PRUNE backoff is first stored, but a backoff just small enough to be stored could still overflow later. On each heartbeat, expired backoffs were found with `backoff_time + slack > now`, which panics when the stored time is close to the largest `Instant`. A peer that sends one PRUNE with such a backoff crashes the node a heartbeat or so later, and can repeat it after every restart.\n\nThe fix caps a remote PRUNE backoff at one hour, uses `checked_add` for the heartbeat comparison, and replaces other unchecked time arithmetic in the behaviour, peer scoring and time cache with checked or saturating operations. It is in 0.49.4.","affected":[{"package":{"name":"libp2p-gossipsub","ecosystem":"crates.io","purl":"pkg:cargo/libp2p-gossipsub"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.49.4"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0537.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/libp2p-gossipsub"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0537.html"},{"type":"WEB","url":"https://github.com/libp2p/rust-libp2p/commit/55e4a64630f66d55fec5955c8f9905413c5d0859"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0538","published":"2026-09-30T12:00:00Z","modified":"2026-11-13T12:45:08.844283231Z","aliases":["GHSA-6pp4-4cxf-xf88"],"summary":"Receive loop can spin after a truncated datagram","details":"Some targets read one datagram per `recvmsg` call instead of using `recvmmsg`: Apple platforms without the `fast-apple-datapath` feature, OpenBSD, NetBSD, Solaris and illumos, and from 0.6 also DragonFly BSD, Redox and GNU/Hurd. On these targets the receive loop set up its `msghdr` only once and looked at the `MSG_TRUNC` flag before checking whether `recvmsg` had failed. After a datagram larger than the receive buffer was dropped, a following `EAGAIN` still saw the old truncation flag. The loop then kept issuing non-blocking receives instead of returning `WouldBlock`.\n\nWhen the receive buffer is smaller than a datagram that arrives, a remote sender can keep the task that drives the socket busy, before any QUIC packet authentication. The loop ends only when a later datagram fits in the buffer. Whether an application is exposed therefore depends on the receive buffer size it uses. Linux, Android, FreeBSD and Windows use other receive paths and are not affected.\n\nThe fix rebuilds the header before every `recvmsg` call and returns receive errors before checking the truncation flag. It is in 0.5.16 and 0.6.3.","affected":[{"package":{"name":"quinn-udp","ecosystem":"crates.io","purl":"pkg:cargo/quinn-udp"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.5.16"},{"introduced":"0.6.0"},{"fixed":"0.6.3"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["denial-of-service"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0538.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/quinn-udp"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0538.html"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/462865a6c33039c26076f7077c7cd7e2f997b9cd"},{"type":"WEB","url":"https://github.com/quinn-rs/quinn/commit/6862d3dcc9a9333fc4160481b3e5e5d154d4dd36"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0539","published":"2026-09-03T12:00:00Z","modified":"2026-11-13T12:55:36.653610929Z","aliases":["CVE-2026-123596","GHSA-3r6v-f3jh-vvqm","RUSTSEC-2026-0530"],"summary":"Parent-side NSEC at a zone cut accepted as proof of nonexistence below the cut","details":"At a delegation, the parent zone signs an NSEC record for the child's name whose type bitmap has NS but not SOA (or has DNAME). RFC 6840 section 4.1 says such a record only proves that no DS record exists at that name. It says nothing about names below the cut or about other types at the cut, because those belong to the child zone.\n\nDNSSEC validation did not make this distinction. It used such a record as a covering NSEC for names below the cut, and as a direct match proving that other types did not exist at the cut. An attacker who can answer or modify DNS responses can replay the parent's genuine signed records to get an NXDOMAIN or NODATA response for an existing name in the child zone accepted as secure. A recursor caches that denial for the negative TTL.\n\nThis affects DNSSEC validation through `DnssecDnsHandle` when built with `dnssec-ring` or `dnssec-aws-lc-rs`.\n\nThe fix adds `NSEC::is_ancestor_delegation()` in hickory-proto. Validation no longer uses such a record to cover a name below its owner, and treats a direct match on it as bogus unless the query is for DS. It is in 0.26.2.","affected":[{"package":{"name":"hickory-net","ecosystem":"crates.io","purl":"pkg:cargo/hickory-net"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.26.2"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["privilege-escalation"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0539.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/hickory-net"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0539.html"},{"type":"WEB","url":"https://github.com/hickory-dns/hickory-dns/commit/2e3c829ea45000b1c409a64a03bd422618372471"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0540","published":"2026-09-03T12:00:00Z","modified":"2026-11-13T12:55:54.316294846Z","aliases":["CVE-2026-123591","GHSA-7php-9j59-g3ch","RUSTSEC-2026-0531"],"summary":"Child-side NSEC or NSEC3 record accepted as proof that a delegation has no DS record","details":"To show that a delegation is insecure, a validator needs proof that the parent zone has no DS record for it. That proof must come from the parent side of the zone cut: RFC 4035 section 5.2, RFC 5155 section 8.9 and RFC 6840 section 4.4 require the matching NSEC or NSEC3 record not to have the SOA bit set, since a record with SOA comes from the child zone's apex.\n\nDNSSEC validation did not check this. An attacker who can answer or modify DNS responses can answer a DS query with the child zone's own signed NSEC or NSEC3 record for its apex, which does not list DS, and have the validator accept that the delegation is insecure. Records in the child zone can then be forged without any signature.\n\nThis affects DNSSEC validation through `DnssecDnsHandle` when built with `dnssec-ring` or `dnssec-aws-lc-rs`.\n\nThe fix treats a NODATA proof for a DS query as bogus when the directly matching NSEC or NSEC3 record has SOA in its type bitmap. It is in 0.26.2.","affected":[{"package":{"name":"hickory-net","ecosystem":"crates.io","purl":"pkg:cargo/hickory-net"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.26.2"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["privilege-escalation"],"cvss":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0540.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/hickory-net"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0540.html"},{"type":"WEB","url":"https://github.com/hickory-dns/hickory-dns/commit/ec98851f4d175d97b61701bc539523ff63ddbb00"}],"database_specific":{"license":"CC0-1.0"},"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"}]}
|
||||
@@ -0,0 +1 @@
|
||||
{"schema_version":"1.9.2","id":"RUSTSEC-2026-0541","published":"2026-09-03T12:00:00Z","modified":"2026-11-13T12:55:46.260287377Z","aliases":["CVE-2026-123595","GHSA-624w-vvww-xvpw","RUSTSEC-2026-0532"],"summary":"Parent-side NSEC3 at a zone cut accepted as proof of nonexistence at and below the cut","details":"At a delegation, the parent zone signs an NSEC3 record for the child's name whose type bitmap has NS but not SOA (or has DNAME). RFC 6840 section 4.1 and RFC 5155 section 8.3 say such a record only proves that no DS record exists at that name.\n\nNSEC3 validation picked the closest encloser by matching the hashed owner name alone, without looking at the type bitmap, so it accepted such a record as the closest encloser for names below the cut. For NODATA responses, it accepted a direct match on such a record as proof that any type other than the queried one and CNAME was absent, not only DS. An attacker who can answer or modify DNS responses can replay the parent's genuine signed records to get an NXDOMAIN for a name below the cut, or a NODATA for a non-DS type at the cut, accepted as secure. A recursor caches that denial for the negative TTL.\n\nThis affects DNSSEC validation through `DnssecDnsHandle` when built with `dnssec-ring` or `dnssec-aws-lc-rs`.\n\nThe fix adds `NSEC3::is_ancestor_delegation()` in hickory-proto. Validation no longer accepts such a record as a closest encloser, and treats a direct match on it as bogus unless the query is for DS. It is in 0.26.2.","affected":[{"package":{"name":"hickory-net","ecosystem":"crates.io","purl":"pkg:cargo/hickory-net"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.26.2"}]}],"ecosystem_specific":{"affected_functions":null,"affects":{"arch":[],"functions":[],"os":[]}},"database_specific":{"categories":["privilege-escalation"],"cvss":null,"informational":null,"source":"https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0541.json"}}],"references":[{"type":"PACKAGE","url":"https://crates.io/crates/hickory-net"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2026-0541.html"},{"type":"WEB","url":"https://github.com/hickory-dns/hickory-dns/commit/889801333d7f18d59a4468100e8cd1859e083d43"}],"database_specific":{"license":"CC0-1.0"}}
|
||||
Reference in new issue
Block a user