PHP2Shell: get your PHP servers patched before attackers find them
CVE-2026-109618 and CVE-2026-109619 let attackers run code on unpatched PHP web servers without logging in. We find every affected PHP runtime, patch it, verify it and check for signs of compromise — at a fixed price per server.
- CVSS v4 severity, both CVEs
- 9.2
- CVSS v4 severity, both CVEs
- Unauthenticated remote code execution
- No login
- Unauthenticated remote code execution
- PHP-FPM, mod_php, CGI, LiteSpeed, FrankenPHP
- All web SAPIs
- PHP-FPM, mod_php, CGI, LiteSpeed, FrankenPHP
- Fixed PHP releases published
- 21 Oct 2026
- Fixed PHP releases published
Are You Affected?
If it serves PHP over the web, check it today
The flaws are in PHP's own request handling, so secure application code doesn't protect you. WordPress, Magento, Drupal, Laravel and custom PHP apps are all in scope if the PHP runtime underneath them is unpatched.
Linux distributions sometimes backport the fix without changing the version number, so an older-looking version can still be safe — check your vendor's advisory for the CVE IDs. Older branches are the real problem: there is no official fix for PHP 8.1 and earlier.
# Which PHP does the web server actually run? (CLI and FPM can differ)
php -v
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm*
# Every PHP binary on the box, including alternate versions
ls /usr/bin/php* /opt/remi/*/root/usr/bin/php 2>/dev/null
# PHP inside containers
docker ps --format '{{.Names}}' | xargs -r -I{} docker exec {} php -v 2>/dev/null| PHP branch | Status | What to do |
|---|---|---|
| PHP 8.5 | Fixed in 8.5.12 | Update to 8.5.12 or later |
| PHP 8.4 | Fixed in 8.4.27 | Update to 8.4.27 or later |
| PHP 8.3 | Fixed in 8.3.36 | Update to 8.3.36 or later |
| PHP 8.2 | Fixed in 8.2.35 | Update to 8.2.35 or later (8.2 support ends 31 Dec 2026) |
| PHP 7.4, 8.0, 8.1 | No official release | Vendor-patched build, or upgrade to a supported branch |
| PHP 7.3 and older | Affected, no fix | Upgrade, or isolate from the internet until you can |
Source: PHP security advisory, 21 October 2026. Temporary mitigations reduce exposure but PHP states that updating is the only complete fix.
The Fix
PHP2Shell Emergency Fix
Patch CVE-2026-109618 and CVE-2026-109619 on your servers, verified, with a check for signs of compromise.
- Inventory of every PHP runtime on the server (FPM, Apache, CLI, containers)
- Update to a fixed PHP release or vendor-patched build
- Restart and verify every PHP worker is on the fixed build
- Check logs and processes for known exploitation indicators
- Short written report you can file for Cyber Essentials or your insurer
For UK Organisations
The Cyber Essentials 14-day clock is running
Cyber Essentials requires critical and high-risk security updates to be installed within 14 days of release. For PHP2Shell, the fixed PHP releases were published on 21 October 2026.
The NCSC urged organisations to update immediately, and several UK public-sector websites were reported offline in the days after the alert.
FAQ
PHP2Shell questions, answered
What is PHP2Shell?+
PHP2Shell is the name given to two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 (CVSS v4). An attacker who can send an HTTP request to a vulnerable PHP web server may be able to run code on it without logging in. PHP released fixed versions on 21 October 2026.
Is my website affected?+
If your site runs on PHP — including WordPress, Magento, Drupal, Laravel and most custom PHP apps — and the server's PHP is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12, assume yes, unless your hosting provider or Linux vendor has shipped a patched build. Your application code being secure doesn't help; the flaw is in PHP's request handling.
We're on PHP 7.4, 8.0 or 8.1. What now?+
There is no official PHP release for those branches. Some Linux distributions and extended-support vendors have shipped patched builds; otherwise the fix is an upgrade to a supported branch, which may need application changes. We handle both, and can apply temporary mitigations while the upgrade is planned.
Are the published workarounds enough?+
No. PHP's own advisory says there are no complete mitigations and updating is the only safe choice. Settings such as session.upload_progress.enabled=0 reduce exposure to known attack paths while you schedule the update.
We're on managed or shared hosting.+
Your host is responsible for the PHP runtime, but check: ask them which PHP build your site runs and whether it includes the fix. Hosting control panels often run their own PHP engine, which needs updating too.
How do you access our servers?+
We start with read-only access (SSH, AWS Systems Manager or a temporary account you create) to inventory every PHP runtime. Changes are applied only after you approve them, and we hand access back when we're done.
Can you tell whether we've already been compromised?+
We check web and PHP logs, running processes and recently changed files for the indicators published by security researchers, and tell you what we find. If there are signs of compromise, we'll recommend containment and a clean rebuild rather than patching in place.
Does this affect our Cyber Essentials certification?+
Cyber Essentials requires critical and high-risk updates to be installed within 14 days of release. For an organisation running affected PHP, that window runs from the fix release on 21 October 2026.
Want the full technical detail? Read our PHP2Shell patching guide and options for end-of-life PHP.
Let's Talk
Ready to build something that lasts?
Whether it's a charging network, an AI rollout, or a core enterprise system — let's talk about what you're building.