rustsec-2026-0224
Vulnerability from osv_rustsec
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
{
"affected": [
{
"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
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "nostr-relay-pool",
"purl": "pkg:cargo/nostr-relay-pool"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "0.44.2"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-f96q-5f6p-v7cj"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "The `nostr-relay-pool` crate cached the result of event signature verification\nbefore the check was actually performed. Because the entry was inserted\nunconditionally, a first delivery whose signature failed was still recorded\nin the cache. A subsequent delivery of the same event (identical ID,\nbut with a forged signature) would then hit the cache, causing signature\nverification to be skipped entirely. The forged event was passed on to\n`NostrDatabase::save_event()` as if it had been validated.\n\nApplications that connect to untrusted or compromised Nostr relays and persist\nreceived events are vulnerable. An attacker can inject arbitrary events\nwithout a valid signature into the application\u0027s trusted database, enabling\nimpersonation of any public key or corruption of application state derived from\nstored events.\n\nThe issue does not compromise confidentiality or availability. It solely\nundermines the integrity of stored event data.\n\nThe fix, released in version 0.44.2, moves the cache insertion to occur only\nafter a successful signature verification, so that failed attempts never create\na cache entry.\n\n## Credit\n\nDiscovered and reported by [Ali Al-Sorehi](https://github.com/aykoooo)",
"id": "RUSTSEC-2026-0224",
"modified": "2026-08-01T15:02:54Z",
"published": "2026-08-01T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/nostr-relay-pool"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0224.html"
},
{
"type": "WEB",
"url": "https://github.com/nostrdevkit/nostr/commit/02a88bd5688de058bfba8aa9fb4612441a384eff"
}
],
"related": [],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Verification cache poisoning allows forged Nostr events to bypass signature validation"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.