Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

zstd-jni CVEs (CVE-2026-87795 and 8 others) have only GIT ranges, so they are missing from Maven/all.zip and Maven queries

オープン
#6,148 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go

調査の方向性

Start by tracing how OSV converts CVE List records with GIT ranges and how Maven package queries and exports are populated; the issue names no source files or tests. Compare the affected zstd-jni records with existing Maven mappings and determine how to represent the artifact safely. Done means the nine records appear in Maven exports and vulnerable Maven queries, with regression coverage for the mapping.

索引モデルが issue の本文から書いたものです。

説明

Describe the bug
Nine CVEs published in September 2026 against com.github.luben:zstd-jni (fixed in 1.5.7-14) exist in OSV only as records generated from the CVE List, each with a GIT range on https://github.com/luben/zstd-jni and no package. None has an affected entry for the Maven package, so:

  • Maven/all.zip contains none of them, and doesn't contain the string zstd-jni at all.
  • A Maven-ecosystem query for a vulnerable version (for example 1.5.7-2) returns no vulnerabilities.

So tools that check Maven dependencies against OSV report vulnerable zstd-jni versions as clean, while other CVE scanners flag the same artifacts.

The affected records are all in GIT/all.zip, with osv_generated_from pointing at CVEProject/cvelistV5:

OSV id CNA aliases extracted range
CVE-2026-87795 VulnCheck GHSA-ff36-7w3w-g8rm introduced 1.2.0, fixed 1.5.7-14
CVE-2026-87823 VulnCheck GHSA-jfr6-9xqw-2g2q introduced 1.1.1, fixed 1.5.7-14
CVE-2026-87824 VulnCheck GHSA-257p-3h6w-pg7h introduced 1.3.3-1, fixed 1.5.7-14
CVE-2026-87825 VulnCheck GHSA-947w-pxjj-c7m9 introduced 1.3.8-4, fixed 1.5.7-14
CVE-2026-87877 VulnCheck GHSA-2jw3-mg7f-vw4q introduced 1.3.8-4, fixed 1.5.7-14
CVE-2026-89045 VulnCheck GHSA-9jx2-gfp9-phfm introduced 1.4.8-4, fixed 1.5.7-14
CVE-2026-89046 VulnCheck GHSA-rm53-6wf5-f34m introduced 1.5.5-6, fixed 1.5.7-14
CVE-2026-90560 VulnCheck (none) introduced 1.2.0, fixed 1.5.7-14
CVE-2026-90852 VulDB (none) introduced 1.5.7-13, last_affected 1.5.7-13

To Reproduce
Steps to reproduce the behaviour:

  1. Query OSV for a vulnerable version as a Maven package. No vulnerabilities come back:
    curl -s -X POST https://api.osv.dev/v1/query \
      -d '{"package":{"name":"com.github.luben:zstd-jni","ecosystem":"Maven"},"version":"1.5.7-2"}'
    # => {}
    
  2. Query the same version as a GIT tag. The CVEs come back:
    curl -s -X POST https://api.osv.dev/v1/query \
      -d '{"package":{"name":"https://github.com/luben/zstd-jni","ecosystem":"GIT"},"version":"v1.5.7-2"}' | jq '[.vulns[].id]'
    # => ["CVE-2026-87795","CVE-2026-87823","CVE-2026-87824","CVE-2026-87825",
    #     "CVE-2026-87877","CVE-2026-89045","CVE-2026-89046","CVE-2026-90560"]
    
  3. Search the Maven export (last-modified 2026-10-08). There are no matches:
    curl -s -o Maven-all.zip https://osv-vulnerabilities.storage.googleapis.com/Maven/all.zip
    unzip -p Maven-all.zip | grep -c -e 'zstd-jni' -e 'CVE-2026-87795'
    # => 0
    
  4. Look up one of the GHSA aliases. It doesn't resolve:
    curl -s https://api.osv.dev/v1/vulns/GHSA-ff36-7w3w-g8rm
    # => {"code":5,"message":"Vulnerability not found, but the following aliases were: CVE-2026-87795"}
    

Expected behaviour
These CVEs affect the Maven artifact com.github.luben:zstd-jni. github.com/luben/zstd-jni is that artifact's source repository, and its v<version> tags match the Maven versions one to one. We expected the records to be in Maven/all.zip and returned by Maven-ecosystem queries, through either:

  • an affected entry {"ecosystem": "Maven", "name": "com.github.luben:zstd-jni"} with ECOSYSTEM ranges (introduced: <x>, fixed: 1.5.7-14); or
  • an import of the GHSA advisories listed as aliases, if they carry the Maven mapping.

Screenshots
N/A. The commands above show the behaviour.

Additional context

  • The aliases don't resolve. Seven of the records list GHSA aliases, but OSV has no records for those IDs, and GitHub's public advisory API (GET https://api.github.com/advisories/GHSA-ff36-7w3w-g8rm) returns 404. So no OSV import path supplies the Maven mapping today.
  • Impact. Anything that checks Maven dependencies against Maven/all.zip or Maven-ecosystem queries (the documented approach for Maven) misses all of these CVEs. zstd-jni is a widely used transitive dependency. The same gap probably affects any CVE-List-only record whose upstream is a Git repo that publishes to Maven Central.
  • A separate data issue found while investigating. CVE-2026-90852's range is narrower than its own description. The description says "luben zstd-jni up to 1.5.7-13" and "Upgrading to version 1.5.7-14 is able to resolve this issue". But the CNA's (VulDB's) structured affected field lists only {"version": "1.5.7-13", "status": "affected"} and {"version": "1.5.7-14", "status": "unaffected"}. OSV's conversion follows the structured field, giving introduced: 1.5.7-13, last_affected: 1.5.7-13, so earlier versions such as 1.5.7-2 don't match even with a GIT query. This looks like a problem in the source record rather than in OSV's conversion. We mention it because it makes OSV and NVD-based scanners disagree about which versions are affected.
主要言語
Go
スター
3k
フォーク
382
平均マージ
1日 12時間
マージ済み PR(30日)
110

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

google/osv.dev のほかの issue

google/osv.dev の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。