Cyber insurance

Does cyber insurance cover unpatched vulnerabilities?

Reviewed by the Apex broking team · Last reviewed 2026-10-22

Cyber insurance can cover attacks that exploit an unpatched vulnerability, but some policies have patching conditions or exclusions that can reduce or remove cover. PHP2Shell (October 2026) shows why your wording, your proposal answers and the Insurance Act 2015 all matter.

Part of: PHP2Shell and cyber insurance

In short

Often, yes, but it depends on the wording. Cyber policies are designed to respond to attacks, and most attacks exploit some weakness. Cover can be at risk from: security conditions or warranties that require you to patch within a set time; exclusions in some wordings for failing to maintain systems or fix known vulnerabilities; and inaccurate proposal form answers about patching. The Insurance Act 2015 softens some of this. Section 11 can stop an insurer relying on a breached term that could not have increased the risk of the actual loss, and section 10 suspends cover after a warranty breach rather than ending it.

Does cyber insurance cover PHP2Shell and other unpatched vulnerabilities?

Last updated 22 October 2026. An unpatched vulnerability does not automatically mean no cover. What decides it is your wording, what you told the insurer, and how quickly you acted once a fix existed.

PHP2Shell is the live example. On 21 October 2026 the PHP project released fixed versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35) for CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 and allowing unauthenticated remote code execution. The NCSC told UK organisations to prepare to update immediately, and the PHP advisory says updating is the only safe choice. As of 21 to 22 October 2026, several security firms reported exploitation attempts. See our PHP2Shell and cyber insurance guide.

Zero-day vs n-day: the gap between disclosure and patch

A zero-day is a flaw attackers can exploit before any fix exists. An n-day is a known flaw with a fix available that has not yet been applied. Patching conditions and exclusions are commonly triggered by a patch being available or a vulnerability being known, not by the flaw simply existing.

PHP2Shell moved through both stages in two days: an emergency release was pre-announced on 20 October 2026 after details leaked, and fixes followed on 21 October. From 21 October, any patch window in your policy is likely to be running. php.net says interim configuration changes "do not make an installation safe", so do not assume they satisfy a patching condition.

How cyber policies commonly deal with patching

There is no standard UK cyber wording. These patterns are common, but whether and how they appear depends on your policy.

Minimum security standards. Controls you must maintain, which may include updated and supported software, multi-factor authentication and backups.
Patch windows. Some wordings require critical updates within a set number of days of a patch becoming available, or within a "reasonable time".
Warranties and conditions precedent. The same requirement can be drafted as a warranty, a condition precedent or a plain condition, and the label changes what a breach does; see conditions precedent vs warranties.
Failure to maintain or known-vulnerability exclusions. Some wordings exclude losses from a failure to maintain systems, or from a known vulnerability left unfixed beyond a stated period. Others have none. See what cyber insurance does not cover.
Unsupported software. Some policies treat end-of-life software differently. PHP 8.1 and older get no official updates from the PHP project, though some Linux distributions ship backported fixes.

A useful benchmark is the Cyber Essentials requirements (v3.3, April 2026): high-risk and critical updates within 14 days of release, where high risk means CVSS v3 7 or above or a vendor rating of critical or high. Your policy may use a different window, or none. See Cyber Essentials and cyber insurance.

What does the cyber proposal form ask about patching?

Cyber proposal forms commonly ask how quickly you apply critical updates, whether you run unsupported software, and whether patching is automated or outsourced. Our cyber proposal form walkthrough covers typical questions.

Accuracy matters. Under section 3 of the Insurance Act 2015, a business must disclose every material circumstance it knows or ought to know, and material representations of fact must be substantially correct. Answering "critical patches within 7 days" when the reality is "when our developer gets round to it" is a misrepresentation risk.

Under section 8, the insurer has a remedy only if, but for the breach, it would not have offered cover or would have used different terms. Schedule 1 sets the remedies:

Deliberate or reckless: the insurer may avoid the policy, refuse all claims and keep the premium.
Otherwise, would not have insured at all: it may avoid the policy but must return the premium.
Would have used different terms (such as a stricter patching condition): the policy is treated as if it included them, if the insurer requires.
Would have charged more: claims are reduced proportionately.

See the duty of fair presentation and section 8 remedies, and answer patching questions at renewal with PHP2Shell in mind.

Can an insurer refuse a claim because you hadn't patched?

Not automatically. For business policies, the Insurance Act 2015 gives two key protections.

Section 11: terms not relevant to the actual loss. Section 11 covers terms that, if complied with, would tend to reduce the risk of loss of a particular kind, at a particular location or at a particular time. If you breached one, the insurer cannot rely on that to exclude, limit or discharge its liability if you show the non-compliance "could not have increased the risk of the loss which actually occurred". The explanatory notes say it can apply to conditions precedent and exclusions, not only warranties, but not to terms defining the risk as a whole. See section 11 explained.

Section 10: warranties suspend cover. Under section 10, a breach of warranty no longer ends the policy. The insurer has no liability for loss occurring, or attributable to something happening, between the breach and its remedy. The breach does not affect cover for losses before it, or after it is remedied, subject to the rest of the policy. See section 10 and breach of warranty.

Two illustrative scenarios (real outcomes depend on the wording and facts):

Relevant breach. A policy requires critical patches within a set period. The business misses it and attackers get in through PHP2Shell. The breach plausibly increased the risk of that exact loss, so section 11 is unlikely to help.
Irrelevant breach. The same business is late patching PHP, but its loss comes from a phished email account unconnected to the web server. It may be able to show the late patch could not have increased that risk, which is what section 11 is for.

One caution: section 16 lets business policies contract out of these protections if transparency requirements are met. See contracting out of the Insurance Act.

Managed or shared hosting: who is responsible for patching PHP?

On shared or managed hosting, the host usually controls the PHP build and applies updates, while the site owner often chooses the PHP version in the hosting control panel. If the host has patched but your site is set to an old version, you may still be exposed. Updating WordPress, Drupal, Joomla or Magento does not fix PHP2Shell, because the flaw is in PHP itself. See how to check your website PHP version.

For insurance purposes, ask:

What does your hosting or managed service contract say about who applies security updates, and how quickly?
Does your policy's patching condition extend to systems run for you by third parties? Cyber Essentials, for comparison, treats updates on infrastructure and platform services as shared, with the provider's commitment set out in the contract.
If the host's failure caused your loss, can you or your insurer recover from them? That depends on the contract's liability caps; our contract insurance clause check can review them.

If you are the agency or host, clients may claim against you: see PHP2Shell liability for web agencies and hosts.

What to check in your own cyber wording

What to look for	Where it usually sits	Why it matters for PHP2Shell
Security or minimum standards condition	Conditions or a security endorsement	May require supported software and timely updates
Patch window	Conditions, endorsement or proposal declaration	Tells you how long after 21 October 2026 you have
Warranty, condition precedent or plain condition	The clause itself and how it is labelled	Decides whether a breach suspends cover, defeats a claim or only affects part of it
Failure to maintain or known-vulnerability exclusion	Exclusions	Could apply to a loss through a known, unfixed flaw
Definition of your computer system	Definitions	Whether hosted or outsourced servers fall within your obligations and your cover
Notification condition	Claims conditions	How quickly you must report an incident or circumstance
Your proposal answers	Proposal form or statement of fact	What you said about patching and unsupported software
Insurance Act contracting-out terms	Often near the general conditions	Whether section 10 or 11 protections have been changed

Raise any gap before there is a claim.

How Apex can help

Apex is an independent UK insurance broker. We can:

check your current cyber policy's conditions on patching and security, notification and incident response;
for Apex clients, help you notify your insurer of an incident or circumstance quickly and correctly (if you think you have been attacked, see what to do in the first 72 hours);
arrange cyber cover if you have none, through our cyber proposal;
arrange technology PI and cyber for web agencies, developers, hosting providers and MSPs;
give you a free second opinion on your renewal.

We are not an IT security firm and do not patch or scan systems; your IT provider or host does that.

Sources

Frequently asked

Does cyber insurance cover PHP2Shell?

It can. Cyber policies are commonly designed to respond to attacks that exploit vulnerabilities such as PHP2Shell, subject to their terms. The risks to cover are an unmet patching condition or warranty, a failure-to-maintain or known-vulnerability exclusion in some wordings, and inaccurate proposal answers about patching. Fixed PHP versions were released on 21 October 2026, so any patch window in your policy is likely to be running.

Will my insurer refuse a claim if I hadn't patched?

Not automatically. It depends on whether your wording has a patching condition, warranty or exclusion, and whether the unpatched flaw was relevant to the loss. Under section 11 of the Insurance Act 2015, an insurer cannot rely on a breached risk-reducing term if you show the breach could not have increased the risk of the loss that actually happened.

Do I need to tell my insurer about PHP2Shell?

Not usually just because you run PHP, but check your policy. If you suspect your systems have been compromised, cyber policies commonly expect prompt notification of an incident or circumstance under their claims conditions. At renewal, your answers on patching must be accurate. Apex clients can call us for help deciding whether and how to notify.

Is my web host responsible for patching PHP?

Often, on shared or managed hosting, the host controls the PHP build and applies updates, but you may choose the PHP version in your control panel. Your hosting contract sets out who does what. Updating WordPress or plugins does not fix PHP2Shell, so check which PHP version your site actually runs.

What is the difference between a zero-day and an n-day vulnerability?

A zero-day is a flaw attackers can exploit before any fix exists. An n-day is a known flaw with a fix available that has not yet been applied. Patching conditions and exclusions in cyber policies are commonly triggered by a fix being available or a flaw being known, so unpatched n-days carry more insurance risk.

Get cyber cover in place, or check the policy you have

Start a cyber quote online in a few minutes, or ask a broker to check your current policy's patching and notification conditions. Or call 0117 325 0027.

Start a cyber quote Request a callback

Apex Insurance Brokers Limited is authorised and regulated by the Financial Conduct Authority. Registered in England and Wales, company number 07014570. This page is general information, not advice on your individual circumstances, and it does not guarantee that cover will be available or on what terms.