nostr

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.

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.

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 parsing the plaintext.

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 decoded payloads before full allocation or HMAC processing. The limit remains in the v2 implementation so a future codec with a different length format can define its own bound.

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 separator or decoding an arbitrarily large IV.

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.

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 lengths now return a Malformed error instead of panicking.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

The NIP-44 v2 decryption path in the nostr crate contains a reachable panic when processing a short or empty ciphertext. After the HMAC check passes and the ciphertext is decrypted via ChaCha20, the code reads a 2‑byte unpadded‑length prefix via buffer[0..2] without first verifying that the decrypted buffer contains at least 2 bytes. A malicious sender who holds the symmetric conversation key (e.g., a direct‑message sender) can craft a payload that produces a 0 or 1‑byte decrypted buffer, causing an index‑out‑of‑bounds panic. This can be triggered remotely through any relay that delivers the crafted event to the victim's client, resulting in a denial of service. No key material, plaintext, or memory corruption occurs.

The vulnerability is present in all versions from 0.26.0 up to 0.44.4 (inclusive) and in the alpha releases 0.45.0‑alpha.1 through 0.45.0‑alpha.4. Versions 0.44.5 and 0.45.0‑alpha.5 contain the fix.

Credit

Discovered and responsibly disclosed by Muhammed Shekho (mhd-shekho.com).

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.