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.