OA008: Materialized Vulnerable Copy

Severity: critical · Auto-fix: no

The most severe rule. An override declared a floor, but a copy of the target package below that floor is still present on disk in node_modules. The security pin is not effective. The project is vulnerable and the developer did not know it.

What makes this dangerous: three things feel correct and are not. The code review looked right. npm install ran without errors. npm audit reported nothing new. Static analysis of package.json alone cannot catch this - it requires checking what is actually on disk.

Example

{
  "overrides": {
    "@esbuild/linux-x64": ">=0.28.0"
  }
}

Installed tree (real finding from a production codebase):

node_modules/@esbuild/[email protected]           <- VULNERABLE: below floor
node_modules/tsx/node_modules/@esbuild/[email protected]   <- OK

The tsx parent's exact pin won that subtree's resolution. The override was written, npm install ran, CI passed - and one copy of the binary is still at the vulnerable version.

Terminal output

CRITICAL (1)
------------
  OA008  @esbuild/linux-x64
    package.json/overrides/@esbuild~1linux-x64
    Override floor not applied - vulnerable copy still on disk

Fix

OA008 is suggest-only. The fix requires investigating the parent that pulled in the vulnerable copy:

# 1. Find what is pulling in the vulnerable copy
npm ls @esbuild/linux-x64

# 2. Override the parent instead (see OA006)
#    "overrides": { "esbuild": ">=0.28.0" }

# 3. Flush and reinstall
rm -rf node_modules package-lock.json && npm install

# 4. Confirm the finding is gone
cve-lite overrides .

See OA006 for the parent-override pattern. OA008 and OA006 often appear together on the same package - OA006 catches the structural cause, OA008 confirms the vulnerable copy on disk.

Example​

Terminal output​

Fix​

Example

Terminal output

Fix