Android apps match CVEs with an unversioned "vulnerable" Android OS entry at any version (Firefox for Android gets CVE-2017-7759 on 145.0) since android_apps got target_sw=android #58685

Fleet versions

• Discovered: rc-minor-fleet-v4.95.0 @ 728f6f2b47 (server 4.95.0-rc.2611101952), local NVD data synced 2026-11-13, while QAing False positive CVEs: VLC for Android CVE-2026-26227 and CVE-2026-26228 match desktop VLC #55057 / Ignore VLC for Android CVEs on non-Android VLC #55058. Unreleased: the android_apps → target_sw=android change (Ignore VLC for Android CVEs on non-Android VLC #55058, 8daf266734) is on main and the 4.95 branch only.
• Reproduced: same build with the nvdvuln harness at three Firefox versions; macOS Firefox as control; parent commit 6334a951c6 as pre-change control.

Web browser and operating system: N/A (vulnerability processing)

💥 Actual behavior

Since #55058, Android apps get CPEs with target_sw=android. The CVE matcher's OS shortcut (matchTargetSW in server/vulnerabilities/nvd/tools/cvefeed/nvd/match_cpe.go) turns an application CPE's target_sw into a synthetic OS CPE (o:*:android) and treats any vulnerable, unversioned cpe:2.3:o:google:android:-:*… / …:*:*… entry in a CVE's configuration as a match. Before #55058 Android apps carried target_sw=*, so the shortcut never fired for them; now it does, and the version range on the application entry in the same configuration is never consulted.

Observed with Firefox for Android (android_apps, application_id=org.mozilla.firefox): CVE-2017-7759 (Firefox < 54.0 on Android) is reported at 145.0, 60.0 and 53.0 alike. macOS Firefox 145.0 (apps) does not get it, and the pre-change tree does not either.

# RC (with #55058), harness patched to pass application_id for android_apps
Firefox 145.0 android_apps -> cpe:2.3:a:mozilla:firefox:145.0:*:*:*:*:android:*:*  545 CVEs, CVE-2017-7759 present
Firefox  60.0 android_apps -> ... 1546 CVEs, CVE-2017-7759 present
Firefox  53.0 android_apps -> ... 1701 CVEs, CVE-2017-7759 present
Firefox 145.0 apps (macOS) -> cpe:2.3:a:mozilla:firefox:145.0:*:*:*:*:macos:*:*    543 CVEs, CVE-2017-7759 absent
# parent commit 6334a951c6
Firefox 145.0 android_apps -> cpe:2.3:a:mozilla:firefox:145.0:*:*:*:*:*:*:*        551 CVEs, CVE-2017-7759 absent

NVD configuration for CVE-2017-7759 (one node, two vulnerable entries):

cpe:2.3:a:mozilla:firefox:*:*:*:*:*:*:*:*   versionEndExcluding 54.0
cpe:2.3:o:google:android:-:*:*:*:*:*:*:*    (no version)

Size of the exposure, from a census of the local NVD feed (all years): 2,060 CVEs carry a vulnerable unversioned o:*:android entry; 41 of those also name an application product; of the application products, mozilla:firefox appears 5 times (e.g. CVE-2012-3979, CVE-2017-7759), the rest are Adobe Flash/AIR and unrelated server products. Candidate CVEs are selected by the app's own product, so the ~2,000 OS-only entries do not attach to apps — the "android" OS package exclusion in #55058 is what keeps them off the Android System row. Chrome for Android is unaffected (0 of its 63 Android-only matches come from OS entries).

Net, the #55058 change is still an improvement for Android apps — it fixes Chrome for Android's CPE (previously 360:chrome, 0 CVEs) and drops 7 iPhone-only Firefox CVEs — but it introduces this small class of version-blind false positives.

🛠️ Expected behavior

An Android app only matches a CVE when its own application entry matches (vendor/product/version range). A vulnerable, unversioned o:google:android entry in the same configuration should not by itself flag the app at every version. Options: skip the OS shortcut when the configuration also contains an application entry for the software's product and that entry has a version range; or don't apply matchTargetSW for target_sw=android at all, since the Android OS is never the software being scanned (OS vulns come from the Android OSV artifacts).

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
• Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.

1. Check out main or rc-minor-fleet-v4.95.0 (contains 8daf266734) with a synced vulnerability DB in /tmp/vulndbs.
2. tools/nvd/nvdvuln has no application_id flag; add one locally (set ApplicationID on the fleet.Software row when -software_source android_apps) or call nvd.CPEFromSoftware + TranslateCPEToCVE from a scratch test with fleet.Software{Name: "Firefox", Version: "145.0", Source: "android_apps", ApplicationID: ptr("org.mozilla.firefox")}.
3. Run it for versions 145.0, 60.0 and 53.0 → CVE-2017-7759 is in every result. Control: -software_name Firefox -software_version 145.0 -software_source apps -software_bundle_identifier org.mozilla.firefox → absent.
4. Repeat from the parent commit 6334a951c6 → absent for android_apps too (CPE has target_sw=*).
5. Live: an Android host with Firefox from Play shows CVE-2017-7759 (and the other 4 old Firefox-for-Android CVEs) on Host details > Software after the vulnerabilities cron.

🕯️ More info (optional)

• Found while QAing False positive CVEs: VLC for Android CVE-2026-26227 and CVE-2026-26228 match desktop VLC #55057 / Ignore VLC for Android CVEs on non-Android VLC #55058; the VLC rule itself works (both CVEs dropped on desktop VLC, kept on Android VLC 3.6.5, gone at 3.7.0).
• Related, opposite failure in the same package: NVD configurations with target_sw=- never match Fleet CPEs that carry a concrete target_sw (Google brotli CVE-2026-111497 missed on Python and Homebrew) #58295 (an NVD target_sw=- configuration never matches a concrete Fleet target_sw, a false negative in wfn/matching.go matchAttr). Both point at the matcher's platform handling; fixing one does not fix the other.
• matchTargetSW has existed since 19841 macos app false positives #19905 (June 2024) and behaves the same for macOS/Windows apps (o:apple:macos, o:microsoft:windows entries); Android is the first platform where NVD routinely lists the OS as a vulnerable entry next to the app.