osv-scanner scan image reports no CVEs for alpine:3.19 musl, but Alpine's own tracker lists it as vulnerable

[mcho421]

Describe the bug

osv-scanner scan image returns no findings for musl when scanning the current alpine:3.19 image, but the installed musl-1.2.4_git20230717-r5 is listed as vulnerable to ALPINE-CVE-2026-40200 (and two other CVEs) by Alpine's own security tracker, by the OSV record itself, and by Docker Hub's image scan.

To Reproduce

1. Run the scan:

   osv-scanner scan image --format vertical alpine@sha256:6baf43584bcb78f2e5847d1de515f23499913ac9f12bdf834811a3145eb11ca1

2. Observe that no musl vulnerabilities are reported.
3. Confirm the installed musl version in the same image:

   docker run --rm alpine@sha256:6baf43584bcb78f2e5847d1de515f23499913ac9f12bdf834811a3145eb11ca1 apk list musl
   # musl-1.2.4_git20230717-r5 aarch64 {musl} (MIT) [installed]

4. Compare against:
   • Alpine security tracker: https://security.alpinelinux.org/vuln/CVE-2026-40200 (lists v3.19 fix as 1.2.4_git20230717-r6)
   • OSV record: https://osv.dev/vulnerability/ALPINE-CVE-2026-40200
   • Docker Hub scan for alpine:3.19: https://hub.docker.com/layers/library/alpine/3.19/images/sha256-45470a1b6b2bb3c200494c9caff4796ad4379e8a9090d4f664cf7f6c5052cbd6

Expected behaviour

osv-scanner scan image should report ALPINE-CVE-2026-40200 (and ALPINE-CVE-2025-26519, ALPINE-CVE-2026-6042) against the installed musl-1.2.4_git20230717-r5.

Screenshots

N/A — output above.

Additional context

The miss appears to reproduce against the OSV.dev API directly (i.e. without osv-scanner in the loop), so this may be upstream of the scanner. Sharing in case it helps triage; the analysis below was put together with help from an AI assistant and may be wrong.

# Installed version → empty
curl -sS -X POST \
  -d '{"package":{"name":"musl","ecosystem":"Alpine:v3.19"},"version":"1.2.4_git20230717-r5"}' \
  https://api.osv.dev/v1/query
# {}

# Same package, version with the `_git20230717` qualifier stripped → three CVEs
curl -sS -X POST \
  -d '{"package":{"name":"musl","ecosystem":"Alpine:v3.19"},"version":"1.2.4-r5"}' \
  https://api.osv.dev/v1/query
# returns ALPINE-CVE-2025-26519, ALPINE-CVE-2026-40200, ALPINE-CVE-2026-6042

# Older non-`_git` version also matches as expected
curl -sS -X POST \
  -d '{"package":{"name":"musl","ecosystem":"Alpine:v3.19"},"version":"1.2.3-r4"}' \
  https://api.osv.dev/v1/query
# returns the same three CVEs

Sweep across _git revisions — none match, regardless of whether they should fall inside or outside the affected range:

query version (Alpine:v3.19, musl)	matches CVE-2026-40200 (range [0, 1.2.4_git20230717-r6))?
1.2.4_git20230717-r0	no (would expect yes)
1.2.4_git20230717-r5	no (would expect yes)
1.2.4_git20230717-r6	no (correct — fixed)
1.2.4_git20230717-r99	no (correct — past fix)

Inspecting the OSV record itself, the Alpine:v3.19 entry has an ECOSYSTEM range with fixed: 1.2.4_git20230717-r6, but its affected[].versions enumeration is 223 entries long and contains no _git-qualified versions at all. ALPINE-CVE-2025-26519 (fix 1.2.4_git20230717-r5) has the same shape.

If that observation is right, it would suggest that versions carrying apk pre/post qualifiers (_git, and presumably _alpha, _beta, _pre, _rc, _p) aren't being matched against ECOSYSTEM ranges for the Alpine ecosystem — which would mean every current alpine:3.19 image is reported clean for these musl CVEs. I haven't read the importer or matcher code, so this part is a guess.

[Nick-Bug-Bounty-Hunter]

Hi maintainers — I took a quick look at this report and it seems plausible that the miss is upstream of osv-scanner, likely in Alpine ingest or version-range handling on the osv.dev side. If that matches your expectations, I can dig in and prepare a draft PR with a regression test rather than guessing at the right fix path.

[michaelkedar]

This seems to be an issue with the Python Alpine Linux version parser we use considering these strings invalid (for some reason - _alpha, _beta, _pre, _rc, _p seem to parse without error).

That vendored code might be quite out of date, but I haven't checked if the latest code upstream has this issue or not.

We're planning to migrate the API to Go soon, which will use this helper which defers to the semantic implementation in osv-scalibr. semantic is very lenient in what it accepts, so I suspect this issue will be fixed automatically by the move to go.

Since the Go migration is happening soon, I don't think it's worth trying to fix in the Python version.

[Nick-Bug-Bounty-Hunter]

Thanks, that makes sense.