First Hours After a Critical CVE: Checklist

A top-severity vulnerability in a core component is published. From that moment the clock runs for everyone, attackers included. The difference between a calm day and a bad week is rarely the patch itself. It is what you do in the hours before and after it. This is the sequence we follow, written so you can adapt it to your own fleet.

Hour zero: read the advisory twice

Read the advisory once to understand the flaw and once to understand the conditions. Most serious advisories come with qualifiers: only when a particular module is loaded, only in a particular server mode, only when a feature is reachable from the network. Those qualifiers decide which of your hosts are urgent, which are merely affected, and which mitigation fits.

Write down three things before touching anything: the affected package names, the fixed upstream release, and the conditions for exploitation. Everything that follows is checked against that note.

Find every host that runs it

Ask the package database on every host rather than relying on what you believe is installed:

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

Then check the conditions. If the flaw lives in a module, list what is actually loaded. If it needs a feature to be reachable, check whether it is. Sort the result into three groups: exposed and reachable, installed but not exploitable as configured, and not present. The first group gets mitigated now.

Mitigate before the fix exists

There is almost always something you can do before a fixed package is available: disable the vulnerable feature, change a configuration value, put a rule at the edge that blocks the request shape the exploit needs. Choose the least disruptive mitigation that closes the path, and apply it with discipline:

Keep a list of every mitigation you placed, so you can lift the ones that cost performance once the real fix lands. Mitigations that cost nothing can stay.

Build the fix yourself if you have to

Sometimes the upstream project has released fixed source and the distribution has not packaged it yet. Waiting is an option, but it is not the only one. When we decide not to wait, we build the package ourselves: from the distribution maintainer's own specification, in a clean throwaway container, from source whose checksum is verified against the project's official download page, with a release tag chosen so the vendor's own build replaces ours automatically when it arrives. The packages go into our own mirror with their checksums on record. The full method, with commands, is in Your own RPM mirror, and building the fix before the distro ships it.

The decision to build is a judgment, not a reflex. Build when the flaw is being exploited or trivially exploitable, the affected hosts are reachable, and no mitigation closes the path well enough. Otherwise a solid mitigation plus a short wait for the vendor's package is usually the calmer choice.

Keep a record, and tell people

Keep a timeline as you go

Open a plain text file at hour zero and write one line per action, with the time: advisory read, inventory done, mitigation placed on which hosts, package built, each host patched, log review finished. It costs seconds per line. It gives you the exact exposure window for every host, which the log review needs, and it turns the report you owe afterwards into an edit rather than an exercise in memory.

Tell people before they ask

The people who depend on the affected systems will hear about a famous vulnerability from the news, often within hours. Tell them first. A short message stating whether their systems are affected, what has been done already and when the fix will land is worth more than a perfect report a week later. If any step needs downtime, agree the timing with them before you take it.

Roll out one host at a time, with proof

Every host gets a pre-check and a post-check, and the two are compared, not eyeballed:

php -m | sort > pre-modules.txt      # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

On a larger fleet, automate the careful part rather than skipping it. A rollout that upgrades one server per run, samples real sites before and after, and halts the whole sweep and calls an engineer the moment a single site fails to come back is both faster and safer than a human working through a list at night.

Then ask whether the window was used

Patching closes the door. It does not tell you whether someone walked through it while it was open. Once the rollout is done, search the web and authentication logs for the period between disclosure and patch on every exposed host. Look for the request shapes the exploit needs, for unexpected processes or files created in that window, and for logins that do not fit the usual pattern. Write down what you found, including "nothing", because the people who depend on those systems will ask.

The short version

Read the conditions, not just the severity.
Inventory from the package database, not from memory.
Mitigate within hours.
Build the fix yourself only when it is warranted, and do it the clean way.
Keep a timeline and tell the people affected early.
Roll out one host at a time with comparable pre and post checks, and an automatic stop.
Review the exposure window in the logs, and report it.

If a disclosure lands and you would like help working through it on your own platform, we are around. Talk to an engineer

The first hours after a critical CVE: a working checklist