PHP2Shell: A Patch Plan for Cyber Essentials and UK GDPR

What happened

The PHP security team gave advance notice on Tuesday 20 October and released the fixes the next afternoon, a little before the scheduled 3pm BST. By then the CVE IDs had leaked, and Cloudflare had already reported early attacks against PHP sites that morning. php.net · Sansec timeline

This guide is about the deadlines and obligations around the patch. For how the two bugs work, which server setups are most at risk, and update commands for Ubuntu, Forge, cPanel and Plesk, see our technical PHP2Shell guide.

What the NCSC is asking

The NCSC's alert, “Critical security issue affecting PHP”, boils down to five steps: NCSC alert

1. Find every PHP installation, starting with internet-facing systems. Don't only look for old versions; all of them may be affected.
2. Include suppliers and appliances that bundle PHP, and apply their updates as they arrive.
3. Update, then harden using the PHP team's guidance. If you can't update yet, apply the temporary mitigations.
4. Take the system offline if you can neither update nor mitigate in time.
5. Check for compromise and backdoors before patching a system that's been exposed. If you're unsure, bring in an NCSC-assured Cyber Incident Response provider.

The alert also recommends the NCSC's free Early Warning service, which flags threat activity it sees on your network. It's worth signing up if you haven't.

Who patches what

If your site runs PHP and nobody has installed the fixed package and restarted PHP, it's exposed. Who should be doing that depends on your hosting:

That's what we hit on a client's Forge server on release day. The newest build the PPA offered was still short of 8.3.36, so we added the mitigation as a conf.d drop-in, restarted PHP-FPM and checked every site. It's a stop-gap until the fixed package lands:

# Interim mitigation for PHP-FPM 8.3 (repeat per installed version / SAPI)
echo 'session.upload_progress.enabled = 0' | sudo tee /etc/php/8.3/fpm/conf.d/99-php2shell.ini
sudo systemctl restart php8.3-fpm
php-fpm8.3 -i | grep session.upload_progress.enabled   # expect: Off

# Evidence worth keeping: the version that serves traffic, and when it changed
php-fpm8.3 -v
grep ' upgrade php8.3' /var/log/dpkg.log | tail -5

Cyber Essentials: 14 days

Since April 2026, two security-update questions in the “Danzell” question set are automatic fails: A6.4 for operating systems and firmware, and A6.5 for applications. Both require high-risk or critical updates to be installed within 14 days of release. IASME: changes to Cyber Essentials for April 2026

PHP rates both flaws critical (CVSS v4.0 9.2), so for in-scope servers the window closes on Wednesday 4 November 2026. Two things to watch:

• When the fix reached you. If your PHP comes from a distro or PPA that published later than PHP itself, note the date the fixed package became available. That's your answer if an assessor asks why you patched on day nine.
• Who's responsible. On a VPS, patching PHP is your job. On shared or managed hosting it's the provider's, but you should still have their written confirmation.

Our evidence checklist

We don't close an emergency patch for a client until five things are true and written down:

For the compromise check, look for multipart requests followed by memory-limit errors, bursts of HTTP 500s, unusually large PHPSESSID cookies and unexplained PHP worker restarts. This is our working checklist, not an official IASME or NCSC tool.

If you were compromised: UK GDPR and the ICO

Code execution on a web server usually means the attacker could read the database credentials in the application's config, and on a shop, booking or membership site that means customer data. If you find evidence of compromise:

1. Assess the risk to people. If a personal data breach is likely to pose a risk to individuals' rights and freedoms, report it to the ICO as soon as possible and, where feasible, within 72 hours of becoming aware. ICO: report a personal data breach
2. Tell the people affected without undue delay if the risk to them is high.
3. Record the decision either way. You're expected to document breaches, including the ones you decide not to report.
4. Rotate every secret the server held, such as database passwords, API keys and payment-provider keys, and treat the server as untrusted until it's rebuilt or cleaned.

Fines can reach £17.5 million or 4% of global turnover, but for most small businesses the bigger cost is customer trust, and a late or missing report makes both worse. If you're a processor, such as an agency or host acting for a client, tell the controller without undue delay so they can make the 72-hour decision. Our guide to UK GDPR when your development team works abroad explains who's the controller and who's the processor.

If you run an agency

Most clients don't know which PHP version their website runs, and they shouldn't have to. They do need you to tell them, plainly, well inside the 14 days. Send each client a short note: whether their site was exposed, when it was patched, what interim measures were in place, and whether you saw anything suspicious. And if you're a client whose supplier has gone quiet, our guide to taking over a website from another agency covers getting control back safely.

Primary sources

• php.net: security advisory and the 8.5.12, 8.4.27, 8.3.36 and 8.2.35 releases
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• NCSC: critical security issue affecting PHP
• IASME: Cyber Essentials changes for April 2026
• ICO: personal data breach reporting
• Ubuntu USN-8948-1: fixed package versions

Technical and operational guidance, not legal advice. Confirm breach-reporting decisions with your data protection lead or a qualified adviser, and certification questions with your Cyber Essentials certification body.