AI-Accelerated Vulnerability Discovery: What the "Patch Wave" Means for Technology Disputes

Introduction

On 21 October 2026, the PHP project released security updates for two critical remote code execution vulnerabilities in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619 and publicly referred to as “PHP2Shell”. Public reporting describes the research that identified them as AI-assisted. PHP underpins a wide range of web applications, including many that organisations use through suppliers rather than manage directly. At the time of writing, the position regarding exploitation is still developing.

The incident is one example within a broader discussion. In May 2026, the UK National Cyber Security Centre (NCSC) published a blog post advising organisations to prepare for a “vulnerability patch wave”, on the basis that AI, used by skilled individuals, is showing the ability to exploit long-standing technical debt in software at scale and at pace. In September 2026, the Financial Conduct Authority (FCA) published a multi-firm review of frontier AI and cyber resilience, which addressed how firms are preparing for an increase in vulnerability findings.

This article does not attempt to predict how that trend will develop. It considers the technical questions these developments may raise in disputes about security incidents, including some that are specific to the use of AI tools to find vulnerabilities.

What has changed, and what has not

The core activities of vulnerability management are not new. Organisations have long been expected to maintain an inventory of their systems, monitor vulnerability disclosures, assess their exposure, prioritise remediation and apply fixes. Established frameworks, including ISO/IEC 27001 and the NIST Cybersecurity Framework, address these activities, as does NCSC guidance.

What the recent publications describe is a potential change in the rate and volume at which serious vulnerabilities are identified, as AI tools are applied to tasks such as source code analysis. The FCA’s review also refers to the possibility that several lower-rated weaknesses may be combined into a viable route to compromise, which is relevant to prioritisation methods that rely primarily on individual severity scores.

It is important to distinguish what is established from what is forecast. That AI-assisted research has contributed to the discovery of specific vulnerabilities is a matter of public record in some cases. That this will produce a sustained increase in the serious vulnerabilities affecting a given organisation is a forecast, and the extent of any increase will depend on factors that are not yet known. In a dispute, the relevant position is what was known and reasonably expected at the time of the events in question, not what has become apparent since.

The vulnerability gap

One way to frame the technical issues is to consider the interval between a vulnerability becoming known and an organisation completing verified remediation. That interval can be broken down into three stages, each of which raises its own evidential questions.

Identifying exposure. The first stage is establishing whether, and where, the organisation is affected. This depends on the accuracy of asset inventories, the availability of software composition information (such as a software bill of materials), and the extent to which the organisation understands the software embedded in products or hosted by suppliers. A vulnerability in a widely used runtime or library may be present in systems that the organisation does not directly manage.

Deciding on and obtaining a fix. The second stage involves assessing the risk, deciding on a course of action, and obtaining a fix or mitigation. Where the affected software is supplied or managed by a third party, this may depend on the supplier confirming whether its product is affected and when a fix will be available. The organisation may need to decide whether to apply an interim mitigation, isolate a system, or accept the risk for a period.

Deploying and verifying remediation. The third stage involves testing and deploying the fix through the organisation’s change process, and verifying that it has been applied across all affected systems. A fix that has been approved but not deployed, or deployed to some systems but not others, leaves the exposure in place.

An organisation may perform well at one stage and less well at another. It may have effective vulnerability intelligence but an incomplete inventory, or a reliable inventory but a change process that cannot accommodate urgent deployments. In a dispute, the question is not usually whether the organisation was aware that vulnerabilities exist in general, but what it did, at each stage, in relation to the specific vulnerability in issue.

AI findings as evidence

The use of AI tools to find vulnerabilities, whether by attackers, researchers or organisations examining their own systems, may raise evidential questions that are less familiar.

Findings as a record of knowledge. A vulnerability scan or code review that identifies a weakness creates a record that the weakness was identified. If AI-assisted tools increase the volume of findings an organisation generates about its own systems, the size and handling of the resulting backlog may become relevant. A finding that was recorded, assessed and deferred with a documented rationale presents differently from one that was recorded and not reviewed. Such records may be disclosable, and may bear on whether representations about known vulnerabilities were accurate, or whether a weakness that was later exploited had been identified beforehand.

Whether the tools themselves were expected. The state of the art changes over time. As AI-assisted analysis becomes more widely available, a question may arise in some cases as to whether an organisation, or a supplier of software, could reasonably have been expected to use such tools to identify a weakness before it was exploited. The answer will depend on the availability, cost and maturity of the tools at the relevant time, the nature of the organisation or supplier, and the guidance then in force. The published guidance does not, at present, resolve this question.

Reliability of findings. AI-generated findings may include false positives, and repeating an analysis may not produce identical results. Where an AI-assisted finding is relied upon in a dispute, the expert may need to consider how the finding was produced, whether it has been independently verified, and what weight it can bear. The same considerations apply where an expert uses such tools in the course of their own analysis, in which case the methodology should be explained in a way that allows it to be tested.

How the gap may arise in disputes

Many of the dispute types in which these questions arise are familiar, and I have discussed several of them in earlier articles on ransomware disputes and data breach litigation. The vulnerability gap bears on each of them in a particular way.

Cyber insurance. Where a policy or proposal contains a commitment to apply critical patches within a stated period, the expert may be asked to establish when the vulnerability became known, when a fix was available, when the insured became aware that it was affected, and when remediation was completed. Each of these dates may be contested, and the stage at which any delay occurred may be relevant to whether the commitment was met.

Outsourced IT and managed services. Contracts may allocate responsibility for deploying patches without addressing the identification of exposure, software embedded in applications, or emergency changes. The expert may need to establish which party was responsible for each stage of the gap, both under the contract and in practice.

Data protection and regulation. Under Article 32 of the UK GDPR, measures must be appropriate to the risk, having regard to the state of the art among other factors. Published guidance from bodies such as the NCSC forms part of the context in which the state of the art may be assessed, although guidance is not, of itself, a legal standard. The FCA’s review sets out observations for firms rather than new rules.

Supplier obligations. Where a vulnerability exists in software supplied under contract, there may be questions about the supplier’s obligations to notify customers, to provide fixes within a particular period, and to confirm remediation. These questions may arise alongside, or instead of, claims against the organisation that suffered the incident.

Technical matters relevant to reasonableness

Whether an organisation’s response to a vulnerability was reasonable is a matter for the court. The expert’s role is to address the technical matters relevant to that assessment, which may include the following.

The position at the relevant time. The analysis must be made by reference to what was known, and what guidance and tools were reasonably available, at the time. Guidance in this area is developing, and a practice described as expected in later publications may not have been expected, or practicable, earlier. Care is needed to avoid assessing earlier conduct against later standards.

Speed and safety. Deploying a fix quickly is not without risk. Patches can introduce regressions, cause service outages, or interact unpredictably with other components, and change management processes exist in part to manage that risk. The expert may need to address what testing was appropriate, whether interim mitigations were available, how critical the affected service was, and whether the organisation could reverse a failed change. A rushed deployment that causes an outage may itself give rise to a dispute.

Prioritisation. Where an organisation faces a large number of findings, prioritisation decisions are unavoidable. The expert may be asked to address the method used to prioritise, and how the specific vulnerability was assessed against the information available at the time. This may include whether factors beyond a severity score were considered, such as exposure to the internet, evidence of exploitation, and the potential for weaknesses to be combined.

Policy compared with practice. A documented vulnerability management policy, regular scanning and external certification are relevant evidence of the arrangements an organisation had in place. How those arrangements operated in relation to the particular vulnerability is a separate factual question, which the expert may also need to examine. As with each of these matters, the assessment depends on the facts of the specific case.

The evidence an expert may examine

Each of the stages described above tends to generate records, and the availability of those records will affect what the expert is able to establish. Relevant evidence may include:

• asset inventories, configuration management databases and software composition records, including their state at the relevant time;
• vulnerability scan results and the dates on which particular findings were first recorded;
• the outputs of any AI-assisted analysis, together with information about how the tools were configured and how their findings were reviewed;
• internal alerts or tickets relating to the disclosure;
• correspondence with suppliers about whether their products were affected and when fixes would be available;
• risk assessments, exception records and decisions to defer remediation or apply interim mitigations;
• change requests, approvals, test records and deployment logs, including any use of emergency change processes; and
• post-deployment verification, such as rescans or configuration checks.

The completeness of these records varies considerably between organisations. Where records are incomplete, the expert must be transparent about the limitations of the analysis and the extent to which conclusions depend on assumptions.

Practical guidance for solicitors

Where an incident involves the exploitation of a known vulnerability, the timeline is likely to be central. Establishing early the dates on which the vulnerability was disclosed, a fix was released, the organisation was notified or became aware, and remediation was completed will help to identify the issues in dispute.

Records relevant to the vulnerability gap may be held across several systems, including ticketing platforms, scanning tools and supplier portals, some of which have limited retention periods. Where litigation is anticipated, these records should be preserved alongside the forensic evidence relating to the incident itself. Where AI-assisted tools were used, this may extend to their configuration and outputs, which may not be retained by default.

For those advising on contracts or insurance proposals, it may be worth considering whether existing patching commitments address the identification of exposure as well as the deployment of fixes, how they apply to software embedded in third-party products, and how emergency changes are to be handled. Whether particular commitments are achievable will depend on the organisation’s estate and operating model.