Software supply chain risk
Detect a Supply Chain Attack Without a CVE
Updated 7 Oct 2026
A hijacked package has no CVE on the day it ships. A CVE scanner checks versions against a list of known problems, so it passes the new version. This page shows why, with real attacks, and how to catch the update by what it can do.
Why a CVE scanner misses a hijacked update
Tools such as npm audit, Dependabot and OSV-Scanner look up each package version in an advisory database. If the version has an entry, the tool reports it. If it has no entry, the tool stays quiet.
A supply chain attack is a new version of a real package. Nobody knows about it when it ships, so no advisory exists. The entry comes later, after someone finds the attack. Every install before that date passes the scan.
The CVE scanner works as designed. It answers "is this version known to be bad?" On the day of an attack, the answer is no.
Real attacks that shipped before their CVE
XZ Utils, 2024
Version 5.6.0 came out on 24 February 2024 and 5.6.1 on 9 March 2024. Andres Freund disclosed the backdoor on 29 March 2024. It is now tracked as CVE-2024-3094. For five weeks, the backdoored release matched no advisory. See the XZ Utils page.
3CX DesktopApp, 2023
Signed installers carried a trojanized ffmpeg library. The attack became public on 29 March 2023, and the issue is now tracked as CVE-2023-29059. See the 3CX page.
SolarWinds Orion, 2020
SUNBURST hid in a signed Orion DLL, from 2019.4 HF5 onward. Customers installed it as a normal vendor update. See the SolarWinds page.
@apexacc/cli, 2026
Version 1.5.122 went live on npm on 17 September 2026. It turns off Windows Defender and runs commands from a server. Vigilance found the release eleven hours after it went to npm. See advisory VIGI-001-2026.
The npm supply chain attacks page lists 24 more npm records. In each one, the malicious version was new when people installed it.
What to look for instead
Look at what the new version can do that the old one could not. A real update to a date library does not suddenly reach the network, start a shell, or read SSH keys. A hijacked one often does.
This check needs no advisory, no reputation list and no history. It needs two things: the version you trust and the new version.
- Keep the version you trust. A lockfile pins it for you.
- Before you accept an update, compare the two versions.
- Read the files that gained a capability. Most updates gain none.
- If a file gained a capability it does not need, do not install the update.
How Vigilance does it
Vigilance compares the version you trust with a new one. It reports the file that gained a new capability, such as a new install script, a network call or a read of saved passwords. It stays quiet on the rest of the release.
Compare two folders before you install.
vigi diff --old ./current --new ./updateOn a machine, record once, then check after each change.
vigi record
vigi checkA new capability needs review. It does not prove that an update is malicious. Use a CVE scanner as well. It finds known flaws, and Vigilance finds the change that has no CVE yet. The nine prevention controls cover the rest of the pipeline.
FAQ
Can a CVE scanner catch a malicious package?
Only after someone finds the attack and an advisory goes out. Until then the version matches no entry in the database, so the scan passes. XZ Utils 5.6.0 shipped on 24 February 2024 and the backdoor became public on 29 March 2024.
How do I detect a supply chain attack without a CVE?
Compare the version you trust with the new one, and look for a file that can do something it could not do before. Examples are a new install script, a new network call, or a new read of saved credentials. Vigilance reports that file.
Does a new capability mean the update is malicious?
No. A new capability needs review. It does not prove an attack. Vigilance reports what it finds, and your team decides what to install.
Check your next update.
Vigilance compares the version you trust with a new one. Download Vigilance to scan your own files.