A PoC for a Vulnerability in Your Company’s Service Has Been Released. How Much Time Do You Have Left?
According to Cloudflare, attack attempts targeting Log4j’s Log4Shell vulnerability were observed just nine minutes after the vulnerability was publicly disclosed.
Not nine days. Not nine hours.
Nine minutes.
Of course, not every vulnerability is exploited this quickly.
But the situation changes dramatically when an unauthenticated remote code execution vulnerability is discovered in an Internet-facing system — especially once a working Proof of Concept (PoC) becomes publicly available.
At that point, the vulnerability is no longer simply a “security issue that needs to be patched.”
It becomes an attack tool that anyone can potentially use.
What Changes When a PoC Becomes Public?
When only the vulnerability details are available, attackers still need to do some work.
They may need to compare patches, identify the vulnerable code, understand the conditions required for exploitation, and develop a working exploit.
Once a public PoC appears, however, much of that work has already been done.
A few lines of code may be enough to verify whether a target is vulnerable. Combined with Internet-wide scanning, the same technique can then be applied automatically across thousands or even tens of thousands of systems.
Publishing a PoC is a little like handing attackers a new key and allowing them to try it against every lock they can find.
Attackers Will Not Wait for You
Log4Shell was not an isolated case.
When CVE-2020-5902 affecting F5 BIG-IP was disclosed, public exploits and large-scale attacks followed within days of the patch becoming available.
For Atlassian Confluence’s CVE-2021-26084, malicious traffic was observed even before the public PoC became widely available.
React Server Components’ React2Shell (CVE-2025-55182) also saw scanning and exploitation attempts beginning on the day of disclosure, with confirmed compromises appearing only days later.
It may be minutes. It may be hours. You may be given a few days.
“Why Would Anyone Attack Us?”
Many Internet attacks do not begin with an attacker deliberately choosing a specific company.
Attackers scan the Internet.
They identify servers running a particular product, determine which systems appear vulnerable, and automatically attempt publicly available exploits against them.
If your vulnerable server happens to be found during that process, it becomes a target.
So instead of asking:
“Are we important enough for someone to attack us?”
A better question may be:
“Can our vulnerable systems be discovered from the Internet?”
If the vulnerable system is part of a public-facing service, there is a good chance that information about the service — including its technology stack or version information — has already been collected by scanners.
And if your domain happens to be the first one in an attacker’s dataset, your service could just as easily become victim number one.
What Matters Is Not Just How Quickly You Can Patch, but How Quickly You Can Respond
Patching every Critical vulnerability immediately is not realistic.
Organizations need to assess service impact, verify compatibility, test changes, and consider the possibility that an emergency deployment itself could cause a major outage.
That is why organizations do not simply need a policy that says “patch immediately.”
They need an incident-ready vulnerability response process that can move immediately when a truly urgent vulnerability appears.
Teams need to quickly determine whether the affected system is Internet-facing, whether exploitation requires authentication, whether the vulnerability enables remote code execution, whether a public PoC exists, and whether active exploitation has already begun.
If an immediate patch is not possible, the organization should still be capable of restricting external access, disabling vulnerable functionality, or applying temporary mitigations while preparing the permanent fix.
The longer these decisions and actions are delayed, the more likely it becomes that what started as vulnerability management will turn into incident response.
How Much Time Do You Have Left?
Imagine that a Critical vulnerability is announced in a system your organization uses.
Shortly afterward, the advisory is updated with one additional line:
Public PoC Available.
How much time do you have left?
For Log4Shell, it was nine minutes.
For another vulnerability, it might be several hours or several days.
No one knows the exact answer.
In some cases, attackers may already be exploiting the vulnerability before a public PoC even appears.
That is why an enterprise vulnerability response program cannot be completed with a single rule such as “Critical vulnerabilities must be patched within X days.”
Organizations need the ability to detect newly disclosed vulnerabilities quickly, determine whether their systems are affected, assess the likelihood of exploitation, apply immediate mitigations when necessary, deploy emergency patches, and — when exploitation has already begun — investigate whether compromise has already occurred.
Organizations cannot control how quickly vulnerabilities are disclosed.
They cannot control when a PoC will become public.
And they cannot control how quickly attackers will move.
There is only one thing they can control:
How quickly they can assess the situation and act once they know the vulnerability exists.
In an era where AI is accelerating vulnerability discovery and the number of newly identified vulnerabilities continues to grow, the amount of time available for defenders to respond is becoming increasingly limited.
As security incidents continue to occur across industries, I hope more organizations build fast, proactive, and resilient vulnerability response processes — and that, over time, fewer companies find themselves learning this lesson through an actual breach.