What is the CVSS score of CVE-2026-44302?

CVE-2026-44302 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Which versions of Snappier are affected by CVE-2026-44302?

CVE-2026-44302 is a remote denial-of-service vulnerability in the Snappier .NET compression library that allows unauthenticated attackers to crash or freeze services processing compressed data with a…. A patch is available.

How to fix or mitigate CVE-2026-44302?

Within 24 hours: Identify all .NET applications using Snappier library (check NuGet dependencies, project files, and running services); isolate affected systems from untrusted input if possible and enable request size/rate limiting on upload endpoints. Within 7 days: Implement input validation to reject malformed compressed streams before decompression; deploy network-level DoS mitigations (WAF rules blocking compressed payloads under 15 bytes, rate-limiting compressed requests). Within 30 days: Evaluate Snappier alternatives (System.IO.Compression or other vetted libraries); plan migration path and conduct regression testing prior to library replacement in production.

Snappier CVE-2026-44302

HIGH

Loop with Unreachable Exit Condition (Infinite Loop) (CWE-835)

2026-05-06 https://github.com/brantburnett/Snappier

GHSA-pggp-6c3x-2xmx

Denial Of Service

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 06, 2026 - 21:31 vuln.today

Analysis Generated

May 06, 2026 - 21:31 vuln.today

CVE Published

May 06, 2026 - 20:53 nvd

HIGH 7.5

DescriptionGitHub Advisory

Summary

Snappier.SnappyStream enters an uncatchable infinite loop when decompressing a malformed framed-format Snappy stream as small as 15 bytes.

Details

The hang manifests as a userspace busy loop with SnappyStreamDecompressor.Decompress repeatedly calling Crc32CAlgorithm.Append. The exact non-terminating loop in or above Decompress has not been traced further.

PoC

csharp

using System.IO.Compression;
using Snappier;

byte[] data = { 0x00, 0x04, 0x00, 0x00, 0x64, 0x4e, 0x6c, 0x71, 0x79, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64 };
using var src = new MemoryStream(data);
using var snap = new SnappyStream(src, CompressionMode.Decompress);
using var dst = new MemoryStream();
snap.CopyTo(dst);   // never returns

Impact

A caller using SnappyStream on attacker-controlled bytes can be made to spin forever and burn a thread until the process is killed. try/catch around the stream operation can't recover (no exception is thrown).

AnalysisAI

Infinite loop denial-of-service in Snappier .NET library allows remote attackers to exhaust server resources with as few as 15 bytes of malformed Snappy-compressed data. The vulnerability affects the SnappyStream decompressor component when processing framed-format streams, causing an uncatchable busy-loop that cannot be interrupted via try/catch blocks. Publicly available exploit code exists (CVE researcher provided a working proof-of-concept). CVSS 7.5 with network vector and no authentication required indicates remotely exploitable attack surface in web applications processing compressed uploads or API payloads. No active exploitation confirmed at time of analysis, but the trivial exploit complexity (15-byte payload) makes this attractive for resource exhaustion attacks against .NET services using Snappier for decompression.

Technical ContextAI

Snappier is a .NET port of Google's Snappy compression algorithm, commonly used for high-performance data compression in distributed systems, databases, and network protocols. The vulnerability resides in the SnappyStreamDecompressor.Decompress method's handling of framed-format Snappy streams, specifically when processing malformed chunk headers. The infinite loop occurs in the CRC32 validation path where Crc32CAlgorithm.Append is called repeatedly without advancing the stream position or detecting corruption. This is a CWE-835 (Loop with Unreachable Exit Condition) class defect, where missing input validation allows specially crafted frame headers to trigger a state machine that never terminates. Unlike typical .NET exceptions, this manifests as a userspace CPU spin rather than throwing an exception, making it invisible to standard error handling. The affected package is distributed via NuGet as 'Snappier' and is used in performance-critical .NET applications requiring fast compression, including Couchbase clients, event streaming systems, and data serialization layers.

RemediationAI

Upgrade to Snappier version 1.3.1 or later, which includes the fix for the infinite loop condition in SnappyStreamDecompressor. Update the NuGet package reference in your .csproj file to '<PackageReference Include="Snappier" Version="1.3.1" />' and redeploy. The official fix commit is referenced in the GitHub security advisory at https://github.com/brantburnett/Snappier/security/advisories/GHSA-pggp-6c3x-2xmx. If immediate patching is not feasible, implement input validation before decompression: limit the maximum size of compressed payloads (e.g., reject inputs larger than expected data size plus compression overhead) and run decompression operations in isolated worker threads or processes with CPU time limits and health monitoring that can detect and terminate hung threads. For ASP.NET applications, configure request timeouts and implement async cancellation tokens on decompression operations to enable forced termination, though this will not prevent the thread spin itself. These mitigations reduce blast radius but do not eliminate the vulnerability - patching is the only complete fix. Note that cancellation tokens in .NET cannot interrupt a CPU-bound infinite loop unless the loop explicitly checks the token, which the buggy code does not do.