What is a zero-day vulnerability?

Zero-day vulnerability, exploit and attack

The three terms are often used interchangeably, but they describe different things:

• Zero-day vulnerability: the flaw itself, unknown to the vendor or without a fix.
• Zero-day exploit: the code or technique that takes advantage of the flaw.
• Zero-day attack: the exploit used against real targets.

Once the vendor ships a fix, the flaw stops being a zero-day and becomes a known vulnerability, often called an n-day. That starts a second race: attackers study the patch and scan for systems that have not applied it, so a known vulnerability left unpatched can do as much damage as the original zero-day.

Zero-days in your dependencies

Most of the code in a modern application comes from open source packages, and most of those are transitive dependencies: pulled in by other packages rather than chosen by your team. A zero-day in any of them is a zero-day in your product.

Log4Shell (CVE-2021-44228) is the best-known example. Disclosed in December 2021, it let an attacker who controlled a logged message run arbitrary code through Apache Log4j 2, and it scored the maximum CVSS 10.0. For most teams the hard part was not the fix. It was the question before it: which of our applications contain log4j-core, and in which versions? Log4j was usually a dependency of a dependency, and many teams spent days finding out.

Zero-days in the supply chain are not always bugs. In March 2024, Andres Freund found a backdoor in xz versions 5.6.0 and 5.6.1 (CVE-2024-3094) after noticing that SSH logins were using too much CPU. Malicious package releases, a common kind of supply chain attack, work the same way: the first teams to install an infected version, such as those hit by the Shai-Hulud npm worm, face an attack that no advisory or scanner knows about yet.

How to respond when a zero-day hits a dependency

1. Find where it is. List every application, image and release that contains the affected component, including as a transitive dependency. This needs an accurate SBOM for each build. A lockfile misses dependencies fetched outside the package manager, such as code downloaded by install scripts or the operating system layers of a container image.
2. Work out the exposure period. Which builds shipped the vulnerable version, and since when? That tells you what to investigate and what to report.
3. Contain it. Apply the fix or a workaround when one exists, and stop new builds from shipping the vulnerable version once it has a CVE. See CVE remediation.
4. Check for exploitation. Look for signs the flaw was used against you during the exposure period, and rotate any secrets it could have reached.

Are we affected? walks through the first two steps in detail.

Can you defend against a zero-day nobody knows about?

Not by patching, and not with scanners, because both depend on the flaw being known. What works before disclosure is limiting what an attacker can do with a flaw they find:

• Least privilege. Give each system and each CI job only the access and secrets it needs.
• Egress control. Block outbound connections to hosts a system does not need, so an exploit that runs cannot send data to the attacker. In a CI build this is one of the few controls that works even if you are the first victim of a new malicious package. See egress policies for GitHub Actions.
• Defense in depth. Layer controls so one flaw does not open everything.
• Records you can search later. When the zero-day is disclosed, the speed of your response depends on knowing what you built and shipped.

How CRACI helps

CRACI runs your GitHub Actions jobs on its own runners and records every build as it happens:

• Build-time SBOMs list the packages each job actually pulled in, including the hidden dependencies that lockfile-based tools miss, so you can answer "where is it?" from what was really built. See build-time SBOMs.
• Build history shows every past build and its SBOM, and which builds contained a vulnerable dependency, direct or transitive, so you know the period you were affected.
• Policy gates can block a build that contains a specific CVE, so a new build does not ship the vulnerable version again.
• A default-deny egress policy blocks connections to hosts the build does not need, even during an attack nobody has seen before.

Zero-day vulnerabilities: frequently asked questions

What is a zero-day vulnerability?

A security flaw that attackers know about, or are already exploiting, before the vendor or maintainer has released a fix. The name counts the days defenders have had to patch it: zero.

What is the difference between a zero-day vulnerability, exploit and attack?

The vulnerability is the flaw. The exploit is the code or technique that takes advantage of it. The attack is the exploit used against real targets.

When does a zero-day stop being a zero-day?

When a fix is available. From then on it is a known vulnerability, sometimes called an n-day, and the risk moves to systems that have not applied the fix yet.

Can a scanner detect a zero-day?

Not by looking it up. Vulnerability scanners match components against published advisories, and a zero-day has none yet. What a scanner or SBOM gives you is the inventory to search the moment the advisory appears.

How do I find out if a zero-day affects my software?

Search an accurate inventory of what each build and release contains, including transitive dependencies, for the affected component and versions. Then work out which releases shipped it and since when, so you know the exposure period.