On 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 — nicknamed “PHP2Shell” or “php2shell” — that can allow unauthenticated remote code execution on web servers running PHP (3)(4)(5). Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Our earlier post covered who should patch and why UK GDPR Articles 28 and 32 make that question a compliance issue as well as a technical one. This follow-up looks at what happened next in the UK, and what it means when a “web” flaw hits a high-street business.

What changed after the patch day

32 UK government services taken offline

Tech minister Baroness Lloyd of Effra told the House of Lords that 32 government services were unavailable and four were partially unavailable. She said this had “largely resulted from precautionary measures taken to protect systems while security updates and mitigations are applied” (1). Downing Street said some limited government services “may be offline” while security work was carried out, and a government spokesperson stressed that this did not mean the services had been hacked (1). No large UK public-facing critical services were reported as affected (1).

NCSC: “unprecedented” — and no confirmed successful breaches

Olly Whitehouse, chief technology officer of the National Cyber Security Centre (NCSC), called the event “unprecedented”. “It will be universally felt, I suspect,” he told BBC Radio 4’s World At One. He also said there were “no indications” of any successful breaches by hackers, and that the NCSC was “starting to see positive confirmation” that its advice was being acted on (1).

The NCSC’s published advice remains clear: identify systems running PHP (especially internet-facing ones), update to a fixed version, use temporary mitigations if you cannot update yet, and “consider taking the system offline until it can be fully mitigated” if neither is practical. It also says to assess systems for evidence of compromise before upgrading (3).

A garage in Chepstow that couldn’t issue MOT paperwork

The story is not only about Whitehall websites. Dean Presley, who runs a garage in Chepstow, South Wales, told the BBC he had been unable to properly process MOTs online. His computer system had been down since Wednesday morning — longer than the short outages he was used to. “MOTs can be conducted and they’re legal but none of the paperwork and certificates can be printed and they’re not on the system,” he said. Staff were forced onto paper documents, with delays for customers (1).

That is the small-business version of the same problem: when a system you depend on for day-to-day work goes offline — whether as a precaution, because a supplier is patching, or because something has gone wrong — the MOT still needs doing, the customer is still waiting, and “we’ll patch next week” is no answer.

Attackers were probing before the patch was public

Amazon Threat Intelligence reported that exploitation attempts against the PHP2Shell flaws began on Saturday 17 October 2026 — four days before patches were released on 21 October. AWS chief information security officer CJ Moses said the early attempt came from an anonymised IP while the vulnerability was still under embargo, and that later payloads suggested multiple actors. He said the flaws were “now being broadly exploited in the wild,” while adding it was unclear how many attacks were succeeding, and warned defenders “should not assume the public disclosure date is the earliest date of exploitation” (2).

Cloudflare’s Matthew Prince reported thousands of exploit attempts in the hours before public announcement, rising to millions afterwards (1). Dataminr’s TRACE team, cited alongside Amazon’s report, said observed activity after disclosure remained limited to scanning, fingerprinting and non-working exploits, with “no known compromises” at that point (2).

By 24 October, WIRED reported that the PHP Foundation said it had not seen any successful exploitation of PHP2Shell, and that many publicly circulating potential exploits appeared ineffective. Sites that had been taken offline as a precaution — including some large public and commercial services overseas — had returned (7). That is welcome context, not a reason to relax: the NCSC still treats unpatched internet-facing PHP as urgent (3).

Why this still matters if your site “seems fine”

PHP powers a large share of the web, including WordPress, Drupal, Joomla and many booking, shop and control-panel products (1)(4)(5). Most small business websites sit on shared hosting or with a web agency. The Chepstow example shows the risk is not only “will our brochure site get hacked?” — it is also “what happens if the online system we use for certificates, bookings or orders is taken offline while someone patches?”

Security is a shared responsibility. Your host usually patches server PHP; your web agency may patch WordPress and plugins; you own the business impact and the contracts. If nobody can say, in writing, who updates PHP and how you are told when a system must go offline, that gap is the story — not the CVE number.

The compliance and GDPR angle

Websites and MOT, booking or shop systems often process personal data. Under UK GDPR:

  • 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 (8). Leaving a critical, publicly announced flaw unpatched on an internet-facing system that holds customer data is hard to square with that duty. So is having no plan for precautionary downtime.
  • Article 28, contracts with processors: if your host, web agency or MOT/software supplier handles personal data on your behalf, there must be a written contract covering security measures and help if there is a breach (9)(10). That contract is also where “who patches what” and “how we communicate outages” should be clear.

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 PHP2Shell breaks we know who to chase — and what to do if a system has to go offline. It comes at a fixed monthly price, no surprises. MSL is registered with the ICO (ZC279345).

Your follow-up checklist

  • Confirm, in writing, that every internet-facing PHP system is on 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport.
  • Ask your host or web agency whether they checked for signs of compromise, not only applied the patch (3).
  • Name who decides if a site or linked system (shop, booking, MOT, control panel) must be taken offline — and how you are told.
  • Write down a short “pen and paper” fallback for any process that cannot stop when the online system is down.
  • Confirm you have a written data-protection contract with each web or software supplier (9)(10).
  • If PHP is 8.1 or older, schedule an upgrade to a supported version; those releases no longer get PHP project security fixes (3)(5).

References

  1. BBC News, “Race to update services' computer systems after cyber-security flaw found”, 22 Oct 2026
  2. BleepingComputer, “Amazon says PHP2Shell exploitation began 4 days before patches”, Sergiu Gatlan, 22 Oct 2026
  3. National Cyber Security Centre, “Critical security issue affecting PHP”, 21 Oct 2026
  4. The Register, “PHP devs publish critical bug fix as site owners warned: Pull 'em offline if you're unpatched”, 21 Oct 2026
  5. BBC News, “Websites taken down worldwide as critical cyber-security update issued”, 21 Oct 2026
  6. CISA, “Critical Vulnerabilities in PHP Require Immediate Patching”, 21 Oct 2026
  7. WIRED, “The PHP Meltdown Shows How AI Makes Bugs More Exploitable”, Lily Hay Newman and Matt Burgess, 24 Oct 2026
  8. UK GDPR, Article 32: Security of processing (legislation.gov.uk)
  9. UK GDPR, Article 28: Processor (legislation.gov.uk)
  10. Information Commissioner's Office, “What needs to be included in the contract?”

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