An exploit is a specific piece of code, sequence of commands, or technique that takes advantage of a vulnerability to make software do something its designers never intended — leak memory, execute arbitrary code, escalate privileges, or crash a service. A vulnerability is the flaw; an exploit is the weapon built to fire through it. CVE-2021-44228 (Log4Shell) was a vulnerability disclosed on December 10, 2021 with a CVSS score of 10.0. Within 24 hours, working exploit code was posted publicly on GitHub, and by December 12 security teams were tracking over 800,000 attack attempts against it, according to Check Point telemetry. That gap — from disclosed flaw to weaponized attack — is the entire threat model modern AppSec teams are built to close. This glossary entry breaks down what exploits are, how they're classified, how attackers get them, and how to measure real exploitation risk instead of theoretical severity.
What is an exploit in cybersecurity?
An exploit is executable proof that a vulnerability can be abused, not just theorized about. It turns a CVE entry — a description of a flaw — into a working attack: a Python script that triggers a buffer overflow, an HTTP request that smuggles a deserialization payload, or a crafted file that hijacks a parser. The distinction matters operationally. As of mid-2024, the National Vulnerability Database listed over 240,000 CVEs, but CISA's Known Exploited Vulnerabilities (KEV) catalog — which only includes vulnerabilities with confirmed real-world exploitation — held just over 1,100 entries. Fewer than 0.5% of all disclosed vulnerabilities ever get a working, actively-used exploit. Security teams that treat every CVE as equally urgent burn budget on the 99.5% that will never be fired.
How is an exploit different from a vulnerability and a payload?
A vulnerability, an exploit, and a payload are three distinct links in the same attack chain. The vulnerability is the underlying weakness (e.g., CVE-2014-0160, the Heartbleed bug in OpenSSL's heartbeat extension, disclosed April 7, 2014). The exploit is the mechanism that reaches and triggers that weakness — in Heartbleed's case, a malformed heartbeat request that tricked OpenSSL into returning up to 64KB of adjacent memory per request. The payload is what the attacker does once the exploit succeeds — in many Heartbleed attacks, that meant scraping private TLS keys and session tokens directly out of leaked memory. Vendors patch vulnerabilities; detection tools flag exploit attempts; incident response deals with payloads. Conflating the three is why "we patched it" and "we're not compromised" are sometimes false equivalents — an exploit can succeed in the window before a patch is applied.
What are the main types of exploits?
Exploits are classified by delivery method and target, and the two axes that matter most for defenders are remote-vs-local and known-vs-zero-day. A remote code execution (RCE) exploit, like the one for CVE-2023-34362 in Progress Software's MOVEit Transfer (disclosed May 31, 2023), let the Cl0p ransomware group run SQL injection attacks against internet-facing servers with no authentication required, ultimately compromising more than 2,700 organizations and 93 million individuals' data according to breach disclosures tracked through early 2024. A local privilege escalation (LPE) exploit requires existing access and elevates it — CVE-2021-4034 ("PwnKit") in Linux's Polkit let any local user gain root with a five-line exploit. A zero-day exploit targets a vulnerability with no patch available at time of use, like the four zero-days chained in the 2023 MOVEit-adjacent GoAnywhere MFT attacks. A known-CVE exploit, like EternalBlue (targeting MS17-010, patched by Microsoft on March 14, 2017), gets weaponized against unpatched systems for years — EternalBlue powered both WannaCry in May 2017 (200,000+ machines across 150 countries in four days) and NotPetya weeks later, which Merck, Maersk, and FedEx each reported costing them roughly $300-400 million.
How do attackers actually get exploits?
Attackers get exploits by building them, buying them, or copying public proof-of-concept code — and the third category moves fastest. Public exploit code shows up on platforms like Exploit-DB, GitHub, and within Metasploit modules, often within days of a CVE disclosure; for Log4Shell, functional exploit code was public before Apache had finished shipping a fully effective patch (the initial fix, 2.15.0, was itself found bypassable, requiring 2.16.0 and then 2.17.1). Commercial exploit brokers and gray-market vendors sell weaponized zero-days for six to seven figures — NSO Group's Pegasus exploit chains for iOS have been priced in leaked contracts at over $1 million per operation. Nation-state and cybercrime groups also stockpile exploits internally; the ShadowBrokers leak in April 2017 dumped NSA-developed exploits, including EternalBlue, directly into public circulation, which is how it ended up in WannaCry a month later. The economics matter for defenders: once an exploit is public, the population of attackers who can use it against you expands from a handful of specialists to anyone who can run a script.
Does having a public exploit mean I'll get attacked?
No — a public exploit raises the probability of attack but doesn't guarantee it, and the best available measure of that probability is EPSS (Exploit Prediction Scoring System), a FIRST.org model that scores CVEs from 0 to 1 based on observed exploitation likelihood in the next 30 days. Log4Shell scored above 0.97 on EPSS within weeks of disclosure — near-certain exploitation — while the majority of CVEs sit below 0.01. The gap between CVSS (which measures theoretical severity) and EPSS (which measures observed attacker interest) is often enormous: a CVE can carry a 9.8 CVSS score and still show negligible real-world exploitation because it requires local access, non-default configuration, or a component nobody actually deploys internet-facing. Conversely, a "medium" CVSS 6.5 vulnerability sitting in a component that's actually reachable from the internet, in a library your app actually calls at runtime, can be a live exploitation target. Severity score alone tells you almost nothing about whether an exploit will ever touch your environment.
How can organizations reduce exposure to exploits?
Organizations reduce exposure by shrinking the window between disclosure and patch, and by prioritizing fixes based on whether a vulnerable code path is actually reachable rather than just present. CISA's Binding Operational Directive 22-01 gives federal agencies a hard deadline — as tight as 2 weeks for actively exploited KEV entries — because the data backs it up: Mandiant's M-Trends research has repeatedly found that a large share of breaches involving known vulnerabilities occur against flaws that had a patch available for 6 months or longer before exploitation. Network segmentation, WAF rules, and virtual patching buy time when a real fix can't ship immediately, as many teams did in the days after Log4Shell before every downstream dependency was updated. But the highest-leverage move is triage: knowing which of your 10,000 open findings are in code that actually executes, versus sitting in an unused function of a transitive dependency, is what separates a two-week remediation backlog from a two-year one.
How Safeguard Helps
Safeguard turns "is this exploitable" from a guess into an answer. Reachability analysis traces whether a vulnerable function in a dependency is actually called by your application's code paths at runtime, so a CVE with a public exploit sitting in dead code gets deprioritized instead of paging your on-call team. Griffin AI, Safeguard's reasoning engine, correlates CVSS, EPSS, KEV status, and reachability to rank findings the way an attacker would — not the way a scanner alphabetizes them. Safeguard generates and ingests SBOMs to give you a live inventory of every component an exploit could target, and where a fix exists, auto-fix pull requests ship the patched version directly into your CI pipeline so the gap between "exploit is public" and "we're patched" shrinks from months to hours.