GHSA-f96q-5f6p-v7cj json
Verification cache poisoning allows forged Nostr events to bypass signature validation
published 3mo ago modified 3mo ago also RUSTSEC-2026-0224
- cvss
- 7.5
- version 3.1, OSV
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
The `nostr-relay-pool` crate cached the result of event signature verification before the check was actually performed. Because the entry was inserted unconditionally, a first delivery whose signature failed was still recorded in the cache. A subsequent delivery of the same event (identical ID, but with a forged signature) would then hit the cache, causing signature verification to be skipped entirely. The forged event was passed on to `NostrDatabase::save_event()` as if it had been validated.
Applications that connect to untrusted or compromised Nostr relays and persist received events are vulnerable. An attacker can inject arbitrary events without a valid signature into the application's trusted database, enabling impersonation of any public key or corruption of application state derived from stored events.
The issue does not compromise confidentiality or availability. It solely undermines the integrity of stored event data.
The fix, released in version 0.44.2, moves the cache insertion to occur only after a successful signature verification, so that failed attempts never create a cache entry.
## Credit
Discovered and reported by [Ali Al-Sorehi](https://github.com/aykoooo)
Patch / fix
Is GHSA-f96q-5f6p-v7cj in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| OSV | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | nostr-relay-pool | >=0.0.0-0, <0.44.2 |
0.44.2 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.