Rust advisories / nostr-relay-pool
Vulnerability HighRUSTSEC-2026-0232 · nostr-relay-pool
RUSTSEC-2026-0232: Processing of unverified relay events
Short answerA security vulnerability in the nostr-relay-pool crate: Processing of unverified relay events. High severity (CVSS 7.5). Fixed in 0.44.3: update to a fixed version.
| Crate | nostr-relay-pool |
|---|---|
| Type | Vulnerability (crypto-failure) |
| Affected versions | Before 0.44.3. |
| Fixed in | 0.44.3 |
| Severity | High, CVSS 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N |
| Published | 2026-08-01 |
| Last changed | 2026-08-02 |
| Also known as | none |
What to do
- See which version you have:
cargo tree -i nostr-relay-pool(it also shows which of your dependencies pulls it in). - Update within your version requirement:
cargo update -p nostr-relay-pool. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for examplenostr-relay-pool = "0.44.3") or update the dependency that pulls it in. - Check again with
cargo audit, or paste your Cargo.lock into our Cargo.toml checker.
Details from the advisory
The processed events received from a relay through admission-policy and database paths before verifying that the serialized fields matched the claimed event ID and signature. In particular, a database result for the claimed ID could cause verification to be skipped. The verification cache also keyed successful checks by a 64-bit hash instead of the complete event ID.
A malicious relay could send an event whose claimed ID referred to a known database entry while its content, tags, author, or signature differed from that ID. The forged event could then reach policy callbacks or other SDK processing as if it were authentic. A cache-key collision provided a second path for an unverified event to be treated as previously verified. This undermines event integrity but does not reveal private keys or enable the attacker to produce a valid signature for the altered event.
The SDK now verifies each event before policy evaluation, database lookup, or propagation decisions, and the verification cache stores the complete EventId so a truncated hash collision cannot stand in for successful verification.
References
- Package: crates.io/crates/nostr-relay-pool
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0232.html
- Web: github.com/nostrdevkit/nostr/commit/4b67f9b45909d2e35f34c30c084c0ab66e599a9f
From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.
Other advisories for nostr-relay-pool
- Vulnerability HighRUSTSEC-2026-0224 · 2026-08-01Verification cache poisoning allows forged Nostr events to bypass signature validation
- Vulnerability HighRUSTSEC-2026-0231 · 2026-08-01Relay authentication challenges can exhaust memory
- UnmaintainedRUSTSEC-2026-0243 · 2026-08-03`nostr-relay-pool` is unmaintained
Up next
Same cratenostr-relay-pool: security historyEvery advisory for this crate, and whether it is safe to use today.Read it next →Did this answer your question?