IsAffected panics on an advisory with an unrecognized ecosystem, crashing the whole scan

[Lougarou]

Summary

vulns.IsAffected panics when an OSV advisory's affected[].package.ecosystem is a value that osvecosystem.MustParse does not recognize. Because IsAffected is called for every advisory on the match path, a single such advisory aborts the entire scan instead of being skipped.

Affected code

• internal/utility/vulns/vulnerability.go:160 (and :113 in AffectsEcosystem):

  if osvecosystem.MustParse(affected.GetPackage().GetEcosystem()).Equal(imodels.Ecosystem(pkg)) && ...

  osvecosystem.MustParse panics (Failed MustParse: base ecosystem does not exist in osvschema: "…") on any unrecognized ecosystem string.
• Reached from the normal local-DB match path: internal/clients/clientimpl/localmatcher/zip.go:304 → VulnerabilitiesAffectingPackage → IsAffected, which loops over v.GetAffected() and calls MustParse on each entry.

Reproduction

A recognized-ecosystem package matched against a multi-ecosystem advisory where one affected[] entry uses an ecosystem the build's vendored osv-schema doesn't know. The package isn't in-range for the known entry, so IsAffected falls through to the unknown entry and panics:

vuln := &osvschema.Vulnerability{
    Id: "EXAMPLE-multi",
    Affected: []*osvschema.Affected{
        { // npm entry the package is NOT in-range for (5.0.0 <= v < 6.0.0)
            Package: &osvschema.Package{Ecosystem: "npm", Name: "my-package"},
            Ranges:  []*osvschema.Range{{Type: osvschema.Range_ECOSYSTEM,
                Events: []*osvschema.Event{{Introduced: "5.0.0"}, {Fixed: "6.0.0"}}}},
        },
        { // ecosystem the vendored osv-schema does not know
            Package: &osvschema.Package{Ecosystem: "SomeFutureEcosystem", Name: "other"},
            Ranges:  []*osvschema.Range{{Type: osvschema.Range_ECOSYSTEM,
                Events: []*osvschema.Event{{Introduced: "0"}, {Fixed: "2.0.0"}}}},
        },
    },
}
pkg := &extractor.Package{Name: "my-package", Version: "1.0.0", PURLType: purl.TypeNPM}
vulns.IsAffected(vuln, pkg) // panics: base ecosystem does not exist in osvschema: "SomeFutureEcosystem"

Why it's reachable (no attacker required)

OSV advisories routinely list multiple ecosystems in affected[], and a per-ecosystem DB zip stores the full advisory record (all affected[] entries, not just the matching one). The vendored osv-schema ecosystem registry is pinned per osv-scanner release, while osv.dev's ecosystem set evolves over time. So once osv.dev introduces a new ecosystem that appears in a multi-ecosystem advisory, older osv-scanner builds still pinned in CI will panic on it — a forward-compatibility availability problem with a broad blast radius for a tool that runs in many CI pipelines. It is also deterministically triggerable today with a custom/local advisory database.

Relationship to #2831 / #2837

#2837 fixed the version-parser panic — semantic.Parse is now skipped gracefully for ecosystems that have no version parser (e.g. GitHub Actions). This is a different, still-present site: the ecosystem-name osvecosystem.MustParse at vulnerability.go:113 and :160 was not changed and still panics on an unrecognized ecosystem string.

Suggested fix

Use the non-panicking osvecosystem.Parse and skip the affected[] entry on error — the same "skip, don't panic on unsupported ecosystems" approach taken in #2837. The default (recognized) path is unaffected.

I have a fix and a reproducing test ready, and would be happy to open a PR once this is assigned.

---

_{This was found via automated state-space analysis and confirmed with a reproducing Go test against the current main.}

[G-Rath]

can you provide a real-world reproduction for this? i.e. using the scanner CLI or public library, rather than a crafted Go reproduction that is calling the internal library directly

[Lougarou]

Sure, here's an end-to-end reproduction driven entirely through the public CLI (no internal calls), using the documented offline-database feature. It panics and aborts the whole scan.

Upfront on scope: this reproduces via the offline path with a local/custom OSV DB (a supported --local-db-path config), not the live osv.dev DB today. I scanned the current real exports (npm: 220,201 records, PyPI: 20,315) and none reference an ecosystem this build doesn't recognize, so the downloaded DB won't trigger it right now. The only unrecognized ecosystems osv.dev currently serves (GSD, UVI) are single-ecosystem records a normal scan never loads. So it's a latent forward-compatibility crash: the ecosystem registry is pinned per release (v2.3.8 knows 48), and any advisory referencing an ecosystem added to osv.dev after a build's pin will hit this once it lands in a scannable ecosystem's zip. It's also deterministic today for anyone pointing the scanner at a self-maintained DB.

Repro

Run from the repo root (only needs python3, to build the zip):

WORK="$(mktemp -d)"

# 1) a normal npm lockfile to scan
mkdir -p "$WORK/target"
cat > "$WORK/target/package-lock.json" <<'EOF'
{ "name":"app","version":"1.0.0","lockfileVersion":3,"requires":true,
  "packages":{ "":{"name":"app","version":"1.0.0","dependencies":{"my-package":"1.0.0"}},
               "node_modules/my-package":{"version":"1.0.0"} } }
EOF

# 2) a local offline DB in osv.dev's own export format: one valid OSV record with
#    two affected[] entries. my-package@1.0.0 matches the npm entry by NAME (so the
#    record is loaded) but is NOT in its range, so IsAffected falls through to the
#    second entry, whose ecosystem "GSD" is a real ecosystem osv.dev ships today
#    but that this build's pinned osv-schema doesn't recognize.
python3 - "$WORK/db" <<'PY'
import json,os,sys,zipfile
out=sys.argv[1]
adv={"id":"CB-REPRO","affected":[
 {"package":{"ecosystem":"npm","name":"my-package"},
  "ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.0.0"},{"fixed":"6.0.0"}]}]},
 {"package":{"ecosystem":"GSD","name":"GSD-2024-1000000"},
  "ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.0.0"}]}]}]}
zp=os.path.join(out,"osv-scanner","npm","all.zip"); os.makedirs(os.path.dirname(zp),exist_ok=True)
zipfile.ZipFile(zp,"w",zipfile.ZIP_DEFLATED).writestr("CB-REPRO.json",json.dumps(adv))
print("wrote",zp)
PY

# 3) scan with the real CLI, offline, against the local DB
go run ./cmd/osv-scanner scan source \
  --offline-vulnerabilities --local-db-path "$WORK/db" "$WORK/target"

Output (v2.3.8, main)

Scanned .../target/package-lock.json file and found 1 package
Loaded npm local db from .../db/osv-scanner/npm/all.zip
panic: Failed MustParse: base ecosystem does not exist in osvschema: "GSD"

goroutine 1 [running]:
.../osvecosystem.MustParse(...)            parsed.go:162
.../vulns.IsAffected(...)                  vulnerability.go:160
.../localmatcher.VulnerabilitiesAffectingPackage(...)  zip.go:304
.../localmatcher.(*LocalMatcher).MatchVulnerabilities(...)  localmatcher.go:99
.../pkg/osvscanner.makeVulnRequestWithMatcher(...)  osvscanner.go:502
.../pkg/osvscanner.DoScan(...)             osvscanner.go:221
.../scan/source.action(...)                command.go:140
main.main()                                main.go:15

[rohan-patnaik]

I’m interested in helping with this, but I saw that you already mentioned having a fix ready.

I had opened a PR(#2879) before checking the contributing guide, and it was closed for it, sorry for that. If you’re already planning to send your fix ,great. If not, I’d be happy to rework my closed PR based on any maintainer requirements and only open a new PR if assigned(to me)

[another-rex]

Assigned to you now @Lougarou, feel free to submit your fix PR.

I’m interested in helping with this, but I saw that you already mentioned having a fix ready.

Since @Lougarou made the issue and expressed interest in working on it I'll give him a chance to make the PR first.