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
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The NIP-50 event-matching path searched event content with `slice::windows(search.len())`. An empty search string therefore called `slice::windows(0)`, which always panics instead of returning a match result. A remote client able to submit filters to an application using this matcher could trigger the panic with an empty NIP-50 search value. This includes clients querying an SDK local relay. Depending on the application's panic configuration and task isolation, the crafted filter could terminate request processing, a runtime worker, or the entire process, causing denial of service. No confidentiality or integrity impact is known. Empty searches are now handled before the substring search, so the matcher returns a defined result without constructing a zero-sized window or panicking.
Recommended action: Upgrade to 0.44.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NIP-04 decryption parser split attacker-controlled content on every `?iv=` separator and collected all resulting segments before checking that the message had the expected two parts. It also Base64-decoded the complete IV text before checking that it represented the required 16-byte AES-CBC IV. A malicious sender could include a large number of separators or an oversized IV in an encrypted direct message. Applications that attempted to decrypt the message performed avoidable allocations proportional to the malformed input, with additional allocation amplification from the segment vector and Base64 output. This can consume memory and CPU in clients processing messages received through a relay. It does not weaken NIP-04 encryption or reveal plaintext or key material. The parser now uses a single bounded split, rejects additional separators, and validates the 24-byte encoded IV length before Base64 decoding. Malformed inputs are returned as errors without allocating for every…
Recommended action: Upgrade to 0.44.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NIP-44 decryption entry point Base64-decoded the complete attacker-controlled payload before determining its version or enforcing any size limit. For v2 payloads, the decoded buffer was then authenticated with HMAC even when it was much larger than the maximum payload supported by the crate's current v2 codec. A malicious relay or event author could deliver an oversized value to an application that decrypts NIP-44 content. The value caused memory allocation and Base64 and HMAC work proportional to its size before authentication failed; knowledge of the conversation key was not required to consume those initial resources. Repeated payloads could exhaust memory or CPU and make the receiving application unavailable. The issue does not disclose plaintext or key material and does not bypass message authentication. Decryption now reads only the encoded version prefix first, derives the bound from the largest payload the current v2 encoder can emit, and rejects oversized encoded and…
Recommended action: Upgrade to 0.44.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NIP-47 response and notification parsers and the NIP-60 wallet event parsers decrypted relay-provided events before verifying their kind, computed event ID, signature, and expected wallet public key. The decryption peer was derived from the untrusted event author, so successful decryption did not prove that the configured wallet created the event. An attacker can sign an event with their own key and derive the corresponding shared secret with the victim's public key. A malicious relay delivering that event could therefore cause attacker-chosen encrypted content to be parsed as a response, notification, token, spending record, or quote from the configured wallet. This can corrupt wallet state or cause an application to act on forged wallet data. The issue does not expose the victim's private key or decrypt events authored by the legitimate wallet. The affected parsers now verify the event kind, ID, signature, and exact configured wallet author before attempting decryption or…
Recommended action: Upgrade to 0.44.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Several NIP-46 and NIP-60 types used derived `Debug` implementations even though their fields contained credentials or decrypted application data. Formatting these values exposed NIP-46 connection secrets and request parameters, as well as NIP-60 private keys, Cashu bearer proofs, and quote capability identifiers. Applications commonly include `Debug` output in diagnostic logs, tracing spans, or error reports. Anyone able to read those outputs could recover the disclosed credentials and, depending on the value, impersonate a signer connection or spend wallet tokens. The issue does not expose data unless an affected value is formatted and the resulting output is made accessible. The affected types now use custom `Debug` implementations that preserve variant and non-sensitive structural information while replacing credentials, bearer values, and plaintext fields with redaction markers. Serialization and protocol behavior are unchanged.
Recommended action: Upgrade to 0.44.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The NIP-98 HTTP authorization parser Base64-decoded the complete authorization value and parsed the resulting JSON event without applying an application-level size limit. Both operations occurred before the event's signature and authorization fields could be validated. An unauthenticated remote client could send an oversized `Authorization: Nostr` header to a server using this parser. Each request caused memory allocation and decoding and JSON parsing work proportional to the supplied value, allowing repeated requests to consume server memory and CPU. The impact depends on any lower HTTP header limit already enforced by the hosting server. The issue does not bypass NIP-98 authentication or disclose protected data. The parser now rejects oversized encoded input before Base64 allocation and rejects decoded authorization events larger than 64 KiB before JSON parsing.
Recommended action: Upgrade to 0.44.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `nostr` crate did not validate the length of the initialization vector decoded from the `?iv=` portion of a NIP-04 encrypted message. The decoded IV was converted from a byte slice to the 16-byte AES-CBC IV type using a conversion that asserts the slice length. As a result, an IV whose decoded length was not exactly 16 bytes caused a panic before ciphertext decryption. For example, `?iv=AAAA` decodes to a three-byte IV and triggers the panic. Applications that decrypt untrusted NIP-04 content are affected. The issue is also reachable through NIP-47 (Nostr Wallet Connect), where response and notification events from a malicious or compromised wallet service are passed to NIP-04 decryption. If the panic is not isolated, a crafted event can terminate the application or disrupt message processing, causing a denial of service. The issue does not affect confidentiality or integrity. The flaw was corrected by converting the decoded IV to `[u8; 16]` using a checked conversion. Invalid IV…
Recommended action: Upgrade to 0.45.0-alpha.6 (pre-release) or 0.44.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.