snappy-java CVE-2026-116590

Exploitation requires the embedding application to forward caller-controlled ranges into the vulnerable primitives in snappy-java < 1.1.10.9 - specifically Snappy.arrayCopy(src, offset, byteLength, dest, destOffset), SnappyInputStream.rawRead/read, or SnappyOutputStream.rawWrite/write (including their typed-array variants). The concrete triggers are a negative or oversized byteLength/offset passed through to native memcpy, or a typed-array byte-size calculation that overflows int. A realistic path is an application decompressing untrusted data via SnappyInputStream where byteLength derives from attacker-influenced input. Limiting factors: no authentication is needed (PR:N) and no user interaction (UI:N), but the application must actually expose untrusted offsets/lengths to these methods (reflected by AC:H) - if it validates ranges itself or never passes attacker-controlled sizes, the flaw is not reachable; documented impact is limited to availability (JVM crash). The vendor states the complete fix is upgrading to 1.1.10.9; the only stated workaround is to validate offsets and lengths before calling these methods.

Signals point to a real but modest priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, base 5.9 Medium) scores availability-only impact - the documented consequence is a JVM crash (denial of service), with no confidentiality or integrity impact in the official vector. AC:H reflects that triggering is not straightforward: the flaw lives in a library primitive, so exploitation depends on the embedding application forwarding caller-controlled offsets/lengths to the vulnerable methods. EPSS is low at 0.41% (35th percentile), the CVE is NOT in CISA KEV, and no public exploit code is present among the references (all are vendor advisory/patch/release links, not PoC). The vuln.today Decision label is this_month, not act_now or emergency, consistent with a widely-used library that carries DoS-only risk rather than active exploitation. SSVC-style reasoning: exploitation status is none, technical impact is partial (availability loss, not full control), and automatability is uncertain because it hinges on application-specific data flow. Net: patch on a normal maintenance cadence; this is a genuine but lower-urgency availability issue, not a drop-everything event. Note the tension between the GHSA text (out-of-bounds read AND write, CWE-787) and the official impact metrics (C:N/I:N/A:H); the broader memory-safety wording could in principle imply disclosure/corruption, but only JVM crash is documented as the outcome - verify with vendor if confidentiality/integrity impact matters for your threat model.

An application decompresses attacker-supplied data through SnappyInputStream (or calls Snappy.arrayCopy / typed-array read/write with attacker-influenced offsets or lengths). A crafted negative or oversized byteLength - or a typed-array byte-size calculation that overflows int - is passed straight to native memcpy, which reads or writes outside the array bounds and crashes the JVM. No public exploit code was identified; reachability depends on whether the host application exposes caller-controlled ranges to untrusted input, consistent with the AC:H rating.