OESA-2026-4078 (CVE-2026-59949)

Vulnerability from osv_openeuler – Published: 2026-09-25 01:28 – Updated: 2026-09-25 01:28 – Source website
VLAI
Summary
lz4-java security update
Details

LZ4 compression for Java, based on Yann Collet's work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4): ° low memory footprint (~ 16 KB), ° very fast (fast scan with skipping heuristics in case the input looks incompressible), ° reasonable compression ratio (depending on the redundancy of the input). * high compression (LZ4 HC): ° medium memory footprint (~ 256 KB), ° rather slow (~ 10 times slower than LZ4), ° good compression ratio (depending on the size and the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.

Security Fix(es):

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)


{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "lz4-java-1.8.0-3.oe2403sp3.aarch64.rpm"
        ],
        "noarch": [
          "lz4-java-javadoc-1.8.0-3.oe2403sp3.noarch.rpm"
        ],
        "src": [
          "lz4-java-1.8.0-3.oe2403sp3.src.rpm"
        ],
        "x86_64": [
          "lz4-java-1.8.0-3.oe2403sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "lz4-java",
        "purl": "pkg:rpm/openEuler/lz4-java\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.0-3.oe2403sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Medium"
  },
  "details": "LZ4 compression for Java, based on Yann Collet\u0026amp;apos;s work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4):     \u00b0 low memory footprint (~ 16 KB),     \u00b0 very fast (fast scan with skipping heuristics in case the       input looks incompressible),     \u00b0 reasonable compression ratio (depending on the       redundancy of the input). * high compression (LZ4 HC):     \u00b0 medium memory footprint (~ 256 KB),     \u00b0 rather slow (~ 10 times slower than LZ4),     \u00b0 good compression ratio (depending on the size and       the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.\r\n\r\nSecurity Fix(es):\n\nyawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)",
  "id": "OESA-2026-4078",
  "modified": "2026-09-25T01:28:09Z",
  "published": "2026-09-25T01:28:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59949"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lz4-java security update",
  "upstream": [
    "CVE-2026-59949"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…