VDB
KO
HIGH 7.5

RUSTSEC-2026-0231

Relay authentication challenges can exhaust memory

Details

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.

Are you affected?

Enter the version of the package you're using.

Affected packages

crates.io / nostr-relay-pool
Introduced in: 0.0.0-0 Fixed in: 0.44.3

Upgrade nostr-relay-pool to 0.44.3 or newer (ecosystem crates.io).

References