A critical vulnerability is announced: the 24-hour response plan for your website

Tuesday 21 October 2026, 14:00 UTC: PHP publishes four versions fixing two critical flaws exploitable without authentication. In the hours that follow, thousands of teams ask the same question: *which of our sites are affected, and who is dealing with it?* Those who have an answer in ten minutes have a response plan; the others improvise. This article describes the 24-hour plan we apply for sites under maintenance, using the PHP flaw as the example (the technical details are here). It is reusable for the next alert, whether it comes from PHP, WordPress, a plugin, Node.js or a library.

Hour 0: knowing the alert exists

You cannot react to what you do not know about. Security monitoring is the first building block, and it costs less than you think:

• Official announcements of the technologies you use: RSS feed or mailing list of php.net, WordPress, your framework, your critical plugins.
• Agency alerts: CISA in the United States, ANSSI in France and DGSSI in Morocco publish alerts for major flaws. PHP's was picked up by CISA the same day.
• GitHub advisories (GHSA) and Dependabot alerts for your applications' dependencies.
• Your host's communications, which often announce the rollout of a fix.

In PHP's case the CVE identifiers leaked the day before, which brought the release forward. Active monitoring lets you prepare the update window before the packages are even available.

Hour 0 to 1: the inventory answers in ten minutes

The question "which sites are affected?" should never take a day. An up-to-date inventory lists, for each site or application: the hosting and access, the PHP (or Node, or Python) version, the CMS or framework and its version, the critical plugins or dependencies, the exposure level (public, authenticated, internal), the owner and the last check. With that inventory, the PHP alert translates immediately into a list: three sites on mod_php to handle first, eight on PHP-FPM fixed by the host to verify, one intranet on 7.4 to migrate or isolate.

Hour 1 to 2: prioritise

Not everything can be handled at once. The order that limits risk:

1. Exposure: public sites first, then authenticated applications, then internal tools.
2. Risky configuration: for PHP, Apache with mod_php before PHP-FPM, since exploitation is demonstrated there with default settings.
3. Value: the store taking orders before the brochure page.
4. No fix available: systems on a version with no fix (PHP 8.1 and earlier) go into a separate queue: immediate temporary measures, then migration or offline.

Hour 2 to 8: update, in the right order

For each system, the same sequence, no exceptions:

1. Backup right before the intervention (files and data), even for a minor update. The 3-2-1 rule makes sure it is usable.
2. Update on a staging environment when the change is significant (PHP branch change, major plugin update). For a minor security update, going straight to production is acceptable, with an immediate check.
3. Apply in production, at a quiet time if the restart causes a few seconds of downtime.
4. Restart everything that needs it: PHP-FPM or Apache, queues, workers, rebuilt containers. A long-running process that is not restarted keeps the vulnerable version in memory. The detailed procedure is in how to update PHP on your server.
5. Temporary measures for systems that cannot be fixed right away: the vendor's recommended settings, a web application firewall, access restriction, or taking the site offline.

Hour 8 to 12: verify, do not assume

An update that was launched is not an update that was applied. Verification is done on what is actually served: the PHP version seen over the web (not just from the terminal), the critical journeys (login, form, order, checkout), the error logs, the scheduled tasks. For sites fixed by a host, verification matters even more because you did not see the operation: an unchanged version can hide a backport or an update that never happened; only an explicit confirmation settles it.

Hour 12 to 24: monitor and look for traces

Fixing closes the door; it does not tell you whether someone came in before. In the days following an alert, watch for signs of a compromise that predates the fix:

• PHP processes spawning a shell or downloading tools (the signal CISA cites for this flaw).
• Unknown or recently modified files in web directories, especially upload folders.
• New administrator accounts, unknown scheduled tasks, added SSH keys.
• Unusual outbound traffic, bulk email sending, load spikes with no cause.

A confirmed sign triggers the incident procedure: isolation, analysis, restoration from a clean backup, rotation of secrets. Our guide for a hacked site details that sequence.

After 24 hours: learn from it

Every alert improves the next one if you take ten minutes to note what was missing: a site absent from the inventory, lost server access, an unreachable host, a plugin that blocked the migration. Those notes feed the maintenance checklist and, often, a structural decision: dropping mod_php for PHP-FPM, leaving end-of-life branches before they reach that point, changing host, replacing an abandoned plugin.

This plan is what you buy with a maintenance contract

A critical alert on a Tuesday afternoon is the real test of website maintenance. Not the frequency of routine updates: the ability to respond within hours, with a ready inventory, valid access, a staging environment and a check afterwards. That is what we do for the sites and applications we look after, and what we can set up for yours. If the alert of 21 October caught you off guard, let's talk: the first deliverable is the inventory, and it already changes everything.