On 21 October 2026, PHP fixed PHP2Shell: two critical flaws that let attackers run code on a web server without logging in. Almost every PHP version back to 5.4 is affected, but official fixes only came for PHP 8.2 to 8.5. AI tools helped find the flaws and turn them into working attacks, and they're speeding up vulnerability discovery across the industry. If your application runs on unsupported PHP, here's what that means and what to do.
cves: CVE-2026-109618, CVE-2026-109619 severity: critical, CVSS 4.0 score 9.2 each impact: remote code execution, no login needed affected: nearly every PHP version back to 5.4 fixed_in: 8.5.12, 8.4.27, 8.3.36, 8.2.35 php_8.1_and_older: no official release
Two flaws in how PHP cleans up after memory errors. They let an attacker who can send requests to your site run their own code on the server, with no login needed. Both are rated critical: 9.2 out of 10.
Every PHP installation that serves web pages, whether through PHP-FPM, Apache mod_php, CGI, FrankenPHP or LiteSpeed. Security researchers report that nearly every version back to PHP 5.4 is vulnerable.
Researchers reported attempts to exploit both flaws within hours of disclosure. Amazon's threat intelligence team logged an attempt four days before the fix was even published.
OpenAI's Codex Security team helped find the flaws. The researchers say AI models let one person turn them into working exploits in about a week, work that would otherwise take a team months.
The PHP project released fixed versions for PHP 8.2, 8.3, 8.4 and 8.5, the only versions it still supports. For PHP 7.4, 8.0 and 8.1 it published source code patches, for people who build PHP themselves.
PHP 5.x and 7.0 to 7.3 got nothing. Workarounds exist, but the PHP project says they don't make an installation safe. On these versions, the flaw stays open unless you upgrade.
Not sure which version you run? Run php -v on the server, or look for the version in your hosting control panel. Linux distributions sometimes ship fixes under older-looking version numbers, so check your package's changelog for the CVE numbers too.
| PHP version | PHP project support | PHP2Shell fix |
|---|---|---|
| 5.4 to 5.6, 7.0 to 7.3 | Unsupported for years | None. Upgrade, or isolate the application |
| 7.4 and 8.0 | Unsupported | Source code patch only. No official release; ask your host or LTS vendor |
| 8.1 | Unsupported since 31 December 2025 | Source code patch only. No official release; ask your host or LTS vendor |
| 8.2 | Security fixes until 31 December 2026 | Fixed in 8.2.35, but this is likely one of its last fixes |
| 8.3 | Security fixes until 31 December 2027 | Fixed in 8.3.36 |
| 8.4 | Security fixes until 31 December 2028 | Fixed in 8.4.27 |
| 8.5 | Security fixes until 31 December 2029 | Fixed in 8.5.12 |
Google's Threat Intelligence Group published these figures on 30 September 2026, in a report on vulnerability trends in the AI era. It expects both discovery and exploitation to keep increasing in the short to medium term. It calls the risk from AI-discovered flaws an early sign rather than an established trend, but says that risk isn't just theoretical.
Supported software gets a fix shortly after a flaw is published. Unsupported software doesn't, so every new flaw found in old PHP, an old framework or an old Composer package stays open. As flaws are found faster, the list of open holes in an old application grows faster too.
Old code is also exactly what AI tools are good at reading at scale. The same tools that help defenders review code help attackers turn published fixes into exploits for anyone who hasn't applied them.
Google is clear that raw counts overstate the risk. Part of the rise comes from automated CVE assignment, and only about 1 in 431 vulnerabilities disclosed in 2026 was seen being exploited.
The question isn't whether every flaw will be used against you. It's whether you can patch the ones that are. On unsupported PHP, you often can't.
Most organisations need a mix: an immediate fix, cover for the months an upgrade takes, and the upgrade itself.
For every PHP site you run
On PHP 8.2 to 8.5, update to the fixed version. On older PHP, apply the workarounds PHP lists, such as turning off session upload progress and limiting request sizes, and restrict who can reach the application. These reduce the risk; they don't remove it.
While an upgrade is planned
Some Linux distributions and long-term support vendors keep patching PHP after the PHP project stops. Zend PHP LTS by Perforce covers PHP 7.2 to 8.1 but not PHP 5, 7.0 or 7.1. HeroDevs also offers NES for PHP, so check its documentation for the versions it covers. It's a bridge, not a fix for old code.
PHP 8.4 or 8.5, supported to 2028–2029
Move the code up to a supported PHP version, with its framework and libraries, in safe steps. Most legacy applications can be modernised in place, without a rewrite.
I've spent years on legacy PHP modernisation. The trick is never to change everything at once: each step is tested and released before the next one starts.
Code scanned for PHP version compatibility, Composer dependencies audited for known vulnerabilities and abandoned packages, and the hosting reviewed. You get a written risk report and an upgrade plan with costs.
Available patches and PHP's recommended workarounds applied, access restricted, and monitoring added, while the upgrade is planned.
Tests added around the parts of the application that matter most, so every later change can be checked against how it behaves today.
PHP raised one version at a time, with Rector doing the repetitive rewrites and PHPStan catching what it misses. Frameworks and libraries move up alongside.
The application moved to a supported operating system and PHP 8.4 or 8.5, often in containers, so future PHP updates become routine.
Released through staging with a rollback plan, then kept up to date on a maintenance plan, so it doesn't become legacy again.
Running fine and being secure aren't the same thing. PHP2Shell is in PHP itself, not in your code, and on PHP 8.1 or older there's no official fixed release. As AI tools speed up how flaws are found, more like it will follow, and unsupported versions won't get fixes for any of them.
Yes. The PHP project published a source code patch for 7.4 but no official release. Your host, Linux distribution or a commercial PHP support vendor may have shipped a patched build, so ask them and check the package changelog for CVE-2026-109618 and CVE-2026-109619. Otherwise, apply PHP's workarounds and plan the upgrade.
It helps, but it isn't a fix. During PHP2Shell, Cloudflare reported attackers changing their payloads to get around its firewall rules. A firewall buys time while you patch or upgrade; it doesn't replace either.
Usually not. Most legacy PHP applications can be upgraded in place, step by step, with tests and automated refactoring. A rewrite is only worth it when the assessment shows the code can't be saved for less.
It can. UK GDPR requires appropriate security for personal data, and running software with known, unfixed vulnerabilities makes that harder to show. If the application holds personal data, talk to your data protection lead. I can supply the technical assessment they need.
Tell me which PHP version and framework you run. I'll come back with the risk, the fastest way to contain it and a fixed price for the upgrade. The first conversation is free and comes with no obligation.
Checked on 30 October 2026. Figures are as published by each source.
This page is general information, not security advice for your specific system. If you think your server has been compromised, get incident response help straight away.