Vulnerability → exploit → payload chain: the flaw lives in the software, the exploit turns it into access and the payload decides what happens next. Breaking any of the three links (patch, mitigation, detection) breaks the attack; that is why you defend in layers rather than relying on patching alone.
What is an exploit
An exploit is a piece of code, a sequence of requests or a technique that abuses a specific vulnerability to make a system behave in an unintended way: execute arbitrary code, elevate privileges, steal information or bring a service down. In the attack chain, the vulnerability is the flaw, the exploit is the tool that turns it into access, and the payload is what runs afterwards: a webshell, a command-and-control beacon or ransomware. Not every flaw is exploitable in practice: the distance between a theoretical advisory and a weaponised zero-day can be years or hours, and measuring that difference is precisely what separates good patch prioritisation from an endless backlog.
Why it matters
Because the real risk of a vulnerability is not set by its CVSS score, but by whether a usable exploit exists and who holds it. When a critical CVE is published for an Internet-facing product, the sequence is almost always the same: a proof of concept (PoC) on GitHub within hours or days, integration into offensive tooling and mass scanners shortly after, and indiscriminate exploitation of everything still unpatched. That race between attacker and patching team has shortened: for many perimeter vulnerabilities, the useful reaction window is measured in days, not months. That is why mature programmes do not patch in order of theoretical severity but by real exploitability: CISA's KEV catalogue lists what is being actively exploited, and EPSS estimates each CVE's probability of exploitation. Understanding exploits also matters for active defence: a serious penetration test does not stop at scanning, but uses controlled exploitation to validate which flaws are genuinely usable in your environment and which are noise.
Key points
Types by effect: RCE (remote code execution, the most critical because it grants control with no prior access), LPE or local privilege escalation (turns a limited user into an administrator), denial of service, information disclosure and authentication bypass.
Zero-day vs n-day: a zero-day exploits a flaw with no patch available and is expensive and scarce; an n-day exploits an already-fixed flaw, betting that the victim has not patched. The vast majority of real incidents use n-days: the patch existed, it just was not applied.
Exploit kits and commoditisation: reliable exploits are packaged into offensive frameworks, crimeware kits and initial-access services that are bought and sold. An attacker with no technical capability of their own can exploit today what required a specialist a few years ago.
Public PoC and the patching race: publication of a proof of concept triggers mass exploitation within hours. The KEV catalogue and the EPSS score let you prioritise by real probability of exploitation instead of theoretical severity.
Legitimate use: in an authorised penetration test, controlled exploitation demonstrates the real impact of each flaw — how far an attacker gets, which data is exposed — without damaging the system. It is the difference between a report of hypotheses and evidence the business understands.
Example: from published CVE to compromise in 72 hours
A manufacturing company runs a remote-access portal for its plant technicians. On Tuesday, a critical remote code execution CVE is published affecting the exact version they use. On Wednesday, a working PoC appears on GitHub; that same night, honeypots run by several threat intelligence vendors record the first mass scans looking for the product. By Thursday, the exploit ships inside automated tooling and ransomware groups are using it for initial access. The company had scheduled its maintenance window for two weeks later: on Friday morning it finds a webshell on the server and lateral movement towards Active Directory.
The same scenario with mature vulnerability management ends differently: the CVE advisory lands on Tuesday tagged as an Internet-facing product, its entry in the KEV catalogue and a high EPSS score escalate it to an emergency, and the patch — or the vendor's temporary mitigation — is applied out of cycle in under 24 hours. You do not need to guess which vulnerabilities matter: you need a reliable inventory of what is exposed, sources that tell you what is genuinely being exploited, and an emergency patching procedure that does not depend on the next maintenance window.
Common mistakes
- Assuming no public exploit means no risk. The absence of a PoC on GitHub does not mean a private exploit is not in the hands of a criminal group or a broker; for critical exposed systems, no known exploit only buys time, not safety.
- Prioritising by CVSS alone. A 9.8 vulnerability with no known exploit on an internal system can be less urgent than a 7.5 under active exploitation on the perimeter. Without exploitability signals (KEV, EPSS, threat intelligence), the patching queue gets sorted wrong.
- Patching the perimeter and forgetting the inside. Privilege escalation exploits and internal n-days are what turn a minor initial foothold into full domain compromise; the unpatched internal network is the silent multiplier of any breach.
- Trusting antivirus or EDR to stop the exploit. Endpoint tools detect known payloads and behaviours, but an exploit against an exposed service can run before any agent sees a thing. Detection complements patching, it does not replace it.
- Banning exploitation in penetration tests for fear of breaking something. The result is an unvalidated scanner report full of false positives with no real measure of impact. Controlled exploitation, agreed in the rules of engagement, is precisely what adds value.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
Does every vulnerability have an exploit?
No. Many vulnerabilities are theoretically exploitable but nobody has written a reliable exploit, because the effort is not worth it or the required conditions are unrealistic. Of the thousands of CVEs published each year, only a small fraction is ever actively exploited. That is why mature programmes prioritise using real exploitation signals — KEV, EPSS, threat intelligence — instead of trying to patch everything with the same urgency.
What is the difference between an exploit, a payload and malware?
The exploit is the key: the code that abuses the flaw to gain access or privileges. The payload is what runs once inside: a remote shell, a command-and-control beacon, a credential stealer. Malware is any malicious software, which may arrive via an exploit or by other routes, such as an attachment the victim opens willingly. An attack may combine all three or skip some.
What is a zero-day exploit and why is it so valuable?
It is an exploit for a vulnerability the vendor does not yet know about or has not patched, so no direct defence exists. Its value comes from exclusivity: brokers and government programmes pay six- and seven-figure sums for zero-days in widely deployed platforms. For most businesses, however, the everyday risk is not zero-days but unpatched n-days.
Is it legal to use exploits?
It depends on context and authorisation. Using an exploit against someone else's systems without permission is a criminal offence in Spain (article 197 bis of the Criminal Code) and in most jurisdictions. By contrast, controlled exploitation within a penetration test or red team exercise with written authorisation, a defined scope and rules of engagement is a legitimate professional practice and, in fact, the best way to validate real risk.