The headline usually looks the same: a remote code execution flaw in a VPN gateway, a file transfer server or a web framework, a CVSS score above 9, a patch released the same day, and a line saying exploitation has already been seen.
Somebody forwards it to the team chat with one question: “Are we affected?”
Some teams answer within the hour. Others spend days digging through spreadsheets and old tickets, while attackers who read the same headline are already scanning the internet for exposed instances.
Below is the order that wastes the least time, plus what to prepare so the next round goes faster.
Start with what is actually vulnerable
Before searching for anything, open the vendor advisory. News stories compress it, and the details that matter get lost.
Note the exact affected version range and the fixed version. “Versions before 7.2.4” and “versions 7.0 through 7.2.3 with the web portal enabled” lead to very different searches.
Then look for preconditions. Many critical bugs need a specific feature turned on, a management interface reachable from outside, or a particular configuration.
If the vulnerable component only listens on an admin port that should never be public, the question becomes “is that port public anywhere?”
Finally, read the CVSS vector. A vector that starts with AV:N/AC:L/PR:N/UI:N means the flaw can be reached over the network, with low complexity, without credentials and without anyone clicking anything.
That is the combination worth dropping other work for. A 9.0 that needs local access or a logged-in admin is a different conversation.
Put versions, preconditions and the vector in the ticket or chat thread before anyone starts searching. Half the follow-up questions in the next hour will be about them.
Find every instance that faces the internet
This is the step where most of the time goes, because the honest inventory of internet-facing systems rarely matches the official one.
The list in the CMDB was accurate when someone last updated it. Since then, a contractor may have set up a staging server, a team may have spun up a test environment in a second cloud account, and an old marketing subdomain may still point at a VM nobody remembers.
Useful sources, roughly in order of how quickly they answer:
- Recent external scan results. If an external vulnerability scanner already keeps a record of open ports, running services and their versions for every public host, this step becomes a filter: show every host running the affected product, then compare versions. How useful that is depends on the date of the last scan. Last week’s results are a good start. Last quarter’s are a guess.
- Cloud accounts. List public IPs, load balancers and DNS zones in every account and region. The “temporary” project accounts are where forgotten hosts tend to live.
- Certificate Transparency. CT logs list every certificate issued for your domains, which is a reliable way to find hostnames that were never added to the inventory. Attackers use the same logs.
- Shodan and Censys. These services show what your IP ranges look like from outside. If they can see a vulnerable version banner on your address, so can everyone else.
One caution about version matching. A version string in a banner is a hint, not proof. Linux distributions often backport security fixes without changing the upstream version number, so a host can report an “affected” version and still be patched.
The opposite also happens: a banner can be hidden or generic while the vulnerable software runs behind it. Treat a match as “needs a look”, then confirm on the host or with a check that tests the vulnerability itself.
By the end of this step you want a short list: hostname or IP, owner, environment, detected version, and whether the vulnerable feature is exposed.
Check whether it is being exploited
Severity says how bad a flaw could be. Exploitation data says how likely it is to be used against you this week.
CISA Known Exploited Vulnerabilities (KEV). The catalog lists vulnerabilities with a CVE ID, confirmed exploitation in the wild and a clear fix. As of early October 2026 it holds 1,734 entries. If the CVE from the headline is on it, the debate about urgency is over.
EPSS. The Exploit Prediction Scoring System from FIRST estimates the probability that a published CVE will be exploited in the next 30 days. Scores are free and updated daily, so a new CVE can move from low to high within days of a public proof of concept.
Public exploit code. A working proof of concept on GitHub or in a public exploit database shortens the time between disclosure and mass scanning. Honeypot operators and threat intelligence feeds report that scanning as it starts, so check them before deciding something can wait.
Decide: patch now, mitigate now, or schedule
With the exposure list and the exploitation data in hand, most findings sort themselves.
Exposed and exploited. Patch today. If the patch cannot go in today, mitigate today: take the management interface off the public internet, restrict access by IP, disable the vulnerable feature or put a blocking rule in front of it.
A mitigation without a patch date is a reminder that never fires, so set the date.
Exposed but not yet exploited. Patch within the deadline your policy sets for critical findings, commonly seven days. Watch KEV and EPSS during that window, because “not yet” can change quickly.
Not reachable from outside. Fix it on the normal cycle and move on. Internal-only does not mean safe forever, but it is not today’s fire.
Record each decision with an owner and a date. The same question will come back from leadership, later from an auditor or a customer questionnaire, and the answer will already be written down.
Prove the fix
A ticket marked “done” is not evidence. Rescan the affected hosts after patching and confirm that the version changed and the finding closed.
If the finding stays open, the patch did not apply where it was supposed to, or there is a second instance nobody listed.
For flaws that were exploited before the patch came out, patching closes the door but does not remove anyone who already came in. Vendors and CISA often publish indicators of compromise for these cases.
If a host was exposed and vulnerable during the exploitation window, checking it against those indicators is part of the fix.
Make the next one take minutes
Whether that first hour is fast or slow is decided long before the headline. The preparation that pays off:
- An inventory of public assets built from cloud accounts, DNS and certificate data, refreshed automatically.
- Scheduled external scans, so service and version data is days old. For internet-facing systems, weekly is a practical baseline.
- An owner for every asset, through tags or naming, so the exposure list turns into messages to specific people.
- Remediation deadlines by severity, agreed before an incident so nobody negotiates them during one.
- A one-page runbook: the steps above, who to call, where decisions get recorded.
The next time someone drops a CVE link into the team chat and asks “are we affected?”, the answer should take one filter and a version check.
