PHP2Shell: Legal and Regulatory implications for multinational businesses

On 21 October 2026, it was announced that there were two critical vulnerabilities in PHP, a script used to build approximately 70% of the websites available on the internet. Those vulnerabilities are CVE-2026-109618 and CVE-2026-109619 (together, PHP2Shell) and they enable a third party to gain access to a website’s code – effectively taking over the website and gaining access to the data that flows through or is collected by the website. Patches for the PHP2Shell have been released, but many websites remain unpatched.

Companies with websites built using PHP should patch their websites, but at this stage they may have bigger issues. There are already confirmed reports of the PHP2Shell leading to data compromises that will require companies to investigate the scope of the incident, and potentially notify impacted persons and regulators of a data breach. Companies should take the risk posed by PHP seriously, and work with IT teams and lawyers to ensure that risks posed by the PHP2Shell are addressed.

If your company has already suffered a data security incident as a result of the PHP2Shell exploit, it is critical to manage your response and perform any required notifications.

What happened

How the flaws were discovered
Between August and September 2026, three teams of security researchers independently found the PHP2Shell exploits with the help of artificial intelligence (AI) tools. On 20 October 2026, details of the exploits leaked online. PHP’s security team rated each flaw 9.2 out of 10 for severity.

The first attacks
Unfortunately, attackers were already using the PHP2Shell exploits before the security updates arrived. The first known attack occurred on 17 October, four days before the fixes were published.

Using the PHP2Shell exploit, attackers reportedly have also targeted building security systems and corporate firewalls. In one campaign, which researchers tentatively linked to China, attackers combined PHP2Shell with a separate vulnerability in Linux, the operating system that runs many servers and network devices, to take full control of 25 systems, including in a US government-affiliated network.

Researchers caution that a successful attack may not leave obvious errors in standard logs, and that attackers who only read the server’s memory may leave no trace at all. In other words, a clean log is not proof that nobody got in.

The most targeted regions: Europe, including the UK
Research indicates that approximately 10% of organisations worldwide have faced PHP2Shell attack attempts. In Europe and the UK, the figure rises to 14%, more than double the rate in North America.

Of the 18 most affected countries, 16 are European. Government bodies across Europe, banks in Japan, and hospitals in the Netherlands, among others, temporarily took their websites and online services offline as a precaution until the updates could be applied.

Legal and Regulatory implications

Security obligations
Whether under EU, UK, US, or other laws, companies generally have legal obligations to take reasonable precautions to secure their data. Where a critical vulnerability has been publicly disclosed, a fix is available and government agencies have issued warnings, regulators in all three jurisdictions are likely to view a delayed response as difficult to justify. Companies relying on PHP should ensure that they have patched their systems or risk regulatory scrutiny if the PHP2Shell is exploited on their network or website.

Incident reporting
Where a business system has been compromised, or personal data may have been accessed, reporting obligations may arise in several jurisdictions.

In the UK and the EU, reporting obligations may arise under data protection law, network and information security rules (the UK Network and Information Systems Regulations 2018 (NIS Regulations), and the EU’s Network and Information Security Directive (NIS2), which set cybersecurity duties for essential services and critical sectors), as well as under financial services rules (including the EU’s Digital Operational Resilience Act (DORA) which govern cyber resilience at financial firms, and the requirements of the UK’s Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA).

In the US, reporting obligations can arise under state breach notification laws, disclosure rules of the Securities and Exchange Commission (SEC), the US securities regulator, and sector regulators. Some deadlines run in hours from discovery rather than days from when notification populations are identified, and the event that starts each clock differs between regimes.

In addition to the general framework, many industries are subject to their own rules on both sides of the Atlantic, including financial services, healthcare and life sciences, energy, telecommunications, transport and aviation, and cloud and digital services. These rules can impose additional reporting obligations, shorter deadlines, and oversight by specialist regulators in each jurisdiction.

In short, companies that experience an incident must be mindful of these varying regimes, which is where McDermott Will & Schulte can assist.

Product security obligations in Europe
Companies that develop and sell software and connected products also have their own cybersecurity obligations.

In the UK, manufacturers of connected consumer products must already explain how security issues can be reported and how long their products will receive security updates.

In the EU, the requirements go further. Since 11 September 2026, the Cyber Resilience Act requires that manufacturers of software and connected products report vulnerabilities that are being actively exploited. An initial notification must be submitted within 24 hours.

Key questions for multinational companies

Given the pervasive use of PHP globally, if you have not already, you should be asking at least these questions:

1. Do we know where PHP is running across our own systems and those of our suppliers?
2. Have all supported systems been updated, and what is the plan for unsupported versions?
3. Would we be able to detect whether a system was compromised before it was patched?
4. Which reporting obligations could be triggered, in which jurisdictions, and who decides?
5. Do we sell any software or connected product containing PHP in the UK, the EU, or the US, and which product security rules apply?

How we can help

Our Global Data, Privacy & Cybersecurity team advises clients on cyber incidents across the UK, the EU, and the US, combining technical fluency with regulatory, litigation, and board-level experience. We provide a single, coordinated strategy rather than a collection of local opinions.

We can assist you in responding to PHP2Shell, including with regard to:

• Assessments of legal exposure to PHP2Shell, including through suppliers;
• Privileged incident response, working alongside trusted forensic experts;
• Coordinated notifications to regulators, customers, partners, and other stakeholders, including sector-specific requirements;
• Board briefings and governance support;
• Supplier engagement, contract enforcement, and loss recovery; and
• Regulatory investigations, litigation, and insurance disputes.

If PHP is used anywhere in your business or supply chain, please contact the authors or your regular McDermott lawyer.

This article reflects developments as of 4 November 2026. The position is evolving rapidly.