The October 21 PHP emergency release left some organizations with a hard choice: stay online and exposed, or take services offline before any attack lands. A precautionary outage goes well when the decision rule, the sequence and the record were settled in advance — here is how to plan one.
Why this decision now has a name
On October 21, 2026, the PHP project released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 by the PHP security team. Both flaws can let an attacker run code on a server without logging in.
PHP’s scope statement is what turns a patch into an outage question. All PHP installations serving web requests are at risk — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed — and PHP states there are no complete mitigations: updating is the only safe choice.
CISA drew the operational conclusion in its October 21 alert. Organizations that cannot update immediately, or that still run unsupported PHP 8.1 or earlier, should take PHP-based systems offline until they can be patched or updated.
CISA also stated it had not observed exploitation of the vulnerabilities as of publication, while insurer Coalition reported its sensors saw exploit-related requests more than five hours before the fix shipped. A precautionary outage is therefore a decision taken on a credible threat, not on a confirmed incident — which is exactly why it has to be planned rather than improvised.
Step one: inventory before you decide anything
You cannot sequence an outage for systems you have not found. CISA’s first action is an inventory of systems running any version of PHP, with a warning built in: PHP is often a component of other software, and its prevalence may not be directly observable.
Coalition’s alert makes the same point from the response side. PHP runs administrative tools that manage firewalls, databases, phone systems and backups, and the insurer’s recommended first step is to find every PHP system — websites, internal tools, vendor appliances, and copies bundled with control panels such as cPanel and Plesk — starting with the admin tools.
The planning consequence is simple. The inventory is a standing artifact of the continuity plan, refreshed before it is needed, with an owner and a patch route named for every entry — because the systems hardest to patch in an emergency are the ones nobody knew were running PHP.
End-of-life versions belong on that inventory in their own color. PHP 8.1 and older receive no update from the PHP project, so Coalition’s guidance for them is different in kind: upgrade to a supported version, obtain a vendor backport, and until then take those systems off the internet.
Step two: set the decision rule before the emergency
A precautionary outage is a decision about how much disruption a service can withstand. Everbridge’s framing of operational resilience defines the two terms the decision needs: important business services are the services an organization determines must be protected, and impact tolerances define how much disruption those services can withstand.
Write the rule against those tolerances in advance. For each important service, the plan should state the order of preference — patch in place, isolate from the internet, or take fully offline — and the condition that moves the service from one state to the next.
CISA’s guidance supplies the default rule when no local rule exists: patch immediately, prioritizing internet-facing systems; if a system cannot be updated, it goes offline until it can be. Deviating from that default is sometimes right, but it should be a recorded decision, not drift.
The decision also needs a named owner and a threshold written in calm conditions. “We will take the service offline if a fixed version cannot be deployed and verified within the window our impact tolerance allows” is a rule a night-shift team can execute; “we will monitor the situation” is not.
Step three: sequence the outage, don’t just announce it
Sequence follows exposure. CISA directs organizations to prioritize internet-facing systems for patching, and Coalition’s action list starts remediation with the administrative tools — the interfaces that hold credentials and control over other systems.
Patching is not finished when the package installs. Coalition’s guidance is to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later and then restart PHP-FPM or the web server so the new version actually loads — and where a distribution or hosting vendor supplies PHP, to confirm with the vendor that the fix is in their package, because their version numbers may not match PHP’s.
Where patching cannot happen at once, the bridge measures are named and bounded. PHP lists settings that reduce exposure on specific attack paths — among them session.upload_progress.enabled=0 with a restart of every worker, a memory_limit set so applications cannot override it, and a low post_max_size — and states plainly that they do not make an installation safe. CISA adds that a web application firewall may provide some protection until systems are updated.
A plan should therefore treat every bridge measure as a dated, expiring state: what was applied, when, what risk remains, and the deadline by which the service is either patched or offline. Finland’s state IT provider Valtori, whose outages were precautionary, expected restoration to take days or weeks because systems needed careful testing alongside updates, as Reuters reported — a useful planning reminder that the outage window includes verification, not just installation.
Step four: run communications off the plan, not the moment
An outage the organization chose still surprises everyone who was not in the room. Continuity planning practice, as broker HUB International sets it out, is to define internal and external stakeholders for communication in advance, develop vetted holding statements for employees, customers and media before they are needed, communicate decisions to the appropriate audiences, and train the response team on its responsibilities.
The precautionary case has one message advantage worth using: the organization acted early, on published government and vendor guidance. The holding statement should say what was taken offline, why (a critical vulnerability with emergency fixes issued October 21), what is being done, and when the next update will come — and it should be approved before the outage, not drafted during it.
Keep the communications themselves. They become part of the record in the next step: public adjuster Crestview’s documentation list for cyber business interruption claims expressly includes customer communication logs where operations or deliveries were affected.
Step five: document the decision as if it will be audited — it may be
A precautionary outage has no attacker to point at, so the record is the evidence. Build it while the event runs: who decided, on what information, at what time, what was taken offline, and when it came back.
The insurer’s side of that record is already published. Beazley’s claims guidance shows its forensic accountant requesting, after a four-day interruption, daily operational records for the loss period and the prior year, monthly billings and collections over at least a year, the prior tax return, monthly profit and loss statements, weekly payroll for the loss window and prior year, and scheduling records showing cancellations and later make-up work.
Crestview’s list adds the technical half: system logs and forensic reports showing when and how the event occurred, downtime duration reports from the IT team, revenue records from comparable periods before and after, customer communication logs, and invoices for extra costs incurred restoring operations.
The compromise check belongs in the same file, timestamps attached. Coalition lists the signs to look for — PHP processes starting shells or tools such as curl or wget, new or changed files in the web root, new cron jobs or user accounts, upload requests followed by out-of-memory errors or a run of HTTP 500 errors, repeatedly crashing PHP workers — and CISA likewise directs defenders to monitor for PHP worker processes launching shells or downloading tools. A documented “we looked, and here is what we found” is what separates a precautionary outage from an unexplained one, for an insurer and for an auditor alike.
Notice runs on the same clock. Coalition instructs its policyholders who find signs of compromise to contact its claims team immediately; a planner’s version of that rule belongs in the plan itself: who notifies the broker and carrier, at what point in the outage, with what packet.
Step six: fold the event back into the plan
The outage is also a test the organization did not have to schedule. Record where the inventory was wrong, which services had no patch route, which decisions waited for a person who was not reachable, and which tolerances proved unrealistic — Valtori’s days-to-weeks restoration estimate is the standing warning that patch-plus-test time is usually longer than the meeting assumed.
Then rehearse the gap before it recurs. HUB International’s continuity steps end where they should: train the response team on its responsibilities and test the plan through exercises. A precautionary-outage annex that has been walked through once will outperform a thicker plan that has only been read.
The measure of the planning is not whether the outage was avoided. On the facts of October 21 — a critical, unauthenticated, remotely exploitable flaw in software running a large share of the web, with a federal agency recommending offline as the alternative to patching — the outage may be the competent outcome. The measure is whether the organization can show it decided on purpose, in sequence, and on the record.
The coverage side of this same decision — what a cyber policy actually says about a voluntary shutdown, its waiting period and its trigger — is a wording question; the companion broker treatment runs on Risk Coverage Hub.
Frequently asked questions
When should an organization choose going offline over patching in place?
When a fixed version cannot be deployed and verified within the service’s impact tolerance. CISA’s default is explicit: organizations that cannot update immediately should take PHP-based systems offline until they can be patched or updated, prioritizing internet-facing systems for the patch itself.
What belongs in the inventory before an emergency?
Every system running PHP, including the copies that are not obvious: websites, internal tools, vendor appliances, control panels such as cPanel and Plesk, and administrative tools for databases, firewalls, backups, monitoring and phone systems — per CISA’s inventory action and Coalition’s recommended actions, with end-of-life versions (PHP 8.1 and older) flagged, because they receive no update from the PHP project.
Do temporary settings make an unpatched system safe?
No. PHP states its interim measures reduce exposure to specific attack paths but do not make an installation safe, and that there are no complete mitigations — updating is the only safe choice. CISA describes a web application firewall the same way: some protection until systems are updated.
What should be documented during a precautionary outage?
The decision record (who, when, on what guidance), offline and restoration timestamps, the compromise-check results, system logs and forensic reports, downtime reports, baseline financial records of the kind Beazley’s forensic accountants request, customer communication logs, and extra-expense invoices — per Beazley’s published claims example and Crestview Public Adjusters’ documentation list.
How long should the plan assume an outage will last?
Longer than the patch itself. Restoration includes testing before services return; Finland’s state IT provider Valtori, which took systems offline as a precaution in this event, expected restoration to take days or weeks for exactly that reason, as Reuters reported. Impact tolerances should be set against the full patch-verify-restore window, not the install time.