This guide is general information, not legal or insurance advice. Your policy wording, and your insurer or broker, decide what you need to report and keep.
The short answer
Insurers are paying attention to PHP2Shell. Cyber insurer Coalition alerted all its policyholders with internet-exposed PHP on October 21, 2026. It told them to find every PHP system, update or get a vendor backport, and check for compromise (source: Coalition).
Whether or not your insurer has written to you, keep a dated evidence pack:
- a list of every PHP system;
- a patch status for each CVE, with how you know;
- PHP’s recommended setting for CVE-2026-115560;
- your host’s written confirmations;
- what you did while you patched;
- what you checked for signs of compromise since October 17, and what you found;
- which secrets you rotated;
- who decided what, and when.
Describe results exactly as far as the evidence goes, and no further.
What insurers have said so far
We only cite insurer notices we’ve verified at source. As of October 23, 2026, that’s one insurer:
- Coalition alerted all its policyholders with internet-exposed PHP on October 21. It told them to find every PHP system, update or get a vendor backport, and check for compromise (source: Coalition).
- Coalition’s own honeypots recorded 3,839 requests for PHP configuration pages in a single hour after the release, against about 100 normally (source: Coalition).
Other insurers may have sent their own notices. If yours did, follow its steps first. Quoting an insurer here doesn’t mean it endorses this guide or any provider.
Why written, dated evidence matters
- “We patched” isn’t evidence. A version number can’t prove whether PHP is patched: backports keep old version numbers, and a patched package isn’t running until PHP’s worker processes restart (source: AlmaLinux).
- The window starts before the patch. Amazon’s threat intelligence team saw the first exploitation attempts on October 17, four days before the patches were released (source: BleepingComputer). It advises that defenders “should not assume the public disclosure date is the earliest date of exploitation.” (source: BleepingComputer)
- There’s still an open issue. On October 23, PHP disclosed CVE-2026-115560, which the October 21 releases don’t fix, and recommended a configuration change in the meantime (source: php.net advisory on CVE-2026-115560, October 23, 2026). A record that ignores it is incomplete.
- The facts may change. As of October 23, 2026, security firms and governments had reported widespread exploitation attempts but no publicly confirmed successful compromise. The one exception: Palo Alto Networks’ Unit 42 reported a compromise at one European government entity, which hadn’t been independently corroborated (source: Beazley Security Labs). If that changes, you’ll want records made at the time, not reconstructed later.
The evidence pack
| # | Keep | What it shows | Tips |
|---|---|---|---|
| 1 | Inventory of PHP systems | Every site and server that runs PHP, including staging and old copies: the first step Coalition gave its policyholders (source: Coalition) | One row per system: owner, host, who manages PHP |
| 2 | Patch status per CVE | For each PHP runtime: CVE-2026-109618 and CVE-2026-109619, status, how you know (evidence level), and the UTC time it was true | Use the four evidence levels: runtime-verified, package-verified, host-attested, external indicator only |
| 3 | The CVE-2026-115560 setting | Where it was set (php.ini, PHP-FPM pool or server configuration) and when PHP was restarted (source: php.net advisory on CVE-2026-115560, October 23, 2026) | A setting made in application code doesn’t count (source: php.net advisory on CVE-2026-115560, October 23, 2026) |
| 4 | Host or developer confirmations | Many shared and managed hosts reported patching PHP on their managed plans; self-managed servers must patch themselves (source: GoDaddy) | Ask for a dated reply for your account (the questions), and save dated copies of status pages |
| 5 | Mitigations while you patched | Firewall rules and when they were switched on; any maintenance page | Firewalls buy time but don’t replace the patch (source: Beazley Security Labs) |
| 6 | Compromise review notes | What was checked, from October 17 onwards, which data was unavailable, and what was found | See “How to describe the results” below |
| 7 | Secrets rotation log | Which passwords, keys and tokens were changed, and when. One flaw can leak memory that may include passwords, session tokens and API keys (source: The Hacker News) | Record the date and owner of each rotation; never record the secrets themselves |
| 8 | Decision log | When you learned about PHP2Shell, what you decided (patch, mitigate, go offline), who approved it, and why | One line per decision, with a date and a name |
| 9 | Correspondence | Alerts received from your insurer or broker, and your replies | Keep the originals |
How to keep it
- Date everything, in one time zone, ideally UTC.
- Keep originals unchanged. Export logs and reports. Don’t edit them, and store copies somewhere other than the server they describe.
- If you suspect a compromise, preserve evidence before anything is removed. Copy logs and suspicious files first. Then bring in incident response, and read your policy’s notification steps, or ask your broker.
- Ask how long to keep it. Retention periods depend on your policy and your legal obligations. Your broker or legal adviser can tell you. Until then, delete nothing.
How to describe the results
What you write may be read by someone deciding a claim, so precision protects you.
| Write | Why |
|---|---|
| “As of 2026-11-03 14:20 UTC, patched for CVE-2026-109618 and CVE-2026-109619, with PHP’s recommended mitigation for CVE-2026-115560 in place.” | Specific, dated, and it names the open issue (source: php.net advisory on CVE-2026-115560, October 23, 2026) |
| “Evidence level 2: package changelog names both CVEs; PHP workers restarted after the update.” | Says how you know (source: AlmaLinux) |
| “No evidence of compromise found in the checks listed,” followed by the list of checks and the data that wasn’t available | PHP’s advisory warns that “absence of an error in logs is not proof of safety.” (source: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)) A list of checks is honest about the limits |
| “Mitigated on [date] with [firewall rule]; patch scheduled for [date].” | A firewall is a bridge, not a fix (source: Beazley Security Labs) |
Avoid blanket statements. A blanket all-clear, or a “no risk” line, says more than any check can show, and that’s exactly the kind of statement that’s hard to defend later.
Security questionnaires
When a customer, partner or insurer sends a questionnaire, answer from the evidence pack and attach the dated record where you’re allowed to. An evidence pack is evidence you can use in questionnaires. It shows what you did; it doesn’t satisfy any standard on its own, and nobody should tell you it does.
Agencies answering for clients can use the same pack per client. The agency triage guide has a one-page status format.
Sourced facts
Full wording, primary sources and dates: /sources.
| ID | Fact | Primary source | Date |
|---|---|---|---|
| S-48 | Coalition alerted all policyholders with internet-exposed PHP; told them to find, update or backport, and check for compromise | Coalition | Oct 21, 2026 |
| S-06d | Coalition honeypots: 3,839 requests for PHP configuration pages in one hour, against about 100 normally | Coalition | Oct 21, 2026 |
| S-06b · Q-09 | First attempts Oct 17; don’t assume disclosure is the earliest date | BleepingComputer | Reported Oct 22, 2026 |
| S-07 | No confirmed compromise except one Unit 42 report | Unit 42 | Oct 23, 2026 · LIVE |
| S-02b | CVE-2026-115560 unfixed; server-level setting; status wording | php.net | Oct 23, 2026 · LIVE |
| S-09 | A version number can’t prove a patch | AlmaLinux | Oct 21, 2026 |
| S-05b | Named hosts reported patching managed plans; self-managed servers must patch themselves | Hostinger · WP Engine | Oct 21–23, 2026 · LIVE |
| S-04b | Memory leak may expose secrets | The Hacker News | Oct 21, 2026 |
| S-10 | Firewalls don’t replace the patch | Beazley | Oct 21–23, 2026 |
| Q-11 | “absence of an error in logs is not proof of safety.” | GHSA-6wmf-4rv5-p3rp | Oct 21, 2026 |
Frequently asked questions
Does keeping this evidence affect my premium or a claim?
We can’t say, and you should be wary of anyone who promises either. Premiums and claims are your insurer’s decisions under your policy. What a dated evidence pack does is let you answer questions accurately when you’re asked.
My insurer sent a PHP alert. What should I do with it?
Read it, follow its steps, and keep it with your evidence pack. If it asks for a reply or a confirmation, check your policy wording or ask your broker about what’s required and by when.
What if our compromise review finds something?
Stop, and preserve evidence before anyone removes or changes anything: copy logs and suspicious files to somewhere other than the affected server. Then follow your policy’s notification steps, or ask your broker, and bring in incident response.
Our host patched for us. Is their status page enough for the file?
Keep it, dated, but ask for a written reply that covers your own account. A general status page isn’t specific to your site, and status pages change (source: GoDaddy). The questions to ask.
Want the evidence pack done for you?
- Patch Verification & Compromise Review. Your developer or host gives us read-only access: a dedicated login that can look but not change anything, shared through a secure link, never by email. We change nothing on your server. We collect items 2, 3 and 6, and you get a plain-English report: where each fix stands, as of a stated time, a compromise review from October 17, and a list of secrets to rotate if the server was exposed. It comes as a one-page summary plus the full evidence report, signed by the Approver of Record. Where we find no indicators, the report says “No evidence of compromise found in the checks listed” and lists the checks and their limits. It’s not legal advice, and it doesn’t promise any effect on coverage. Ask for it