CVE Lite CLI finds 3 of 4 projects’ overrides broken, silently leaving known vulnerabilities live

A free open source tool just exposed a nasty blind spot in JavaScript security: CVE Lite CLI says it found broken override configurations in 3 out of 4 popular projects, including cases where override entries were silently doing nothing. That matters because overrides are supposed to be the quick fix when a transitive dependency ships a vulnerability patch, but the upstream project you directly depend on has not incorporated it yet.

The stakes are simple and uncomfortable. Kapoor, creator of CVE Lite CLI, scanned four popular JavaScript open source projects and reported that three of the four had broken overrides. Cal.com had 90 override entries and 11 that were silently doing nothing. Jest had an override for its own package name pointing at nothing in the resolved tree. NoCoDB’s entries used wildcard patterns that never matched any path in the graph. Next.js was the only clean one, with zero findings. If you are advising engineering teams or overseeing security governance, this is the difference between “we think we are protected” and “we are not, and we did not even get a warning.”

To understand why overrides rot, you have to zoom in on how the JavaScript ecosystem works. Modern apps typically assemble functionality from packages. Those packages often depend on other packages, and those dependencies can depend on still more packages. The vulnerable component you care about might be two or three hops away, which is why security teams talk about transitive or indirect dependencies. A common scenario looks like this: an app depends on Package A. Package A relies on Package B. If the maintainers of Package B patch a reported CVE, but Package A has not updated yet, apps that still pull the old Package B through Package A may remain vulnerable to attack.

One response developers reach for is to create an override in package.json. The idea is to replace the outdated, vulnerable version of Package B with a fixed version, and then remove the override later once Package A’s maintainers ship the real update. In theory, this is a sensible security tool. Kapoor agrees overrides can be legitimate, particularly when a transitive dependency has a CVE and upstream hasn’t shipped a fix yet. But the failure mode is the real story here: the override can appear in configuration while quietly failing to actually influence the dependency graph.

Kapoor’s explanation gets specific about how that quiet failure happens. Override support is not uniform across package managers. npm reads from overrides, pnpm reads from pnpm.overrides, and Yarn reads from resolutions. If a team migrates package managers, the override entries can end up in the wrong place. The package manager then silently ignores them. There is “No error, no warning,” Kapoor said in the email published by The Register. The vulnerable package ships unconstrained, even though the team believes it has pinned something securely.

That silence is exactly what makes this update feel overdue. Kapoor also highlighted another issue: what developers do after adding overrides. AI coding assistants, in his words, commonly advise developers to add override entries when asked to fix a transitive dependency vulnerability. The advice is “correct at the moment,” Kapoor said. The gap is that none of them, he claims, tell developers to come back and verify the entry still works. In other words, the workflow stops at “configuration looks right,” not at “resolved tree is actually right.”

CVE Lite CLI’s newly added override auditing is basically a hygiene check for that missing step. Kapoor says the CLI does not recommend overrides as the primary way to properly address a vulnerable dependency. He argues overrides can outlive their purpose and become dangerous later: they can point at packages no longer in the dependency tree, apply to the wrong package manager entirely, or shift to an unintended version on every install. The tool exists to catch precisely that “teams add an override to address a CVE, move on, and years later, the override does nothing while they still believe they're protected” failure mode.

This lands in a broader security moment. The Register frames the recent wave of supply chain attacks as a reckoning for the developer ecosystem, including CI/CD pipelines, package registries, and developer tooling. If attackers are targeting where developers build and distribute software, then security teams cannot afford to treat dependency fixes as set-and-forget. A broken override is worse than a missing one because it creates false confidence, and false confidence is how vulnerabilities survive the sprint where everyone thought they were removed.