-
CVSS Score
-Basic Information
CVE ID
-
GHSA ID
-
EPSS Score
-
CWE
-
Published
-
Updated
-
KEV Status
-
Technology
-
Technical Details
Vulnerability Intelligence
Miggo AI
Miggo AIMiggo AI| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| com.squareup.okio:okio | maven | >= 2.0.0-RC1, < 3.4.0 | 3.4.0 |
| com.squareup.okio:okio | maven | < 1.17.6 | 1.17.6 |
| com.squareup.okio:okio-jvm | maven | >= 2.0.0-RC1, < 3.4.0 | 3.4.0 |
JavaJavaMiggo AIRoot Cause AnalysisThe vulnerability lies in the misinterpretation of the 'xlen' field in the GZIP header, treating it as signed instead of unsigned. This leads to an exception when xlen is large (e.g. >= 0x8000), which GzipSource fails to handle, resulting in a Denial of Service.
Two commits were analyzed:
b4fa875dc24950680c386e4b1c593660ce4f7839 (Java version): The patch clearly modifies the consumeHeader() method within okio.GzipSource to correctly interpret xlen as an unsigned value (& 0xffff). This method directly contains the vulnerable logic.81bce1a30af244550b0324597720e4799281da7b (Kotlin version): The patch modifies header processing logic within the okio.GzipSource class to correctly interpret xlen by converting to Int, masking with 0xffff, and then converting to Long. While the specific private method name for header parsing isn't shown in the diff, this logic is invoked during the execution of the public read() method. The read() method is the entry point for processing the GZIP stream and is where the unhandled exception would ultimately manifest from, due to the faulty xlen interpretation in the code it calls.Both identified functions are directly involved in the vulnerable processing of the xlen field. The Java version explicitly names consumeHeader. For the Kotlin version, read is the public API that orchestrates the vulnerable header parsing logic shown in the patch.
Ongoing coverage of React2Shell