Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 0.44.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.44.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SDK forwarded every NIP-42 `AUTH` challenge received from a relay through an unbounded command queue. Challenge handling can wait for an asynchronous signer or user interaction, so receiving challenges was substantially faster than completing the corresponding authentication work. A malicious relay could continuously send new challenges without authenticating or delivering valid events. Every value remained queued, causing memory use and pending signer operations to grow without a fixed limit until the client became unavailable. The issue does not allow the relay to forge a signature or learn the client's private key. The SDK now coalesces pending challenges through a latest-value channel. NIP-42 makes an earlier challenge invalid when the relay sends a new one, so replacing pending work preserves the only challenge that can still be answered while keeping memory use bounded.
Recommended action: Upgrade to 0.44.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.