Two critical remote code execution vulnerabilities in PHP, collectively called PHP2Shell, have exposed an estimated 22.6 million web servers worldwide to potential compromise.

This guide explains what clients need to do now, how hosting choices matter for security responsiveness, and what to prioritise for long-term resilience.

What happened

On 21 October 2026, the PHP Foundation released emergency security updates addressing two critical vulnerabilities:

CVE Name Severity
CVE-2026-109618 Upload-progress unserializer use-after-free 9.2 (Critical)
CVE-2026-109619 Fatal-error backtrace use-after-free 9.2 (Critical)

Both vulnerabilities allow unauthenticated attackers to run arbitrary code on affected servers. The flaws exist in PHP itself (not in WordPress, plugins, or themes) so updating these components alone doesn't provide any protection.

Affected versions

PHP Version Status Action Required
8.5 Patched (8.5.12+) Update immediately
8.4 Patched (8.4.27+) Update immediately
8.3 Patched (8.3.36+) Update immediately
8.2 Patched (8.2.35+) Update immediately; plan migration before Dec 2026
8.1 and earlier No official patch Upgrade server or take offline

What clients should do now

Step 1: identify your PHP version

Log into your hosting control panel or ask your developer to run:

php -v

If the version is 8.1 or lower, you are running end-of-life software with no vendor security fixes available.

Step 2: contact your hosting provider

Managed WordPress hosts (WP Engine, Kinsta, SiteGround, Cloudways, Flywheel):

  • Most applied patches automatically within hours of release
  • Ask for written confirmation that patching is complete
  • Verify your site health page shows the correct patched version

Shared hosting providers (GoDaddy, Bluehost, IONOS):

  • Many require manual updates via cPanel or Plesk
  • Some customers reported delays despite advance notice
  • Request confirmation of patching timeline in writing

VPS or dedicated servers (AWS Lightsail, DigitalOcean, Linode):

  • You are responsible for applying updates
  • Run: sudo apt-get update && sudo apt-get install php-fpm
  • Restart PHP-FPM services after installation

Step 3: verify the patch

Check the full version number, not just the major version. For example:

Version Status
8.4.27 or higher ✓ Patched
8.4.26 or lower ✗ Vulnerable
8.2.35 or higher ✓ Patched (but EOL December 2026)
Any 8.1.x ✗ No fix available

Step 4: temporary mitigations (if patching is not possible)

If your hosting provider cannot patch immediately:

  1. Restrict access to known IP addresses where possible
  2. Enable a WAF (Cloudflare, Sucuri, Wordfence cloud tier)
  3. Disable upload progress handlers if accessible via php.ini or .user.ini
  4. Take the site offline if it processes sensitive data and cannot be patched

Per NCSC guidance: organisations on PHP 8.1 or earlier should take systems offline until updated or patched.

Why your host matters

Not all hosting providers respond equally fast to critical vulnerabilities. Understanding your hosting model helps you set realistic expectations.

Hosting Type Who Patches Typical Speed Your Responsibility
Managed WordPress Host Hours to 1 day Verify completion
Shared Hosting Host 1–3 days Check status page
VPS / Cloud You Immediate action needed Manual patching
Dedicated You Immediate action needed Manual patching
Proprietary Platforms Host Variable Wait for notification

Questions to ask your host

  • Are we patched against CVE-2026-109618 and CVE-2026-109619?
  • What patched PHP version are we running?
  • When was the patch applied?
  • What happens if we are still on PHP 8.1 or earlier?
  • Will you provide written confirmation for compliance records?

Planning for future security issues

1. Choose proactive hosting providers

Some hosts demonstrated better preparedness during this incident:

  • Applied mitigations before public disclosure
  • Communicated proactively with customers
  • Provided detailed patching timelines

Consider hosts that publish security transparency reports and maintain public status pages.

2. Maintain PHP version awareness

PHP releases follow a predictable schedule, but many sites lag:

Version Active Support Until Security Support Until
8.5 Dec 2027 Dec 2029
8.4 Dec 2026 Dec 2028
8.3 Dec 2025 Dec 2027
8.2 Dec 2024 Dec 2026

PHP 8.2 reaches full end-of-life on 31 December 2026. Plan migration to 8.3 or 8.4 before then.

3. Build incident response into retainers

If you work with a developer or agency, ensure your contract specifies:

  • Maximum response time for critical security updates
  • Written confirmation requirements for patching
  • Escalation procedures when hosts delay

4. Use external monitoring

Don't rely solely on your host's word:

  • Regularly scan your site using external tools
  • Monitor security advisories from NCSC, CISA, and the PHP Foundation
  • Subscribe to WordPress security mailing lists for ecosystem-level alerts

Technical resources

For readers wanting deeper technical detail:

PHP security

PHP2Shell demonstrates why infrastructure-layer security cannot be outsourced entirely to hosting providers. Even managed services need verification, and self-managed servers demand proactive maintenance. If your site relies on PHP 8.1 or earlier, treat it as already compromised until you upgrade to a supported version.

For ongoing web development and security auditing services, I'm based in Belfast and work with clients across Northern Ireland, the UK and Ireland.

This article reflects information available as of 23 October 2026. Patching status and version availability may change rapidly.