A headline says "critical vulnerability discovered". Another says "company hit by exploit". A third says "security incident under investigation". They sound like the same thing at three volumes. They are three different things, and confusing them leads to panic about the wrong stage or complacency about the right one.
The three words
A is a weakness: a flaw in code, a risky setting, a gap in a process. It exists whether or not anyone knows about it. A door with a faulty latch has a vulnerability even if nobody has tried it.
An is a method that takes advantage of a vulnerability: a technique, a crafted input, or a program that does it automatically. It is the tool shaped to the flaw. Exploit is also used as a verb: to exploit a vulnerability.
An is an event where confidentiality, integrity or availability was actually harmed, or credibly threatened. It is what happened, not what could happen. The burglary, not the latch.
Two neighbouring words complete the picture. A threat is a potential cause of harm, such as an actor with intent. is how likely harm is and how bad it would be, given the threat and the vulnerability. Notice the layering: vulnerability plus threat plus value at stake gives risk.
The chain, and its exits
Read the diagram left to right. For harm to happen through a software flaw, each step has to hold:
- A vulnerability exists in something you run.
- Someone creates a working exploit.
- They can reach your system with it, and the conditions match your configuration.
- They succeed, and something valuable is within reach.
Every step is a place where the chain can break, and each break is a defender's opportunity:
- Remove the flaw by patching (step 1).
- Make the exploit fail by changing the setting it relies on (step 2 or 3).
- Make your system unreachable, using the attack-surface moves from earlier (step 3).
- Limit what is reachable once someone is in, so success yields little (step 4, and the topic of the last lesson in this level).
This is why reading a record like the one in the previous lesson gives you choices. If you cannot patch today, you can still shut a door.
A security researcher publishes a report of a flaw in a popular library, with no working attack code. What exists, and what does not?
A vulnerability exists and is now known. A reliable exploit and any incidents are not part of the report. That can change quickly, which is why a published flaw still deserves attention.
Proof of concept
Between flaw and weapon there is often a proof of concept, usually shortened to PoC: a small demonstration that the flaw is real, written to show a vendor it must be fixed. A PoC is not always a usable attack, but it lowers the work for anyone who wants to build one. Researchers tend to share these carefully for that reason; the practice of telling the vendor first and publishing later is called . A flaw attackers use before the vendor has a fix is a .
When a vulnerability does not become an incident
Most vulnerabilities never cause one for you. Reasons include: the vulnerable feature is not enabled; the product version you run is not affected; the system is not reachable by an attacker; or you patched in time. This is why security teams do not treat the length of a vulnerability list as the measure of danger. A thousand unreachable flaws can matter less than one that is exploited, reachable and on a valuable system. In the last lesson you used KEV and EPSS exactly to sort those.
When an incident has no vulnerability
Here is the part beginners miss. Plenty of incidents involve no flaw in any software:
- A person reuses a password that leaked from another site, and an attacker logs in. The login worked exactly as designed.
- A storage folder is set to public by mistake. The system did what it was told.
- A staff member is tricked into sending a file. A human was the path.
- A tool deletes the wrong directory. There was no attacker at all.
In these, the weakness is a configuration, a habit or a decision. Some people call these vulnerabilities in a broad sense, and that is fine; the point is that "patch everything" does not fix them. Fixing them takes the other controls: strong login with a second factor, safe defaults, review, and limiting access.
An incident also needs handling once it happens, with a plan to find, contain and recover. That discipline is called and we meet it again in level 6.
An employee's reused password lets an attacker into a work account. Is there a vulnerability to patch?
Not in the software. The account behaved correctly. The fix is controls around identity: unique passwords, a second factor, and alerts for unusual logins. This is an incident without a software vulnerability.
How AI changes this
AI squeezes the chain at several places at once.
Faster from flaw to exploit. Models can help read code or a patch and suggest where the flaw is, and help adapt an existing attack to a new target. Beam's post on PHP2Shell and AI agents and the October 2026 roundup describe a critical bug that researchers found with AI help and that saw attack traffic before the fix was out. Treat that as one documented case rather than a law, but the direction is clear: the time between a flaw becoming known and an exploit existing may be shorter than it was, so the patching and exposure-reduction steps need to be quicker.
Faster discovery. AI-assisted code review can find flaws that humans overlooked in old code, which means more vulnerabilities become known, including in code that has been around a long time. That is good for defenders who fix them, and it raises the number of advisories you have to triage.
Incidents with no attacker and no classic flaw. An AI agent can cause an incident by itself: deleting files, using a credential it should not have, or sending data somewhere. The October 2026 roundup notes OpenAI notifying more than 100 organisations that its agents may have accessed their systems without authorisation, an example of an incident with no external attacker (see AI-led attacks in October 2026). Here the weakness was access that was too broad and monitoring that was too thin, not a coding bug.
Design-level weaknesses. is not a bug you can patch in the usual way; it follows from a model treating text it reads as possibly meaningful instructions. It is a vulnerability in the system's design, and the response is to reduce what a steered agent can reach.
What stays the same: the chain, and the exits. Defenders still win by breaking one link.
Try it
Take three recent security headlines of your choice, or these invented ones:
- "Researchers disclose a flaw in a popular chat server."
- "Attack code for the flaw is posted online."
- "A hospital's records system was down for two days after attackers entered through the flaw."
For each, write: vulnerability, exploit or incident? and which chain step is described. Then pick your own situation (a home router, a website you run) and write down one thing you could do at each of the four steps in the chain. No scanning or testing of anything is needed; this is a paper exercise.
Check yourself
Which of vulnerability, exploit and incident exists even if nobody has noticed it?
The vulnerability. A flaw exists whether or not anyone has found it. An exploit needs someone to build it and an incident needs harm to occur.
Give two reasons a known vulnerability might not lead to an incident in your organisation.
Any two of: you do not run the affected version or feature; it is not reachable by attackers; you patched or mitigated in time; there is nothing valuable behind it; there is no working exploit and no motivated attacker.
An AI agent deletes a customer database because of a misunderstood instruction. Vulnerability, exploit or incident?
An incident. No exploit was needed. The weakness was excessive access and a missing safeguard around destructive actions, which is a design and permissions problem.
Next
If patching breaks the chain at step one, why do known holes stay open for years? Next lesson: patching, and why it fails.