Two critical flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, can let an attacker run commands on a web server without logging in. If anything you run on AWS uses PHP, including a WordPress site, a client portal or software from a supplier, update it to a fixed version and restart the PHP workers now. AWS says its own services are not affected, but the PHP you run on them is yours to patch.
What happened
PHP released fixes on 21 October 2026 after details leaked a day before the planned disclosure. Both flaws score 9.2 out of 10 (CVSS v4). The UK’s National Cyber Security Centre (NCSC) said organisations using any version of PHP are affected and urged them to find and update every PHP installation, starting with internet-facing systems. Insurance Business reported that sites belonging to the Metropolitan Police and several UK councils were unavailable that day.
Reports differ on exploitation. Rapid7 had seen attempts but not confirmed in-the-wild exploitation and expected it to follow; watchTowr said it had observed exploitation from 21 October. Treat it as under attack. (Verify the latest position, including whether CISA has added either CVE to its Known Exploited Vulnerabilities catalogue, before publishing.)
Are you affected?
| PHP version | Status | What to do |
|---|---|---|
| 8.5 before 8.5.12 | Vulnerable | Update to 8.5.12 |
| 8.4 before 8.4.27 | Vulnerable | Update to 8.4.27 |
| 8.3 before 8.3.36 | Vulnerable | Update to 8.3.36 |
| 8.2 before 8.2.35 | Vulnerable | Update to 8.2.35 |
| 8.1, 8.0 and 7.4 | No routine fix | Use a vendor or distribution patch, PHP’s limited source backports, or upgrade |
| 7.3 and older | No fix | Upgrade to a supported branch |
Versions are per Rapid7 and AWS’s bulletin. PHP often hides in places nobody lists: content management systems such as WordPress, Drupal, Joomla and Magento, software bundled by a supplier, and control panels such as cPanel and Plesk. Huntress reports researchers demonstrating the attack against WordPress, Drupal and Joomla.
What to do on AWS
AWS’s bulletin sets out what each service needs. The responsibility is split exactly as in the shared responsibility model: AWS patches what it runs, and you patch what you deploy.
| Where PHP runs | Action |
|---|---|
| EC2 on Amazon Linux | Update the PHP packages, then restart PHP workers. AWS says updated packages are available in commercial Regions. (Verify the package version for your Amazon Linux release in the Amazon Linux Security Center: one report suggested a delay on Amazon Linux 2023.) |
| Elastic Beanstalk | Patched PHP 8.2 to 8.5 platforms are released. Managed Platform Updates apply them in the next maintenance window; otherwise update the platform yourself |
| Lambda | There is no managed PHP runtime. If you use a custom runtime or container image, update PHP and redeploy |
| Containers (ECS, EKS) | Rebuild images on a fixed PHP version and redeploy (our advice, not in AWS’s bulletin) |
| Lightsail | AWS has updated its blueprints, but cannot patch running instances: create new ones and migrate |
| WorkMail | Patched by AWS; no action |
| AWS WAF | Keep the PHP managed rule group current. Default versions update automatically; pinned versions need a manual update. A stopgap, not a fix |
Updating is the only complete remediation. Rapid7 lists configuration changes that reduce exposure, such as disabling session upload progress, but says they do not fully address the flaws, and PHP states that no configuration change fully mitigates them.
A worked example
(Illustrative.) A small wealth manager runs a marketing site, a client portal and a supplier’s reporting tool on AWS. A one-hour inventory finds six PHP installs.
| Install | Found | Action | Time |
|---|---|---|---|
| Marketing site on Elastic Beanstalk | PHP 8.3, managed updates on | Confirm the patched platform applied | 15 minutes |
| WordPress on EC2 | PHP 8.2, one instance | Update package, restart | 30 minutes |
| Client portal on EC2, two instances | PHP 8.3 | Update package, restart, one at a time behind the load balancer | 1 hour |
| Staging server | PHP 8.2 | Update package, restart | 30 minutes |
| Reporting tool bundled by a supplier | PHP 8.1 | Ask the supplier for a fix; restrict access in the meantime | Days |
Five of six are fixed in an afternoon. The sixth is the real risk, and it only shows up because someone looked. Until the supplier responds, the firm limits who can reach it, as the NCSC suggests, and checks it for signs of compromise.
Your checklist for today
| Step | Action |
|---|---|
| 1 | List every PHP install, internet-facing first, including supplier software |
| 2 | Update to a fixed version, or apply the supplier’s patch |
| 3 | Restart every PHP worker so the fix takes effect |
| 4 | If you cannot update, restrict internet access, apply PHP’s temporary mitigations, and keep AWS WAF’s PHP rules current |
| 5 | If neither is possible quickly, the NCSC says to consider taking the system offline |
| 6 | Check unpatched systems for compromise: PHP processes starting shells, new files in the web root, new scheduled jobs or accounts |
| 7 | Record what you found and when you fixed it |
If you find signs of compromise, isolate the server, keep the logs, and call an NCSC-assured incident response provider.
Why this matters for regulated firms
For an FCA-regulated firm, a web server running unpatched PHP is a third-party and cyber risk it owns, whichever cloud it sits on. A dated record of inventory, patching and checks is the kind of evidence a board, an auditor or a client’s due diligence asks for. It also links to the themes in The FCA’s Frontier AI Warning: faster exploitation makes slow patching harder to defend.
Patching is prevention. Recovery is the backstop. If a web server is compromised, can you rebuild it from a known-good image and restore data from a clean backup within your impact tolerance? A Yemberzal Disaster Recovery Assessment answers that system by system and proves it with a drill.
