https://feed.craftedsignal.io/vendors/nuget/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 06 May 2026 20:53:23 +0000https://feed.craftedsignal.io/briefs/2026-05-snappier-dos/Wed, 06 May 2026 20:53:23 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-snappier-dos/Snappier versions 1.3.0 and earlier are vulnerable to a denial-of-service condition where a malformed Snappy stream input to `SnappyStream` decompression causes an infinite loop, consuming a thread until the process is terminated.The Snappier library, specifically the SnappyStream class, is susceptible to a denial-of-service vulnerability when decompressing malformed Snappy streams in framed format. An attacker who can control the input to the SnappyStream decompression process can trigger an infinite loop, leading to excessive CPU consumption and thread exhaustion. This issue affects applications using Snappier version 1.3.0 and earlier. The vulnerability stems from an unhandled condition in the decompression logic, causing the SnappyStreamDecompressor.Decompress method to repeatedly call Crc32CAlgorithm.Append without termination. Standard exception handling mechanisms (try/catch blocks) are ineffective in preventing the hang, making it difficult to mitigate without terminating the affected process.

Attack Chain

1. An attacker crafts a malformed Snappy compressed data stream (as small as 15 bytes).
2. The attacker sends this malformed stream to a service or application using the Snappier library for decompression.
3. The application instantiates a SnappyStream object with CompressionMode.Decompress to handle the incoming data stream.
4. The application calls CopyTo() or a similar method on the SnappyStream to decompress the data.
5. The SnappyStreamDecompressor.Decompress method is invoked internally.
6. Due to the malformed input, an infinite loop occurs within SnappyStreamDecompressor.Decompress involving repeated calls to Crc32CAlgorithm.Append.
7. A single CPU core is consumed at 100% by the affected thread.
8. The application hangs indefinitely, requiring termination to recover.

Impact

Successful exploitation of this vulnerability results in a denial-of-service condition. An attacker can remotely trigger the infinite loop by sending malicious data to any application that utilizes the vulnerable Snappier.SnappyStream for decompression. This can lead to resource exhaustion, application unavailability, and potentially impact other services relying on the same system. Since the try/catch doesn’t work, the service will remain inoperable until manually restarted.

Recommendation

• Upgrade to a patched version of the Snappier library that addresses CVE-2026-44302.
• Implement input validation and sanitization on data streams prior to decompression using Snappier.SnappyStream.
• Monitor CPU usage for processes utilizing the Snappier library. Deploy the process monitoring rule below to detect potential exploitation attempts based on high CPU usage.

]]>mediumadvisorydenial-of-servicecompressioninfinite-loophttps://feed.craftedsignal.io/briefs/2024-01-nerdbank-stack-overflow/Fri, 26 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-nerdbank-stack-overflow/A malicious MessagePack payload can trigger a StackOverflowException in Nerdbank.MessagePack due to an uncontrolled stack allocation when decoding DateTime values with oversized timestamp extension lengths, leading to process termination.Nerdbank.MessagePack versions prior to 1.1.62 are vulnerable to an uncontrolled stack allocation vulnerability. This flaw allows an attacker to craft a malicious MessagePack payload that declares an oversized timestamp extension length. When the application attempts to deserialize this payload and encounters a DateTime value, the reader allocates an attacker-controlled number of bytes on the stack. This excessive allocation results in a StackOverflowException, causing the application to terminate. This vulnerability impacts applications that deserialize MessagePack data from untrusted sources and can lead to denial-of-service conditions. Defenders should prioritize patching or implementing workarounds to mitigate this risk.

Attack Chain

1. Attacker crafts a malicious MessagePack payload with an invalid timestamp extension length (not 4, 8, or 12 bytes).
2. The target application receives the malicious MessagePack payload from an untrusted source.
3. The application attempts to deserialize the MessagePack data using Nerdbank.MessagePack.
4. During deserialization, the DateTime decoder encounters the malicious timestamp extension.
5. The decoder derives tokenSize from the attacker-controlled extension length before validating its size.
6. The unvalidated size is used in a stackalloc on the streaming reader’s slow path, allocating an excessive amount of stack memory.
7. The excessive stack allocation triggers a StackOverflowException.
8. The StackOverflowException terminates the application process, resulting in a denial of service.

Impact

Successful exploitation of this vulnerability leads to a denial-of-service condition due to process termination. The vulnerability affects applications deserializing MessagePack data from untrusted sources, particularly those handling long-running processes such as services, APIs, workers, or message consumers. Even small malicious payloads can trigger the vulnerability due to the attacker-controlled extension length. This could potentially disrupt critical business functions relying on affected applications.

Recommendation

• Upgrade to Nerdbank.MessagePack version 1.1.62 or later to remediate the vulnerability.
• Implement pre-validation of MessagePack extension headers, rejecting timestamp extensions with lengths other than 4, 8, or 12 bytes, as suggested in the advisory [GHSA-2cwq-pwfr-wcw3].
• Deploy the Sigma rule “Nerdbank MessagePack Suspicious Stack Allocation” to detect potential exploitation attempts in your environment.
• If immediate patching is not feasible, consider running deserialization of untrusted payloads in isolated processes that can be safely restarted, as described in [GHSA-2cwq-pwfr-wcw3].

]]>highadvisorydenial-of-servicestack-overflowmessagepack