Xerial snappy-java: Unbeschränkte Speicherreservierung führt zu Denial of Service

Zusammenfassung

snappy-java vor Version 1.1.10.9 reserviert Ausgabepuffer anhand einer unkomprimierten Länge, die in den komprimierten Eingabedaten angegeben ist, bevor die Daten geprüft werden. Ein entfernter Angreifer kann mit wenigen präparierten Bytes die betroffenen Dekomprimierungsmethoden veranlassen, bis zu 2 GB Speicher zu reservieren, was zu einem OutOfMemoryError und einem Denial of Service in der Java-Anwendung führt. Die Exposition hängt davon ab, ob ein Java-Dienst unvertrauenswürdige Daten dekomprimiert; laut CVSS-Vektor sind weder Codeausführung noch Datenabfluss möglich.

Betroffen

• Xerial snappy-java Versionen vor 1.1.10.9 (alle Versionen unterhalb von 1.1.10.9)
• Betroffene Methoden umfassen Snappy.uncompress, uncompressString, die uncompress*Array-Methoden, SnappyInputStream und SnappyFramedInputStream
• Transitive Abhängigkeiten, zum Beispiel in Kafka-Clients, Spark oder Avro, können die betroffene Bibliothek enthalten

Behoben in

• Aktualisierung auf snappy-java 1.1.10.9 oder neuer; empfohlen wird die neueste 1.1.10.x-Version
• Herstellerfix in Release v1.1.10.9 (Behebung von Pufferüberläufen und unbeschränkten Allokationen aus unvertrauenswürdigen Eingaben)

Umgehung

• Vor der Dekomprimierung unvertrauenswürdiger Daten den Wert von Snappy.uncompressedLength(input) gegen ein anwendungsspezifisches Maximum prüfen (Sekundärquelle, gegen die Herstellerwarnung verifizieren)
• Speicher des Prozesses oder die JVM-Heap-Grösse begrenzen, um die Auswirkungen einzudämmen; dies ist keine Behebung
• Bestehende Limits für CVE-2023-43642 verhindern dieses Problem nicht

Ausnutzung

• CISA SSVC: Exploitation none, Automatable yes, Technical Impact partial
• In den geprüften Quellen keine Berichte über Ausnutzung in freier Wildbahn und kein öffentlicher Proof-of-Concept gefunden; CISA KEV wurde nicht direkt geprüft

Unsere Empfehlung

• Java-Anwendungen und Herstellerprodukte auf snappy-java inventarisieren, einschliesslich transitiver Abhängigkeiten in SBOMs und Maven-/Gradle-Dateien
• Mindestens auf 1.1.10.9 aktualisieren, vorzugsweise auf die neueste 1.1.10.x-Version
• Aus dem Internet erreichbare Java-Dienste priorisieren, die unvertrauenswürdige Daten dekomprimieren
• Die uncompressedLength-Prüfung als Zwischenmassnahme anwenden, wenn das Patchen verzögert ist
• Logs auf OutOfMemoryError-Ereignisse überwachen

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• Vendor advisory GHSA-q233-g92q-qxp6 github.com
• Release v1.1.10.9 github.com
• OSV CVE-2026-108106 osv.dev
• Ubuntu security notice ubuntu.com
• GitLab advisory advisories.gitlab.com
• VulnCheck advisory www.vulncheck.com

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 05:08.