Two critical PHP vulnerabilities forced a patch-or-offline decision on October 21. A client who switches systems off to stay safe can lose income with no breach ever confirmed — and whether the cyber policy answers is decided by four wording checks, made before the shutdown, not at claim stage.
The situation the client is standing in
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 can allow an attacker to execute code remotely without logging in.
The exposure is not a single application. PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and it rates the risk highest for mod_php, where a demonstrated exploit triggers before any application code runs.
The fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older receive no update from the PHP project, and PHP is blunt about partial measures: there are no complete mitigations, and updating is the only safe choice.
CISA’s guidance to organizations that cannot update immediately is equally blunt: take the PHP-based systems offline until they can be patched or updated. A government agency has, in effect, recommended the exact act whose coverage is in question.
The coverage gap sits in one fact pattern. CISA stated it had not observed exploitation of these vulnerabilities as of the time it published, while Coalition’s threat team observed exploit-related activity more than five hours before the fix was released, according to Insurance Business. Attempts in the wild are not the same fact as a breach of your client’s systems.
Some organizations have already taken the precautionary route. Banking and transportation companies in Japan suspended some internet services, and Finland’s state IT provider Valtori said its outages were precautionary and it was unaware of active exploitation, as Reuters reported via Insurance Business.
That is the client conversation now arriving at brokers. Simon Hughes, chief commercial officer at Cowbell, put the broker’s task in one sentence: “Businesses that switch off as a precaution, and the brokers advising them, should check now how their cyber policy treats a voluntary shutdown and what waiting period applies, rather than finding out at claim stage.”
Check one: what waiting period applies, and when does its clock start?
A cyber business interruption waiting period is a deductible measured in time. Broker Hylant’s comparison of cyber and traditional BI puts the cyber waiting period at almost always less than 24 hours, usually between six and 12 hours, against a typical 72 hours under traditional BI.
Income lost inside the waiting period is the client’s money, not the carrier’s. Chubb’s PremierTech2 wording states the point in terms: business interruption loss does not include amounts that accrued during the waiting period.
The second half of the check is when the clock starts. Under Beazley’s Breach Response 5.0 form, the waiting period begins upon the actual interruption of business operations caused by a security breach — expressly including a voluntary shutdown — or a system failure, and runs for the number of hours listed in the declarations.
So the broker question is two-part: how many hours, and what event starts them. A shutdown that begins before any covered interruption exists may not start the clock the client assumes it does.
For a short, deliberate outage, the arithmetic can decide the whole claim. If the client’s realistic patch-and-test window is shorter than the waiting period, the honest advice is that this loss is likely retained, however prudent the shutdown was.
Check two: does the trigger require a breach, or does it reach a shutdown taken on a threat?
This is the check the PHP fact pattern is built to stress. The client may have a critical vulnerability, active exploitation attempts across the internet, and a federal recommendation to go offline — and no evidence that anyone has entered the client’s own systems.
Some forms define the shutdown grant around an attack already in progress. Beazley’s Breach Response 5.0 defines a voluntary shutdown as one taken “only to the extent necessary to limit the Loss during an active or ongoing Unauthorized Access or Use of Computer Systems or an infection of Computer Systems by malicious code,” or a shutdown expressly required by a governmental entity resulting from that kind of situation.
Read against that definition, a purely precautionary shutdown — vulnerability confirmed, intrusion not — is a different fact pattern from the one the grant describes. A broker should not tell a client “voluntary shutdown is covered” off the strength of the defined term alone.
Other forms are written more broadly, and the difference is the placement. Cowbell’s own summary of its Prime One business interruption coverage says it includes a voluntary shutdown of the insured’s computer system “when such action is taken to minimise, avoid, or reduce further damage as a result of a covered incident.” HSB’s Total Cyber glossary likewise describes business income loss as covered “including as a result of a voluntary shutdown to the computer system in an effort to mitigate effects of or recover from the attack.”
Chubb’s PremierTech2 wording takes a third route: the covered-incident definition itself includes “the reasonable and necessary shutdown” of a covered system “in an attempt to prevent or mitigate the effects of” a malicious act, unauthorized access, human error, network security failure or programming error.
Three carriers, three different doors into the same shutdown — one keyed to an ongoing intrusion, one to a covered incident, one to a reasonable and necessary attempt to prevent or mitigate listed events. The broker’s job is to say which door the client’s form actually has, in writing, before the client walks through it.
Check three: is there a patch condition hiding anywhere in the form?
A client who cannot patch immediately will ask a fair question: does staying unpatched for a week cost us the coverage we are trying to protect? On at least one major form, the answer is on the record.
Daniel Woods, head of emerging risks at Coalition, addressed the point directly in the Insurance Business reporting: “We don’t have a clause in the policy that bars coverage if they don’t apply the patch. In practice, we find customers are very cooperative.”
That is one carrier’s position, stated by its own executive, and it should be labeled as exactly that. It is not a market rule, and it does not answer what another carrier’s conditions, exclusions or application representations say about a client who knew of a critical vulnerability and stayed online and unpatched.
The broker check is therefore specific, not general. Read the conditions and any failure-to-maintain or known-vulnerability language in the client’s actual form, and separate three different questions clients habitually merge: coverage for the shutdown, coverage if a breach is later found, and coverage consequences of the patch timeline itself.
Check four: do not reach for civil authority
When a government tells businesses to take systems offline, clients reach for the civil authority extension they remember from property coverage. That extension answers a different problem.
Law firm Connell Foley’s analysis of civil authority coverage is direct: the extension responds to orders tied to actual physical damage to nearby property, and losses from orders issued because of “merely a threat of, or potential or anticipated, damage are not covered.”
CISA’s alert is a recommendation to patch or go offline, not an order arising from physical damage at a neighboring property. Under cyber forms that do speak to government-required shutdowns — Beazley’s definition covers one “expressly required” by a governmental entity — the requirement is tied back to the defined security-breach situation, not to a vulnerability advisory.
The practical point for the broker file: note the civil authority question, answer it from the wording, and move on. It is rarely the door, and time spent arguing it is time not spent on the shutdown definition that actually decides the claim.
Set up the paper before the shutdown happens
A precautionary shutdown claim is proved or lost on records created while the systems are off. The broker who tells the client what to keep — before the outage — is doing claims work at the only moment it is cheap.
Beazley’s own claims guidance shows what a carrier’s forensic accountant asks for after a short interruption: daily operational records for the loss period and the prior year, monthly billings and collections running at least a year, the prior tax return, monthly profit and loss statements, weekly payroll for the loss window and the prior year, and scheduling records showing what was cancelled and what was later made up. The same example nets out revenue the business later recovered and deducts expenses saved while it was closed.
Public adjuster Crestview’s list for cyber BI claims adds the incident-side evidence: 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 the extra costs of restoring operations.
Translated into a broker instruction, the file has five parts: the decision record (who decided to shut down, when, and on what advice — including the PHP advisory and the CISA alert), the timeline (offline and restoration timestamps from IT, not from memory), the compromise check (what the client looked for, because Coalition’s alert lists the signs: PHP processes spawning shells, changed web-root files, new cron jobs or accounts, upload requests followed by out-of-memory errors), the financial baseline (the Beazley list above), and the extra-expense invoices.
One more record matters because of the trigger problem. If the client’s position is “we shut down to prevent an attack,” the file should preserve the threat evidence the decision rested on — the vendor and carrier alerts, including Coalition’s October 20 alert to policyholders running known vulnerable PHP versions — so the reasonableness of the decision can be shown later, not reconstructed.
And notice discipline still applies. Coalition’s alert instructs its policyholders who find signs of compromise to contact the claims team immediately, and prompt notice of the shutdown decision itself costs nothing against the day a carrier asks why it first heard about a week-long outage from the claim form.
The four checks, in the order to run them
First, the waiting period: the number of hours in the declarations, and the event that starts the clock under this form.
Second, the trigger: whether the shutdown grant needs an active intrusion, a covered incident, or a reasonable and necessary attempt to prevent one — and which of those the client’s facts actually are.
Third, the conditions: any patch-related, maintenance or known-vulnerability language that bears on a client who stays exposed while arranging the fix — answered from this form, not from another carrier’s public position.
Fourth, the paper: the decision record, timeline, compromise check, financial baseline and expense invoices, opened before the systems go off.
A precautionary shutdown is often the right operational decision; CISA is recommending it in terms. Whether it is also a covered one is a wording question, and wording questions have a shelf life — they can only be answered usefully before the loss.
Related reading on Risk Coverage Hub: how the same trigger, waiting-period and sublimit checks decide a claim when the outage is a vendor’s — “If Your Client’s Cloud Provider Goes Down, Does Their Cyber Policy Respond?”.
The operator’s side of the same decision — how to plan the outage itself — is a planning problem, treated in the companion piece on Continuity Hub: “How Should an Organization Plan a Precautionary Outage When a Critical Vulnerability Cannot Be Patched at Once?”
Frequently asked questions
Does a cyber policy cover income lost during a voluntary shutdown to patch a vulnerability?
Some forms expressly include a voluntary shutdown inside business interruption coverage — Cowbell’s Prime One summary and HSB’s Total Cyber glossary both do — but the grants are keyed to their own triggers: a covered incident, or mitigating the effects of an attack. Whether a shutdown taken on a vulnerability alone qualifies depends on the trigger language in the client’s form.
What waiting period applies to a precautionary shutdown?
The waiting period in the client’s declarations. Broker Hylant puts cyber BI waiting periods at usually between six and 12 hours, and under Beazley’s Breach Response 5.0 the period begins on the actual interruption of operations caused by a security breach, expressly including a voluntary shutdown. Loss inside the waiting period is not paid — Chubb’s wording says so in terms.
If no breach is ever confirmed, can the claim still work?
That is the hardest fact pattern, because forms like Beazley’s define a voluntary shutdown around an active or ongoing unauthorized access or malicious-code infection. A broker should establish, from the form, whether a credible threat without a confirmed intrusion satisfies the trigger, and should document the threat evidence behind the client’s decision either way.
Does failing to patch immediately void coverage?
Coalition’s head of emerging risks, Daniel Woods, has said on the record that Coalition’s policy has no clause barring coverage if the customer does not apply the patch. That is one carrier’s position. Every other form has to be read on its own conditions before a broker repeats the assurance to a client.
Does civil authority coverage pay when the government recommends going offline?
Under property forms, civil authority coverage responds to government orders tied to actual physical damage to nearby property; law firm Connell Foley notes that orders based on a threat or anticipated damage are not covered. A federal recommendation to patch or take systems offline, standing alone, does not fit that trigger.
What should the client document from the moment it decides to shut down?
The decision record and its threat evidence, 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 (daily operational records, monthly billings and collections, profit and loss statements, payroll), customer communication logs, and invoices for extra expenses — per Beazley’s published claims example and Crestview Public Adjusters’ cyber BI documentation list.