RUSTSEC-2026-0231High· 7.5▾ TwilightRelay authentication challenges can exhaust memory
▾ 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 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.
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-0232High· 7.5Processing of unverified relay events
RUSTSEC-2026-0224High· 7.5Verification cache poisoning allows forged Nostr events to bypass signature validation