[dependabot]

Bumps org.xerial.snappy:snappy-java from 1.1.10.5 to 1.1.10.12 in openam-cassandra/pom.xml (dependencyManagement), clearing Dependabot alerts #386, #387 and #388. Dependabot proposed 1.1.10.9, the first release that fixes those three; this PR goes on to 1.1.10.12, because upstream published seven advisories against the 1.1.10.x line on 2026-10-03 and two of them, GHSA-c73m-r934-8qvg and GHSA-6gp7-6wmv-gxqw, are fixed only in 1.1.10.10. Neither of those two is a reviewed entry in the GitHub Advisory Database yet, so no alert has been raised for them. This follows #648, which took the same dependency to 1.1.10.5 for CVE-2023-43642.

Advisories

CVE-2026-90559 / GHSA-wmgv-28fv-894x (fixed in 1.1.10.9) — Out-of-bounds write (CWE-787). Snappy.uncompress(ByteBuffer, ByteBuffer) did not check that the destination had room for the decompressed data. The native decompressor writes as many bytes as the compressed input declares, starting at the destination's position, so a crafted input declaring more than uncompressed.remaining() writes past the end of the direct buffer's off-heap allocation. 1.1.10.9 throws IllegalArgumentException when remaining() is smaller than Snappy.uncompressedLength(compressed) (xerial/snappy-java#739).

CVE-2026-93451 / GHSA-gwq9-9ffj-mvrv (fixed in 1.1.10.9) — Off-by-one error; out-of-bounds write (CWE-193, CWE-787). Snappy.uncompress{Char,Short,Int,Long,Float,Double}Array sized the result by dividing the declared byte length by the element size, but the native code wrote the full byte length, so a length that is not a multiple of the element size wrote up to 7 bytes past the end of the Java array. 1.1.10.9 rejects such lengths with SnappyIOException (#739).

CVE-2026-93452 / GHSA-38f5-hf66-x965 (fixed in 1.1.10.9) — Out-of-bounds read and write (CWE-125, CWE-787). The byte[], typed-array and ByteBuffer variants of Snappy.compress, Snappy.rawCompress and Snappy.rawUncompress passed caller-supplied offsets and lengths to native code unchecked and did not check that the output had Snappy.maxCompressedLength(inputLength) bytes available, so an out-of-range length or offset, or an undersized output buffer, read or wrote outside the arrays. NVD files the compress(ByteBuffer, ByteBuffer) case (xerial/snappy-java#732) as CVE-2026-93452. 1.1.10.9 checks the input ranges and the output space before the native call and throws IllegalArgumentException (#739).

CVE-2026-108106 / GHSA-q233-g92q-qxp6 (fixed in 1.1.10.9) — Allocation of resources without limits; memory allocation with excessive size value (CWE-770, CWE-789). Snappy.uncompress(byte[]), Snappy.uncompressString, the uncompress*Array methods, SnappyInputStream and SnappyFramedInputStream allocate the output at the uncompressed length declared in the first bytes of the input, before decompressing anything, so a few bytes force an allocation of up to 2 GB (OutOfMemoryError), or a NegativeArraySizeException at 2^31 and above. The maxChunkSize limit added for CVE-2023-43642 bounds only the compressed chunk length. 1.1.10.9 makes Snappy.uncompressedLength() reject negative lengths and lengths above 64/3 of the compressed size: the densest Snappy element expands 3 bytes to 64, so no valid stream exceeds that (#739).

CVE-2026-116590 / GHSA-xqrx-qh46-34m7 (fixed in 1.1.10.9) — Improper validation of array index; out-of-bounds write (CWE-129, CWE-787). Snappy.arrayCopy(Object, int, int, Object, int) ran a native memcpy without checking the ranges, and SnappyOutputStream.rawWrite and SnappyInputStream.rawRead, and through them the typed-array write / read methods, pass caller-supplied ranges to it, so a negative or oversized length or offset read or wrote outside the arrays and crashed the JVM. 1.1.10.9 checks both ranges before copying; the stream methods validate offsets and lengths and reject typed-array ranges whose byte size overflows int (xerial/snappy-java#741).

CVE-2026-108104 / GHSA-c73m-r934-8qvg (fixed in 1.1.10.10) — Double free; improper control of a resource through its lifetime (CWE-415, CWE-664). When SnappyFramedInputStream needed larger buffers, it returned the current ones to the buffer pool before allocating the replacements. If the allocation failed, for example with an OutOfMemoryError caused by a large declared chunk length, the stream still referenced the released buffers and close() released them a second time. The default CachingBufferPool does not detect duplicates, so two later streams could receive the same backing array, and one stream's decompressed data could be read or overwritten through another. 1.1.10.10 clears the buffer fields right after release (xerial/snappy-java#747).

GHSA-6gp7-6wmv-gxqw (fixed in 1.1.10.10; no CVE assigned) — Uncontrolled recursion; allocation of resources without limits (CWE-674, CWE-770). SnappyInputStream handled each stream header of concatenated data with a recursive call, so a long run of 16-byte headers overflowed the thread's stack (StackOverflowError), and it allocated the compressed-chunk buffer at the declared chunk size, up to the 512 MiB MAX_CHUNK_SIZE, before reading any chunk data. 1.1.10.10 skips headers in a loop and grows the chunk buffer as data arrives (#747).

	Severity	Affected	Fixed in
GHSA-wmgv-28fv-894x	High — CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)	<= 1.1.10.8	1.1.10.9
GHSA-gwq9-9ffj-mvrv	High — CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)	<= 1.1.10.8	1.1.10.9
GHSA-38f5-hf66-x965	Medium — CVSS 3.1 6.5 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H)	<= 1.1.10.8	1.1.10.9
GHSA-q233-g92q-qxp6	High — CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)	<= 1.1.10.8	1.1.10.9
GHSA-xqrx-qh46-34m7	Medium — CVSS 3.1 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)	<= 1.1.10.8	1.1.10.9
GHSA-c73m-r934-8qvg	High — CVSS 3.1 8.7 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N)	<= 1.1.10.9	1.1.10.10
GHSA-6gp7-6wmv-gxqw	High — CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)	<= 1.1.10.9	1.1.10.10

The ids are those of the upstream repository advisories. Only GHSA-gwq9, GHSA-q233 and GHSA-xqrx are reviewed entries in the GitHub Advisory Database, which is what Dependabot alerts on. CVE-2026-90559, CVE-2026-93452 and CVE-2026-108104 have only unreviewed entries there with no package mapping (GHSA-mrhq-xxpp-qf7j, GHSA-pm27-vjq7-f5fv, GHSA-2xrm-qggp-hr4m), and GHSA-6gp7 has none. Every one of the seven needs code that passes snappy-java untrusted compressed data or caller-controlled ranges.

Impact on OpenAM

snappy-java ships in the WAR (WEB-INF/lib/snappy-java-1.1.10.5.jar). java-driver-core 4.19.2 declares it optional, so openam-cassandra-datastore redeclares it explicitly, and openam-server-only depends on that module and on openam-cassandra-cts. No OpenAM source imports org.xerial.snappy; of the jars in WEB-INF/lib, only java-driver-core references it, from com.datastax.oss.driver.internal.core.protocol.SnappyCompressor.

The driver creates SnappyCompressor only when advanced.protocol.compression = snappy is set. OpenAM's openam-cassandra-datastore/src/main/resources/application.conf does not set it, and the driver's reference.conf leaves it absent (frames uncompressed), so by default snappy-java is never called and its native library is never loaded.

A deployment that turns snappy protocol compression on through its own driver configuration has the driver compress request frames and decompress the response frames of the Cassandra nodes it connects to; no data from OpenAM's HTTP clients reaches the decompressor. The driver's own handling keeps every flaw above out of reach:

• Decompression first runs Snappy.isValidCompressedBuffer over the whole frame, a native pass that allocates nothing and succeeds only if the data decodes to exactly the declared length. Only then does it size the output from Snappy.uncompressedLength and call Snappy.uncompress(byte[], int, int, byte[], int) or Snappy.uncompress(ByteBuffer, ByteBuffer) into a buffer of exactly that size. A frame that declares more than it holds is rejected before any allocation, the destination is never undersized (CVE-2026-90559), and frames are capped by advanced.protocol.max-frame-length (256 MiB) (CVE-2026-108106).
• Compression sizes its output buffer with Snappy.maxCompressedLength of the frame's readable bytes, so neither the ranges nor the output space can be wrong (CVE-2026-93452).
• The driver never calls the typed uncompress*Array methods (CVE-2026-93451), Snappy.arrayCopy (CVE-2026-116590), or any of the stream classes, SnappyInputStream, SnappyOutputStream and SnappyFramedInputStream (CVE-2026-116590, CVE-2026-108104, GHSA-6gp7).

openam-cassandra-embedded (cassandra-all 5.0.7, the embedded Cassandra server) also takes its snappy-java version from this dependencyManagement entry, but it is a test-scoped dependency of the datastore and CTS modules and is not in the WAR.

None of the seven is reachable from OpenAM. The bump is hardening: it takes the jar that ships in the WAR out of every affected range.

Change

openam-cassandra/pom.xml, dependencyManagement: org.xerial.snappy:snappy-java 1.1.10.5 → 1.1.10.12 — Dependabot's commit to 1.1.10.9 and a commit on top to 1.1.10.12. It governs openam-cassandra-datastore, and through it the WAR, and openam-cassandra-embedded. No code change.

Behaviour changes in the new range, none of which touches the driver's code path:

• 1.1.10.8: snappy-java no longer catches OutOfMemoryError internally (Remove the problematic catch of OOM. xerial/snappy-java#647).
• 1.1.10.9: compress throws IllegalArgumentException for an output buffer smaller than maxCompressedLength(n), and uncompress for an undersized destination; uncompressedLength rejects declared lengths above 64/3 of the compressed size; the typed uncompress*Array methods reject misaligned lengths; maxCompressedLength throws SnappyError(TOO_LARGE_INPUT) instead of returning a negative number for inputs of 1,840,700,243 bytes and more. musl is no longer misdetected on glibc systems that also have it installed, the Windows DLLs are built with ASLR and DEP, and the jar declares Automatic-Module-Name: org.xerial.snappy.
• 1.1.10.10: SnappyInputStream grows its chunk buffer as data arrives instead of allocating the declared chunk size up front.
• 1.1.10.11: the output check of compress(ByteBuffer, ByteBuffer) measures capacity() - position() instead of remaining(), which restores Hadoop 3.5.0's SnappyCompressor, which sets the output limit to zero before compressing ((#765) Restore Hadoop ByteBuffer compression compatibility xerial/snappy-java#766).
• 1.1.10.12: SnappyHadoopCompatibleOutputStream accounts for Hadoop's 8-byte block header in its output-space check (Hadoop uses a blockHeaderSize of 8 instead of the normal 4 xerial/snappy-java#768).

Verified:

• snappy-java-1.1.10.12.jar matches the SHA-1 published on Maven Central (c97fdfd953df72ae08be22384a1581ce665c2694)
• the jar still targets Java 8 (class file version 52), and its POM declares no runtime dependencies (test and provided only)
• the published 1.1.10.12 carries the fixes: Snappy has the range, output-space, alignment and uncompressed-length checks (checkArrayRange, checkOutputSpace, checkElementAlignment, checkUncompressedLength, the last with the 64/3 bound), Snappy.arrayCopy checks both ranges before the native copy, SnappyFramedInputStream clears its buffer fields right after releasing them, and SnappyInputStream.hasNextChunk() no longer calls itself
• SnappyCompressor in java-driver-core 4.19.2 calls only maxCompressedLength, the compress(ByteBuffer, ByteBuffer) and compress(byte[], int, int, byte[], int) overloads, isValidCompressedBuffer, uncompressedLength and the two uncompress overloads above; it validates before it allocates and sizes every output buffer itself
• among the jars in the built WAR's WEB-INF/lib, only java-driver-core references org.xerial.snappy
• openam-cassandra-embedded, openam-cassandra-datastore and openam-cassandra-cts resolve snappy-java 1.1.10.12; mvn verify of the four openam-cassandra modules passes on JDK 11, where the jdk-15-cassandra profile does not skip the tests: 29 tests, 0 failures, with the datastore and CTS tests running against the embedded Cassandra server
• the GitHub Advisory Database lists no advisory affecting snappy-java@1.1.10.12

References

• GHSA-wmgv-28fv-894x
• GHSA-gwq9-9ffj-mvrv
• GHSA-38f5-hf66-x965
• GHSA-q233-g92q-qxp6
• GHSA-xqrx-qh46-34m7
• GHSA-c73m-r934-8qvg
• GHSA-6gp7-6wmv-gxqw
• https://nvd.nist.gov/vuln/detail/CVE-2026-90559
• https://nvd.nist.gov/vuln/detail/CVE-2026-93451
• https://nvd.nist.gov/vuln/detail/CVE-2026-93452
• https://nvd.nist.gov/vuln/detail/CVE-2026-108106
• https://nvd.nist.gov/vuln/detail/CVE-2026-116590
• https://nvd.nist.gov/vuln/detail/CVE-2026-108104
• Fix buffer overflows and unbounded allocations from untrusted input (CVE-2026-90559 and others) xerial/snappy-java#739
• Validate maxCompressedLength overflow and stream array ranges (#671, #513) xerial/snappy-java#741
• Fix stream buffer double release, header recursion, and eager chunk allocation xerial/snappy-java#747
• (#765) Restore Hadoop ByteBuffer compression compatibility xerial/snappy-java#766
• Hadoop uses a blockHeaderSize of 8 instead of the normal 4 xerial/snappy-java#768
• xerial/snappy-java@v1.1.10.5...v1.1.10.12