Hacktoberfest 2026：维护者为十月标记出来的 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 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
databases, security

调研方向

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 天 9 小时
30 天内合并 PR
136

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

google/osv.dev 的其他 Issue

查看 google/osv.dev 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。