On 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and urged everyone to update immediately (1). Cyber security agencies in the UK, US, EU, Canada and elsewhere told organisations to patch straight away, and to consider taking websites offline if they couldn’t (2)(3)(4)(5).

What happened?

PHP is a programming language that runs on web servers. It builds the pages you see, talks to databases and handles things like contact forms and logins before anything reaches your browser (3). The two flaws, nicknamed “php2shell”, can allow unauthenticated remote code execution: an attacker on the internet, with no password, may be able to run their own commands on the server (1)(4).

How it works: the NCSC says an attacker could trigger an out-of-memory condition in PHP that corrupts memory, and under certain conditions that corruption could be used to run code (3).

Who is affected: the PHP developers say all PHP installations serving web requests are potentially affected, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed. They consider the risk highest for mod_php, where a demonstrated exploit triggers before any website code runs (1).

How serious: CERT-EU rates both flaws 9.2 out of 10 on the CVSS severity scale (1).

The fix: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get updates from the PHP project, so sites on those versions need upgrading to a supported version, or a backported fix from their vendor (2)(6).

Found by AI, then leaked early

The flaws were found by researchers at Calif and Wiz, working with AI tools through an OpenAI programme called Patch the Planet. They had gone unnoticed for more than a decade. The PHP Foundation planned to release the fix later in the month, but details leaked on social media on Tuesday 20 October, forcing an early announcement (2). Wiz estimated “roughly 70%” of the internet is affected, a figure the BBC said it couldn’t verify (2).

Attackers are already trying

watchTowr’s head of threat intelligence, Jake Knott, said it was already seeing in-the-wild exploitation attempts: “Whilst nobody has been successful to date, we don’t expect that will last long” (1). Cloudflare’s CTO said it was “seeing early attacks emerging” (2). CISA said that at the time it published, it hadn’t observed exploitation, but warned the flaws pose a risk if left unpatched (4).

Sites taken offline

Finland temporarily shut down the government’s public web services. In the Netherlands, the cyber security agency, the parliament’s lower house and a public health institute took their websites down, and The Register reported the Dutch data protection regulator did too (1)(2). Wikimedia took some systems offline as a precaution. Edinburgh council’s website and the sites of several BBC programmes also became inaccessible, although they hadn’t confirmed a link to PHP when the BBC reported it (2).

The NCSC’s advice is clear: “Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated” (2)(3).

Why this matters to a small business

You may never have heard of PHP, but there’s a good chance your website runs on it. Huntress points out that PHP “quietly powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn’t even advertise that it runs PHP under the hood” (1)(2). Most small business websites are WordPress sites on shared hosting, or were built by a web agency who looks after them.

Sophos’s Don Smith told the BBC the real challenge isn’t installing a patch, it’s finding every place PHP is running, because it “can sit beneath public websites, content management systems, hosting platforms and third-party products, sometimes without even being obvious to the organisation using it” (2).

The real question: who is responsible?

For most of our clients, the patch itself is someone else’s job. But whose? It depends how your website is set up, and many businesses have never written it down:

Shared or managed hosting: the host usually runs and updates PHP on its servers. Check its status page or support notices to confirm it has applied 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or its own backported fix).

A web agency or freelancer: they may look after WordPress and plugins but not the server underneath, or the reverse. Ask them which parts they cover.

Your own server or cloud machine: if you or your IT provider set up the server, you (or they) are responsible for updating PHP.

Other systems: PHP also turns up inside booking systems, online shops, control panels and some network appliances. The NCSC says to check with those suppliers too (3).

If the answer is “I’m not sure”, that’s the gap to close today. Security is a shared responsibility: your host, your web supplier, your IT provider and you each own a piece of it, and the pieces only fit if everyone knows which is theirs.

The compliance and GDPR angle

Your website probably handles personal data: contact form messages, customer accounts, newsletter sign-ups or online orders. Under UK GDPR that brings two duties into play.

Article 32, security of processing: you must have appropriate technical and organisational measures to protect personal data, including a process for regularly testing and evaluating them (7). Leaving a critical, publicly announced flaw unpatched on a site that holds customer data is hard to square with that duty.

Article 28, contracts with processors: if your host or web agency handles personal data on your behalf, there must be a written contract covering, among other things, their security measures and their duty to help you if there’s a breach (8)(9). That contract is also where “who patches what” should be clear.

Article 33, breach reporting: if your site is compromised and personal data is affected, you may need to report it to the ICO within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people (10). Agencies advise checking for signs of compromise, not just patching (3)(6).

How we handle this with MSL Care Complete

MSL Care Complete, our full managed support package, is built so these questions already have answers. It includes proactive monitoring, patching with Action1, Huntress managed EDR, documentation of your IT setup, a quarterly IT review and a written client agreement, agreed with each client, covering data protection terms, DPIAs (data protection impact assessments), GDPR policy and procedures. That documentation records your suppliers, including your website host and web agency, so when something like this breaks we know who to chase. It comes at a fixed monthly price, no surprises. MSL is registered with the ICO (ZC279345).

Your PHP checklist for today

  • Find out where your website is hosted and who updates the server and PHP.
  • Ask your host or web agency, in writing, whether PHP is patched to a fixed version.
  • If PHP is 8.1 or older, plan an upgrade to a supported version now.
  • Check other systems that might use PHP: shops, booking systems, control panels.
  • Ask your supplier to check for signs of compromise, not just to patch.
  • Confirm you have a written contract with data protection terms with each web supplier.

References

  1. The Register, “PHP devs publish critical bug fix as site owners warned: Pull ’em offline if you’re unpatched”, 21 Oct 2026
  2. BBC News, “Websites taken down worldwide as critical cyber-security update issued”, 21 Oct 2026
  3. National Cyber Security Centre, “Critical security issue affecting PHP”, 21 Oct 2026
  4. CISA, “Critical Vulnerabilities in PHP Require Immediate Patching”, 21 Oct 2026
  5. CERT-EU, Security Advisory 2026-018: “Critical Vulnerabilities in PHP”
  6. Canadian Centre for Cyber Security, AL26-026: Critical vulnerabilities impacting PHP
  7. UK GDPR, Article 32: Security of processing (legislation.gov.uk)
  8. UK GDPR, Article 28: Processor (legislation.gov.uk)
  9. Information Commissioner’s Office, “What needs to be included in the contract?”
  10. UK GDPR, Article 33: Notification of a personal data breach to the supervisory authority (legislation.gov.uk)

Need a hand applying any of this to your business? Get in touch — call +44 1472 564538 or email services@msl.org.uk.

← Back to Insights