https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Thu, 18 Jun 2026 22:26:34 +0000 https://vulnerability.circl.lu/sighting/2b54af85-7a4f-46d1-beb0-9ecfe71450e5/export {"uuid": "2b54af85-7a4f-46d1-beb0-9ecfe71450e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "GHSA-82j2-j2ch-gfr8", "type": "seen", "source": "https://gist.github.com/web3securityauditor/7d7d8acf63a2ec18ed25f500c878c123", "content": "# [Coordinated Disclosure] librustzcash + zallet \u2014 `rustls-webpki` is pinned 12 patch versions behind a maintained release with four published advisories\n\n| Field | Value |\n| --- | --- |\n| Class | Privacy / Store of Value (TLS validation in wallet \u2194 lightwalletd path) |\n| Severity (proposed) | **Informational** \u2014 pure dependency hygiene. None of the four advisories is currently reachable in librustzcash/zallet's actual TLS usage (default cert chains have no name constraints, no CRLs configured); the only legitimate signal is asymmetry with already-bumped sister crates. |\n| Affected crates | `librustzcash` (`zcash_client_backend`), `zallet`, `zcash-devtool` (latter resolves `rustls-webpki 0.103.10` \u2014 patched for -0049 but still affected by -0098/-0099/-0104) |\n| Affected versions pinned | `rustls-webpki = \"0.103.1\"` (resolved in `Cargo.lock`) |\n| Maintained version | `rustls-webpki = \"0.103.13\"` (12 patch releases ahead) |\n| Sister crates already updated | `zebra` and `zaino` are on `rustls-webpki = \"0.103.13\"` (patched) |\n| Discovery date | 2026-05-15 |\n\n---\n\n## Summary\n\n`librustzcash`'s `Cargo.lock` and `zallet`'s `Cargo.lock` both resolve `rustls-webpki = \"0.103.1\"` (via `tonic 0.14.2 \u2192 tokio-rustls 0.26.2 \u2192 rustls 0.23.25 \u2192 rustls-webpki 0.103.1`). The TLS path is reachable from `zcash_client_backend/src/tor/grpc.rs:31`:\n\n```rust\n.tls_config(ClientTlsConfig::new().with_webpki_roots())\n```\n\nThis is the wallet's TLS configuration for talking to a `lightwalletd` over Tor. The validating code path is what protects the wallet against a malicious Tor exit node or any other on-path adversary presenting a forged certificate.\n\nThe pinned `0.103.1` is 12 patch releases behind the current `0.103.13`. The intervening releases ship four security advisories:\n\n| Advisory | Date | Class | Patched at | Reachable in `librustzcash`'s usage today? |\n|---|---|---|---|---|\n| [RUSTSEC-2026-0098 (GHSA-965h-392x-2mh5)](https://rustsec.org/advisories/RUSTSEC-2026-0098.html) | 2026-04-14 | URI name-constraint validation gap | \u2265 0.103.12 | **No** \u2014 the advisory itself notes \"this library does not provide an API for asserting URI names\" |\n| [RUSTSEC-2026-0099 (GHSA-xgp8-3hg3-c2mh)](https://rustsec.org/advisories/RUSTSEC-2026-0099.html) | 2026-04-14 | DNS name-constraint bypass when cert asserts a wildcard | \u2265 0.103.12 | **Latent** \u2014 requires a cert chain that uses DNS name constraints (uncommon for typical webpki-roots TLS endpoints, but used in some enterprise PKIs and onion-service cert chains) |\n| [RUSTSEC-2026-0049 (GHSA-pwjx-qhcg-rvj4)](https://rustsec.org/advisories/RUSTSEC-2026-0049.html) | 2026-03-20 | CRL distribution-point matching | \u2265 0.103.10 | **No** \u2014 the librustzcash TLS path does not configure CRL checking |\n| [RUSTSEC-2026-0104 (GHSA-82j2-j2ch-gfr8)](https://rustsec.org/advisories/RUSTSEC-2026-0104.html) | 2026-04-22 | Panic in CRL parsing | \u2265 0.103.13 | **No** \u2014 librustzcash does not parse CRLs |\n\nSo the immediate reachability is limited: only RUSTSEC-2026-0099 has any plausible reach, and even that requires a non-default cert chain shape. `zebra` and `zaino` already sit on `rustls-webpki = 0.103.13`, so the librustzcash + zallet pair are the only ones in the workspace family still on the pre-patch line.\n\nThe reason to disclose this anyway:\n\n1. **Sister crates already moved.** `zebra` and `zaino` updated; `librustzcash` and `zallet` did not. The asymmetry is itself a signal that the move was missed in librustzcash, not a deliberate hold-back.\n2. **Cert-chain shape is operator-controlled.** The reachability assessment \"requires DNS name constraints + wildcard\" depends on what cert is presented to the wallet by the lightwalletd it's configured to talk to. A user pointing the wallet at a corporate-PKI lightwalletd, an onion-service lightwalletd, or any custom CA chain shifts the reachability. A library-level \"this isn't reachable for our default users\" assertion shouldn't bind operators to a default cert profile.\n3. **Tor exit node threat model.** `zcash_client_backend::tor::grpc` is specifically the Tor-routed TLS path. The threat model for a Tor wallet user is \"any exit node may MitM unless TLS validates\" \u2014 TLS validation is the *only* line of defense, and so any latent gap in the validation library is operationally relevant for that user class even when \"not directly exploitable today.\"\n4. **Dep hygiene.** In a workspace with strong dependency-pinning discipline, a 12-patch-version gap on a TLS validation library reads as a missed bump rather than a deliberate constraint. The `Cargo.lock` would update on the next `cargo update -p rustls-webpki`.\n\n## Verification at code level\n\n```\n$ grep -A 2 'name = \"rustls-webpki\"' librustzcash/Cargo.lock\n[[package]]\nname = \"rustls-webpki\"\nversion = \"0.101.7\" # pulled by an older rustls 0.21\n\u2026\n[[package]]\nname = \"rustls-webpki\"\nversion = \"0.103.1\" # pulled by current rustls 0.23 (the active TLS path)\n\n$ grep 'rustls 0.23' -A 12 librustzcash/Cargo.lock\n[[package]]\nname = \"rustls\"\nversion = \"0.23.25\"\n\u2026\n \"rustls-webpki 0.103.1\", \u2190 this is the version active in the tonic path\n\n$ grep -n 'with_webpki_roots' librustzcash/zcash_client_backend/src/tor/grpc.rs\n31: .tls_config(ClientTlsConfig::new().with_webpki_roots())\n```\n\nFor `zallet`:\n\n```\n$ grep -A 2 'name = \"rustls-webpki\"' zallet/Cargo.lock\n\u2026\nversion = \"0.103.1\"\n```\n\nBoth `zebra` and `zaino` resolve `0.103.13`:\n\n```\n$ grep -A 2 'name = \"rustls-webpki\"' zebra/Cargo.lock zaino/Cargo.lock\nzebra/Cargo.lock:version = \"0.103.13\"\nzaino/Cargo.lock:version = \"0.103.13\"\n```\n\n## Suggested fix\n\nBump `rustls` (and transitively `rustls-webpki`) in `librustzcash` and `zallet` to versions that resolve `rustls-webpki >= 0.103.13`. The `Cargo.toml`s of both repos do not directly pin `rustls-webpki` (it comes through `rustls`), so the actual update is on `rustls` / `tokio-rustls` / `tonic`, or by running `cargo update -p rustls-webpki --precise 0.103.13` and committing the lockfile.\n\n**One additional fix needed**: `librustzcash/supply-chain/config.toml` lists `rustls-webpki 0.103.1` as a `safe-to-deploy` cargo-vet exemption. The version bump must also remove or update that exemption entry, otherwise `cargo vet check` will continue to validate against the old version. This is an easy thing to miss in a routine lockfile-only bump.\n\nA regression test that asserts `cargo audit` on the lockfile passes (or that the `rustls-webpki` resolved version is `>= 0.103.13`) would catch any future drift.\n\n## What I am NOT claiming\n\nI am not claiming any of the four advisories is currently reachable for a default-configuration wallet against a default-configuration lightwalletd. The only one with any plausible reachability is RUSTSEC-2026-0099, and only for cert chains that use DNS name constraints. I am claiming that the dep is out of date, that the asymmetry with the patched sister crates is anomalous, and that the gap is operationally relevant for users whose deployment shape is non-default (corporate PKI, onion-service cert chains, future cert-chain changes).\n\nIf the team's stance is \"yes, we know, we'll bump on the next release,\" that is a sufficient response and I'd document it as such.\n\n---\n\n## Researcher contact\n\nSignal: this thread. Happy to run a follow-up sweep of all `Cargo.lock` files across the librustzcash workspace family for any other dep that's behind the maintained line, if useful.\n", "creation_timestamp": "2026-05-17T18:09:49.000000Z"} {"uuid": "2b54af85-7a4f-46d1-beb0-9ecfe71450e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "GHSA-82j2-j2ch-gfr8", "type": "seen", "source": "https://gist.github.com/web3securityauditor/7d7d8acf63a2ec18ed25f500c878c123", "content": "# [Coordinated Disclosure] librustzcash + zallet \u2014 `rustls-webpki` is pinned 12 patch versions behind a maintained release with four published advisories\n\n| Field | Value |\n| --- | --- |\n| Class | Privacy / Store of Value (TLS validation in wallet \u2194 lightwalletd path) |\n| Severity (proposed) | **Informational** \u2014 pure dependency hygiene. None of the four advisories is currently reachable in librustzcash/zallet's actual TLS usage (default cert chains have no name constraints, no CRLs configured); the only legitimate signal is asymmetry with already-bumped sister crates. |\n| Affected crates | `librustzcash` (`zcash_client_backend`), `zallet`, `zcash-devtool` (latter resolves `rustls-webpki 0.103.10` \u2014 patched for -0049 but still affected by -0098/-0099/-0104) |\n| Affected versions pinned | `rustls-webpki = \"0.103.1\"` (resolved in `Cargo.lock`) |\n| Maintained version | `rustls-webpki = \"0.103.13\"` (12 patch releases ahead) |\n| Sister crates already updated | `zebra` and `zaino` are on `rustls-webpki = \"0.103.13\"` (patched) |\n| Discovery date | 2026-05-15 |\n\n---\n\n## Summary\n\n`librustzcash`'s `Cargo.lock` and `zallet`'s `Cargo.lock` both resolve `rustls-webpki = \"0.103.1\"` (via `tonic 0.14.2 \u2192 tokio-rustls 0.26.2 \u2192 rustls 0.23.25 \u2192 rustls-webpki 0.103.1`). The TLS path is reachable from `zcash_client_backend/src/tor/grpc.rs:31`:\n\n```rust\n.tls_config(ClientTlsConfig::new().with_webpki_roots())\n```\n\nThis is the wallet's TLS configuration for talking to a `lightwalletd` over Tor. The validating code path is what protects the wallet against a malicious Tor exit node or any other on-path adversary presenting a forged certificate.\n\nThe pinned `0.103.1` is 12 patch releases behind the current `0.103.13`. The intervening releases ship four security advisories:\n\n| Advisory | Date | Class | Patched at | Reachable in `librustzcash`'s usage today? |\n|---|---|---|---|---|\n| [RUSTSEC-2026-0098 (GHSA-965h-392x-2mh5)](https://rustsec.org/advisories/RUSTSEC-2026-0098.html) | 2026-04-14 | URI name-constraint validation gap | \u2265 0.103.12 | **No** \u2014 the advisory itself notes \"this library does not provide an API for asserting URI names\" |\n| [RUSTSEC-2026-0099 (GHSA-xgp8-3hg3-c2mh)](https://rustsec.org/advisories/RUSTSEC-2026-0099.html) | 2026-04-14 | DNS name-constraint bypass when cert asserts a wildcard | \u2265 0.103.12 | **Latent** \u2014 requires a cert chain that uses DNS name constraints (uncommon for typical webpki-roots TLS endpoints, but used in some enterprise PKIs and onion-service cert chains) |\n| [RUSTSEC-2026-0049 (GHSA-pwjx-qhcg-rvj4)](https://rustsec.org/advisories/RUSTSEC-2026-0049.html) | 2026-03-20 | CRL distribution-point matching | \u2265 0.103.10 | **No** \u2014 the librustzcash TLS path does not configure CRL checking |\n| [RUSTSEC-2026-0104 (GHSA-82j2-j2ch-gfr8)](https://rustsec.org/advisories/RUSTSEC-2026-0104.html) | 2026-04-22 | Panic in CRL parsing | \u2265 0.103.13 | **No** \u2014 librustzcash does not parse CRLs |\n\nSo the immediate reachability is limited: only RUSTSEC-2026-0099 has any plausible reach, and even that requires a non-default cert chain shape. `zebra` and `zaino` already sit on `rustls-webpki = 0.103.13`, so the librustzcash + zallet pair are the only ones in the workspace family still on the pre-patch line.\n\nThe reason to disclose this anyway:\n\n1. **Sister crates already moved.** `zebra` and `zaino` updated; `librustzcash` and `zallet` did not. The asymmetry is itself a signal that the move was missed in librustzcash, not a deliberate hold-back.\n2. **Cert-chain shape is operator-controlled.** The reachability assessment \"requires DNS name constraints + wildcard\" depends on what cert is presented to the wallet by the lightwalletd it's configured to talk to. A user pointing the wallet at a corporate-PKI lightwalletd, an onion-service lightwalletd, or any custom CA chain shifts the reachability. A library-level \"this isn't reachable for our default users\" assertion shouldn't bind operators to a default cert profile.\n3. **Tor exit node threat model.** `zcash_client_backend::tor::grpc` is specifically the Tor-routed TLS path. The threat model for a Tor wallet user is \"any exit node may MitM unless TLS validates\" \u2014 TLS validation is the *only* line of defense, and so any latent gap in the validation library is operationally relevant for that user class even when \"not directly exploitable today.\"\n4. **Dep hygiene.** In a workspace with strong dependency-pinning discipline, a 12-patch-version gap on a TLS validation library reads as a missed bump rather than a deliberate constraint. The `Cargo.lock` would update on the next `cargo update -p rustls-webpki`.\n\n## Verification at code level\n\n```\n$ grep -A 2 'name = \"rustls-webpki\"' librustzcash/Cargo.lock\n[[package]]\nname = \"rustls-webpki\"\nversion = \"0.101.7\" # pulled by an older rustls 0.21\n\u2026\n[[package]]\nname = \"rustls-webpki\"\nversion = \"0.103.1\" # pulled by current rustls 0.23 (the active TLS path)\n\n$ grep 'rustls 0.23' -A 12 librustzcash/Cargo.lock\n[[package]]\nname = \"rustls\"\nversion = \"0.23.25\"\n\u2026\n \"rustls-webpki 0.103.1\", \u2190 this is the version active in the tonic path\n\n$ grep -n 'with_webpki_roots' librustzcash/zcash_client_backend/src/tor/grpc.rs\n31: .tls_config(ClientTlsConfig::new().with_webpki_roots())\n```\n\nFor `zallet`:\n\n```\n$ grep -A 2 'name = \"rustls-webpki\"' zallet/Cargo.lock\n\u2026\nversion = \"0.103.1\"\n```\n\nBoth `zebra` and `zaino` resolve `0.103.13`:\n\n```\n$ grep -A 2 'name = \"rustls-webpki\"' zebra/Cargo.lock zaino/Cargo.lock\nzebra/Cargo.lock:version = \"0.103.13\"\nzaino/Cargo.lock:version = \"0.103.13\"\n```\n\n## Suggested fix\n\nBump `rustls` (and transitively `rustls-webpki`) in `librustzcash` and `zallet` to versions that resolve `rustls-webpki >= 0.103.13`. The `Cargo.toml`s of both repos do not directly pin `rustls-webpki` (it comes through `rustls`), so the actual update is on `rustls` / `tokio-rustls` / `tonic`, or by running `cargo update -p rustls-webpki --precise 0.103.13` and committing the lockfile.\n\n**One additional fix needed**: `librustzcash/supply-chain/config.toml` lists `rustls-webpki 0.103.1` as a `safe-to-deploy` cargo-vet exemption. The version bump must also remove or update that exemption entry, otherwise `cargo vet check` will continue to validate against the old version. This is an easy thing to miss in a routine lockfile-only bump.\n\nA regression test that asserts `cargo audit` on the lockfile passes (or that the `rustls-webpki` resolved version is `>= 0.103.13`) would catch any future drift.\n\n## What I am NOT claiming\n\nI am not claiming any of the four advisories is currently reachable for a default-configuration wallet against a default-configuration lightwalletd. The only one with any plausible reachability is RUSTSEC-2026-0099, and only for cert chains that use DNS name constraints. I am claiming that the dep is out of date, that the asymmetry with the patched sister crates is anomalous, and that the gap is operationally relevant for users whose deployment shape is non-default (corporate PKI, onion-service cert chains, future cert-chain changes).\n\nIf the team's stance is \"yes, we know, we'll bump on the next release,\" that is a sufficient response and I'd document it as such.\n\n---\n\n## Researcher contact\n\nSignal: this thread. Happy to run a follow-up sweep of all `Cargo.lock` files across the librustzcash workspace family for any other dep that's behind the maintained line, if useful.\n", "creation_timestamp": "2026-05-17T18:09:49.000000Z"} https://vulnerability.circl.lu/sighting/2b54af85-7a4f-46d1-beb0-9ecfe71450e5/export Sun, 17 May 2026 18:09:49 +0000