There's a ticket in almost every backlog that's older than some of the people on the team. The CVE is real, the scanner says a patch is available, and it's still open. Not because nobody cared. The patch means a major-version upgrade the application owner can't schedule this quarter, or it was already backported by the distribution and nobody can prove it, or the vendor stopped shipping patches for that version two years ago.
The instinct when a vulnerability lands is to patch it. It's the right end state. It's also, far more often than anyone budgets for, a complex undertaking, and while it's in progress the exposure stays open. The question worth asking first isn't "is there a patch?" It's "what can we do about this risk right now, and where?"
"Patch available" sounds like a yes. In practice a patch can be in one of several states, and only one of them means "go roll it out".
Old findings tend to sit in the middle two columns. Backports keep old version numbers, so scanners keep flagging CVEs the distribution fixed long ago. Major-version upgrades wait for a roadmap slot. End-of-life base images collect findings for years.
New, fast-moving CVEs make it worse, because the state changes under you. PHP2Shell, the pair of PHP remote code execution bugs disclosed on 21 October, went through most of these states in one week:
PHP2Shell, the first week
Status as of 25 October 2026, from each distribution's own tracker. Details in our PHP2Shell analysis.
Exploitation doesn't wait for any of this. Mandiant estimates that in 2025 exploitation started on average seven days before a patch shipped, and the 2026 Verizon DBIR puts the median time to fully patch known-exploited vulnerabilities at 43 days. Somewhere in that gap, the exposure is open and the patch isn't the answer yet.
A vulnerability is only dangerous if an attacker can reach it, the conditions for the exploit hold, and getting in leads somewhere worth going. Each of those is a place to act, and only one of them is the vulnerable resource itself.
The path that reaches the resource
The conditions the exploit needs
What a compromise leads to
Some of these close the exposure outright: if the path no longer reaches the resource, or the setting the exploit needs is off, the vulnerability is still present but can't be exercised. Others don't stop the exploit but shrink what it buys the attacker. Both are legitimate choices, and both are usually faster, cheaper and less risky than an emergency upgrade.
The one that does the most is often off the resource entirely. A single security group rule or an over-broad role can sit on the path to dozens of vulnerable resources. Closing it can remove more exposure in one change than a week of patching, and it never shows up on a list sorted by CVE severity.
None of this replaces the patch. A mitigation is how you hold the line while the patch moves from "nothing to apply" or "costly here" to "safe to roll out". The part most programs miss is the handoff.
Mitigations put in during an emergency tend to stay forever, because nobody tracks why they're there. Patches rolled out in a hurry are rarely checked to confirm they actually closed the exposure. Treating the two as one process takes care of both: contain the exposure now, watch the patch's state, roll it out when it's safe, confirm the exposure is closed, then retire the mitigation on purpose.
For how Defendermate lays out these options for each exposure and plans the patch rollout once it's safe, see Plan.
Sources: PHP2Shell status per distribution as of 25 October 2026 (our analysis); Mandiant, M-Trends 2026; Verizon, 2026 Data Breach Investigations Report.