Data quality issue with ALPINE-CVE-2018-18311 / -18312 (inverted version range, false positives)

[uluzox]

Affected records

• ALPINE-CVE-2018-18311
• ALPINE-CVE-2018-18312

Problem

Both records carry an inverted version range on every Alpine branch:

"events": [ { "introduced": "5.28.0" }, { "fixed": "5.26.3-r0" } ]

The fixed version (5.26.3-r0) sorts below the introduced version (5.28.0), so the
range x >= 5.28.0 AND x < 5.26.3-r0 is unsatisfiable. Scanners drop the invalid fixed
event and flag all perl >= 5.28.0 as vulnerable — including current perl 5.42.2-r0
on Alpine v3.24 — for a 2018 CVE that was fixed in perl 5.26.3.

Source JSON:

• https://storage.googleapis.com/cve-osv-conversion/alpine/ALPINE-CVE-2018-18311.json
• https://storage.googleapis.com/cve-osv-conversion/alpine/ALPINE-CVE-2018-18312.json

Evidence the range is wrong

Alpine's own secdb records the fix at 5.26.3-r0, and the current branch ships 5.42.2-r0:

# https://secdb.alpinelinux.org/v3.24/main.json  (pkg: perl)
"secfixes": {
  "5.26.3-r0": ["CVE-2018-18311", "CVE-2018-18312", "CVE-2018-18313", "CVE-2018-18314"],
  ...
  "5.42.2-r0": [...]        # current version on v3.24
}

The advisory text itself states "Perl before 5.26.3 and 5.28.x before 5.28.1", so
perl 5.42.2 is not affected.

Suggested correction (all Alpine branches)

"events": [ { "introduced": "0" }, { "fixed": "5.26.3-r0" } ]

Likely root cause

The alpine converter (vulnfeeds/cmd/converters/alpine) appears to have taken introduced
from the NVD CPE range (5.28.x) instead of emitting introduced: 0 for a secfix-only
advisory, then paired it with the Alpine secfix 5.26.3-r0 — two different perl branches
(5.26.x vs 5.28.x) merged into one inverted range. The sibling records ALPINE-CVE-2018-18313
and ALPINE-CVE-2018-18314 share the same secfix line and are worth checking for the same
defect.

This is the same class of malformed-Alpine-range false positive as #4165.

[uluzox]

Same converter defect, additional affected records (different trigger in the Alpine secdb, identical broken-range symptom). While triaging an Alpine-based image fleet I hit three more ALPINE-CVE-* records where a current package is flagged for a long-fixed CVE because the converted range is unsatisfiable:

Record	OSV range (Alpine:v3.24)	Installed (v3.24)	Alpine secdb ground truth
ALPINE-CVE-2022-1292 (openssl)	introduced: 1.0.2, fixed: 0	openssl 3.5.7-r0	fixed in 0 (= not affected in branch)
ALPINE-CVE-2023-4807 (openssl)	introduced: 1.1.1, fixed: 0	openssl 3.5.7-r0	fixed in 0
ALPINE-CVE-2020-14387 (rsync)	introduced: 3.2.1, fixed: 0	rsync 3.4.3-r1	fixed in 0

Source: https://secdb.alpinelinux.org/v3.24/main.json (openssl/rsync secfixes list these CVEs only under version 0, i.e. never-affected-in-branch).

Root cause looks identical to the perl records in this issue: the alpine converter combines an introduced derived from the upstream NVD/CPE range with the Alpine secfix value, without validating that the result is a coherent range for that branch. Two observed variants:

• perl (this issue): secdb has a real fix (5.26.3-r0) -> converter adds a spurious higher introduced (5.28.0) -> inverted range (fixed < introduced).
• openssl / rsync (above): Alpine secdb uses the fixed in 0 not-affected sentinel -> converter emits a literal fixed: 0 event paired with an NVD-derived introduced -> unsatisfiable x >= introduced AND x < 0.

In both variants a matcher discards the invalid fixed event and treats every version >= introduced as affected, so current packages (openssl 3.5.7, rsync 3.4.3) get false-positived. This is the same family as the closed #4165 (zlib, introduced: 0, fixed: 0), which suggests the fixed: 0 sentinel handling either regressed or was never fully addressed in the converter.

Suggested fix (covers both variants): when the Alpine secfix for a branch is the 0 not-affected sentinel, emit no affected range for that branch instead of a fixed: 0 event; and do not synthesize an introduced from NVD unless it is validated against the Alpine secfix version for that branch.