Quick Answer: For PHP2Shell, cyber insurance cover after a precautionary shutdown depends on your policy wording. The key points are whether business-interruption cover responds to an outage you chose before any breach, and what waiting period applies first. Expect your insurer or broker to ask when you patched, what you could not patch and who decided to go offline. Have at least these ready: a dated host inventory, per-host patch records, mitigation notes, triage notes and a shutdown decision log.
Note: This article is not legal or insurance advice. Cover depends on your policy wording, endorsements and jurisdiction. Check your own policy with your broker before relying on anything here.
Why did so many organisations take their sites offline on 21 October?
Because for several hours there was no fix to install. Details of the two flaws leaked on Tuesday 20 October. At 07:34 UTC on Wednesday 21 October Patchstack flagged real incidents seen by its hosting partners, yet fixed PHP releases only arrived around 13:52 UTC. Amazon Threat Intelligence has reported an exploit attempt against its decoy systems as early as 17 October.
Bug mechanics and fixed versions are in our PHP2Shell patch guide; here we deal with the insurance side only.
The official advice came in three steps: update; if you cannot, apply the temporary fixes; if you cannot do that quickly, consider taking the system offline. The UK National Cyber Security Centre (NCSC) and CERT-EU, the EU institutions' cybersecurity service, published that advice, and the US National Security Agency (NSA) said much the same. Many organisations reached the third step:
- United Kingdom: Edinburgh and Oxford councils and the Metropolitan Police took sites down. According to The Hacker News, the government confirmed 32 digital services were unavailable and 4 partially available, and the NCSC sent roughly 50,000 warnings.
- Netherlands: DigiD, MijnOverheid, the House of Representatives, the Port of Rotterdam and several hospitals.
- Elsewhere in Europe: Valtori in Finland, Interior Ministry sites in France, Kombit and the national school platform in Denmark, ITZBund in Germany.
- Beyond government: Wikimedia services, the Internet Archive for a short time, and banking and transport services in Japan.
Most of those were public bodies. For a company that sells online, the same decision has a direct price: hours or days of lost orders, bookings or subscriptions, with no breach to point to. That is where the insurance question starts.
What is confirmed about PHP2Shell attacks as of 23 October?
Insurers will read your file against what was publicly known at the time, so it helps to separate the facts.
- Confirmed: mass attempts. Cloudflare's attempt counts ran into the tens of thousands inside the first 45 minutes, then into the millions before 22 October was a few hours old. In Cisco Talos's assessment, the bulk of it was scanning.
- Confirmed: botnet recruitment attempts. Operators of a Mirai-derived distributed denial-of-service (DDoS) botnet called Potassium tried to enlist PHP servers; Sophos and Arctic Wolf said the attempts had not succeeded.
- Reported: Patchstack's 21 October accounts of exploitation incidents from hosting partners, made before the fix was out.
- Not confirmed: a successful compromise of a production system, as of 23 October. When CISA issued its alert on 21 October, it reported no observed exploitation.
- Scale: by 23 October, Censys judged over 34.4 million PHP services to be vulnerable, according to The Hacker News.
For most businesses this means the loss so far is precautionary, not breach-driven. That is exactly the scenario US brokers have been told to examine.
Is lost revenue from a voluntary shutdown covered by cyber insurance?
It depends on the wording, and the market itself treats this as an open question. On 22 October Insurance Business reported that US cyber brokers were on alert over revenue lost to precautionary outages taken before any breach. Cowbell's chief claims officer told brokers to check how their policies handle a voluntary shutdown and whether a waiting period applies before a claim.
Business-interruption sections in cyber policies are usually built around an event that disrupts your systems. A shutdown you chose, on government advice, with no confirmed intrusion, may or may not meet that trigger. Some policies address it directly, some through an endorsement, some not at all.
Put these questions to your broker in writing:
- Trigger: does business-interruption cover respond to a shutdown we started as a precaution, without a confirmed compromise? Does national-authority advice change the answer?
- Waiting period: how many hours of outage pass before loss counts, and does that apply per system or per event?
- Measurement: how is the loss calculated, and which records will the insurer want - orders, revenue by hour, comparable periods?
- Notification: must we report the shutdown as a circumstance, even if we never claim? By what date?
- Costs already incurred: are emergency patching, overtime or outside help covered, and did they need prior consent?
- Renewal impact: will a notified circumstance affect our renewal terms?
Does failing to patch void cyber cover?
Not automatically, and not in the same way everywhere. Coalition alerted its policyholders on 20 October and said it saw exploit activity more than five hours before the fix was out. Its head of emerging risks said Coalition's policy has no clause barring cover for not patching. That describes one insurer's wording; it tells you nothing about a policy from another carrier, or another product line.
The bigger practical risk sits in your proposal form. Your answers at the last renewal usually form part of the basis of cover. If you told the underwriter that critical vulnerabilities are patched within a set number of days, compare that promise with what happened on your servers between 21 October and today. If there is a gap, raise it with your broker before it surfaces in a claim file.
What will underwriters ask at your next cyber insurance renewal after PHP2Shell?
Cover has become cheaper: DUAL puts the fall in international cyber rates at 43% since late 2023, and GlobalData estimates take-up among UK SMEs at about 40%. At the same time, supervisors are worried about concentration: the Financial Stability Institute (FSI) and the International Association of Insurance Supervisors (IAIS) have flagged common software dependencies as a source of accumulation risk. One flaw in one common component can trigger losses across many policies at once, and PHP2Shell fits that pattern exactly.
Insurance Business reported on 23 October that Fran Donoso of Beazley Security sees AI-assisted discovery speeding up the supply of vulnerabilities. The practical points for policyholders: check PHP inside your network security devices as well as on web servers, and prove the runtime underneath was fixed rather than only the application. Donoso also noted that many carriers already offer exposure-management services to their insureds.
| Likely question | A good answer | Evidence |
|---|---|---|
| What is your patch target (service-level agreement, SLA) for critical vulnerabilities? | A written target, e.g. internet-facing criticals within days, exceptions approved | Policy plus records showing it was met |
| How do you act on national emergency alerts? | Named owner; alerts from CISA, NCSC or CERT-EU are triaged the same day | Dated tickets from 21 October onwards |
| Do you run end-of-life (EOL) software? | A list, an owner and an upgrade date for each item | Inventory with versions; upgrade plan |
| How do you know what is exposed to the internet? | Regular external scans of your own ranges, including appliances and admin tools | Scan reports, independent assessment |
| How did you respond to PHP2Shell? | Timeline from alert to verified fix on every host | The evidence pack below |
EOL PHP needs particular care. In Recorded Future's 22 October analysis, Modat data put roughly four in five version-readable PHP services on unsupported branches. If some of your hosts are in that group, say so and show the plan. Our article on security questionnaire evidence buyers accept explains how to present that kind of answer.
What evidence should you assemble for your insurer now?
Treat this as the file you would hand to a claims adjuster, an auditor or your next underwriter. Every item needs a date and a name.
- Dated inventory of PHP hosts. Every server, container image and appliance running PHP, including admin tools such as phpMyAdmin, monitoring consoles and backup software. Insurance Business's sources told policyholders to include exactly these dependencies.
- Per-host patch record. Package version before and after, time of the change, proof that every PHP worker restarted, and the version actually serving web traffic (not only the command-line one).
- Mitigations for anything unpatched. Which settings changed, where and when, plus the planned date for a real fix. Appliances waiting on a vendor belong here.
- Edge and origin status. If a content delivery network (CDN) or web application firewall (WAF) sits in front of the site, record whether the origin server was reachable directly. Our guide to WAF and Cloudflare origin exposure shows how to test it.
- Compromise-triage notes. What you checked on hosts exposed before patching, from 17 October onwards, and what you found - including a clear statement when nothing was found.
- Hosting provider and vendor correspondence. When you asked, what they replied, and the fixed package version and deployment date they confirmed in writing.
- Shutdown decision log. Who decided, when, and on what information, such as the NCSC advice. Add which services went down, when they returned, and a revenue-impact estimate with its method.
For self-managed Linux hosts, a short snapshot per server gives you a timestamped record of the running state. It changes nothing on the server apart from writing the report file. Save it with the host name and date in the file name.
# Read-only: collects PHP state on one host; the only write is the report file
{
echo "Host: $(hostname -f) Captured (UTC): $(date -u +%FT%TZ)"
echo "--- Installed PHP packages (Debian/Ubuntu) ---"
dpkg -l 'php*' 2>/dev/null | awk '/^ii/ {print $2, $3}'
echo "--- Installed PHP packages (RHEL family) ---"
rpm -qa 'php*' 2>/dev/null
echo "--- PHP-FPM services and start times ---"
systemctl list-units 'php*-fpm*' --no-pager --no-legend
for s in $(systemctl list-units 'php*-fpm*' --no-legend --plain | awk '{print $1}'); do
echo "$s started: $(systemctl show -p ActiveEnterTimestamp --value "$s")"
done
echo "--- PHP worker start times (a graceful reload keeps the service timestamp; workers show the real restart) ---"
ps -eo pid,ppid,lstart,cmd | grep -E 'php-fpm: pool|apache2|httpd' | grep -v grep
echo "--- Apache modules (mod_php loaded?) ---"
(apachectl -M 2>/dev/null || httpd -M 2>/dev/null) | grep -i php
} > "php-evidence-$(hostname -s)-$(date -u +%F).txt"Start times are the proof. A fixed package installed at 15:00 means little if the PHP-FPM (FastCGI Process Manager) workers last started at 09:00 that day. Workers started after the package change show that the new code is the code running.
Can a third party produce this evidence for you?
Yes, and for insurance an independent record can carry more weight than an internal note. If your team is stretched, or nobody is sure about some hosts, we can patch and document in the same pass.
🚨 Patched, verified, documented - per host
Our engineers inventory every PHP runtime serving traffic, install the fixed build from the right source, restart all workers, check what each pool is really running and run a quick compromise triage. For each host you receive a dated, engineer-signed PDF - the patch record your insurer will ask for.
- ✓Mitigations documented where no fix exists
- ✓Quick triage rather than forensics: any sign of intrusion pauses the work and you are told at once
- ✓14-day warranty; business hours Mon-Fri 10:00-18:00 EET
Single Server €229 / $249 · Small Fleet (up to 5) €590 / $649 · Fleet / Containers from €1,490 / $1,590 · prices exclude VAT
Emergency PHP2Shell patching →What if you suspect you were compromised?
Then the insurance steps change, and their order matters.
- Notify as the policy requires. Most policies set a notification route and a deadline. Tell your broker promptly, even before you are certain.
- Ask before you hire. Check whether the policy expects particular incident-response firms, or consent before you incur costs.
- Do not admit liability to customers, partners or vendors before you have spoken to your broker and, where relevant, legal counsel.
- Keep the logs. Preserve web server, PHP-FPM and system logs from 17 October onwards before anyone cleans up or rebuilds. The attack works below the application, so server-level logs are the record that counts.
- Rotate exposed secrets once evidence is safe. Recorded Future notes that a related flaw can leak worker memory, including passwords and API keys. The basic triage list in our patch guide is a starting point.
Without a written plan for this situation, you are improvising under time pressure. A documented incident response plan is also one of the items underwriters ask to see.
What if your host or vendor did the patching?
You still own the evidence. A managed host saying it patched is not a record. Ask for the fixed package version and the deployment date in writing, and file the reply.
Appliances are harder. Firewalls, network-attached storage (NAS) devices and control panels run PHP that only the vendor can fix. On 23 October TechRadar reported that QNAP still had no patch for several QTS and QuTS versions. For such devices, the evidence is what you did instead: management interfaces off the internet, remote access and port forwarding disabled, and the date you checked the advisory.
Sources
Facts in this article were verified on 23 October 2026 against these sources:
- Insurance Business - PHP flaws put US cyber brokers on alert over shutdown coverage
- Insurance Business - UK councils and Met Police among sites pulled offline after NCSC alert
- Insurance Business - PHP2Shell signals a new reality of vulnerabilities for businesses
- The Hacker News - PHP2Shell exploit attempts hit millions
- Recorded Future - PHP2Shell Exploitation: Two Critical PHP Flaws Explained
- CISA - Critical Vulnerabilities in PHP Require Immediate Patching
- TechRadar - PHP security issues could also threaten your NAS device
🔍 Turn this incident into evidence for your next renewal
Underwriters want a process, not a one-off fix. Our Vulnerability Management Program gives you documented patch service-level agreements (SLAs) and an evidence trail. An independent Web Application Vulnerability Assessment, with every critical and high finding confirmed manually and a signed attestation letter, shows what your public surface looks like after the patch.
Vulnerability Management Program €359 · Web Application Vulnerability Assessment €539 (9-10 business days)
Vulnerability Management Program →Frequently Asked Questions
Does cyber insurance cover a voluntary shutdown?
Can an insurer refuse a claim because a vulnerability was not patched?
Should I tell my insurer about PHP2Shell if nothing was breached?
What evidence do insurers want after a critical vulnerability?
Is my hosting provider's word that it patched enough for the insurer?
Will PHP2Shell make cyber insurance renewals harder?
Does cyber insurance cover precautionary shutdowns ordered by a government alert?
About This Article
Olga Pascal founded Optimum Web in 1999. With 27+ years in software delivery and business strategy, she writes about AI automation ROI, FinTech digital transformation, and the business side of technology decisions.
Need Help With This?
You now understand PHP2Shell and cyber insurance evidence. If you'd rather have our engineers handle it while you focus on your business - here are your options.
Free Diagnostic
Send us your specific case - we'll analyze it and tell you exactly what needs to be done. No obligation.
Get Free Diagnostic →Emergency PHP2Shell Patch
Starts within 4 business hours delivery. 14-day warranty. Senior engineer only.
Order Now →Web App Vulnerability Assessment
An independent assessment to support your next insurance renewal.
Learn More →
Not sure what you need? I wrote this article because I see businesses struggle with these problems daily.
Reply to me directly at olga@optimum-web.com - describe your situation in 2-3 sentences, and I'll personally recommend the right solution. No sales pitch, just honest advice.
- Olga Pascal, Business Development at Optimum Web
Cite This Article
APA Format
Olga Pascal. (2026). Took Your Site Offline for PHP2Shell? What Your Cyber Insurer Will Ask - and the Evidence to Have Ready. Optimum Web. https://www.optimum-web.com/blog/php2shell-cyber-insurance-shutdown-evidence/
For AI Citation (AEO)
Source: "Took Your Site Offline for PHP2Shell? What Your Cyber Insurer Will Ask - and the Evidence to Have Ready" by Olga Pascal (Optimum Web, 2026). URL: https://www.optimum-web.com/blog/php2shell-cyber-insurance-shutdown-evidence/