RUSTSEC-2026-0232High· 7.5▾ TwilightProcessing of unverified relay events
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
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.
nostr-relay-pool >= 0.0.0-0, < 0.44.3Upgrade to a patched release:
nostr-relay-pool 0.44.3Connected by shared product, vendor, weakness, or advisory.
RUSTSEC-2026-0243None`nostr-relay-pool` is unmaintained
RUSTSEC-2026-0231High· 7.5Relay authentication challenges can exhaust memory
RUSTSEC-2026-0224High· 7.5Verification cache poisoning allows forged Nostr events to bypass signature validation