Not always. A public proof of concept shows an exploit is feasible, and it raises urgency, but it is not proof that attackers are using it. Treat active exploitation as the stronger signal, and weigh a public exploit alongside exposure, reachability, and how easy the attack is to automate.
Three states of exploitation
CISA's SSVC guide defines the exploitation decision point with three values:
| Value | Definition (from the guide) | Reading |
|---|---|---|
| None | No evidence of active exploitation and no public proof of concept | Normal handling |
| Public PoC | A typical public PoC exists, for example in Metasploit or ExploitDB, or there is a well known method of exploitation | Raise urgency, check exposure |
| Active | Shared, observable, reliable evidence that threat actors have used the exploit in the wild, from a credible source | Move to the front |
The guide stresses that this is the present state, not a prediction. Answers change over time, so it says they should be time stamped.
Why a public exploit still matters
A public PoC lowers the skill needed to attack. Once code is published, opportunistic attackers can use or adapt it. So a PoC against a component you expose to the internet deserves a faster response than the same flaw with no PoC.
But the quality of public exploits varies. Some only crash a service, some need unusual conditions, and some do not work against your version or configuration. Checking the code, or reading a credible analysis, is worth the time.
Active exploitation is different
When credible sources report real use by threat actors, the question changes from "might this happen" to "is this happening to others now". CISA's Known Exploited Vulnerabilities catalog is built for that, and CISA describes it as one input to vulnerability prioritization. An item there that affects you and is exposed belongs on the emergency path.
A decision path
- Is there active exploitation? If yes and the vulnerable code is yours and exposed, treat it as an emergency.
- Is there a public PoC? If yes, check whether it works against your version and whether the service is exposed. If both, move it up a tier.
- Is exploitation easy to automate? SSVC has a separate Automatable decision point for this. If yes, urgency rises.
- If none of these apply, follow the standard schedule, and set a reminder to re-check.
Do not rely on one feed
No list is complete. Absence from a catalog does not prove nobody is exploiting something, and EPSS is a probability, not a verdict. FIRST says EPSS estimates exploitation likelihood in the next 30 days and does not account for context in your environment.
Try it yourself
Open the demo and run the exploitability check on a finding. Notice what changes once the exploit evidence is supplied.
Click through it at your own pace, or open it full screen.
Quick check
Is a Metasploit module the same as active exploitation?
No. It is a public PoC under SSVC. It makes attacks easier, but active exploitation needs reliable evidence of use in the wild.
How often should exploit status be re-checked?
Regularly, since it changes. Re-check when advisories or catalogs update, and date every decision.
Sources
- CISA, SSVC guide
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, EPSS frequently asked questions
Last reviewed: 19 October 2026.
