AI found a decade-old hole in PHP: what PHP2Shell means for every UK website owner

What changed

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities that it says can allow unauthenticated remote code execution. They are tracked as CVE-2026-109618 and CVE-2026-109619 and are known collectively as PHP2Shell. Both are memory-safety bugs in how the PHP engine handles fatal errors, particularly out-of-memory conditions, during a web request. A request that fails in the right way can leave corrupted internal state behind, and a later request handled by the same worker can reuse it. The result is either disclosure of process memory, which can include passwords, session tokens and API keys from other visitors' requests, or full code execution on the server.

The important word is engine. The flaws are in PHP itself, so they apply regardless of what runs on top. Wiz Research demonstrated pre-authentication remote code execution against the latest container images of WordPress, Drupal and Joomla, and states that a plain "Hello World" page on an affected version can be vulnerable. Every PHP version released in the last decade is affected by at least one of the bugs, back to 5.4. The PHP project says the risk is highest for Apache with mod_php, where an unauthenticated request can trigger the attack before any application code runs, but PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are all in scope.

The discovery is the other half of the story. Wiz found the first flaw on 19 August using its Wiz Atlas research agent together with Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol, confirmed working exploits against Drupal and WordPress within two days, and reported to the PHP security team on 24 August. Calif, working with OpenAI's Patch the Planet programme, independently found the same flaws using GPT-5.6 Sol; Reuters puts that date at 1 August. The vulnerable code had been in PHP for more than a decade. What changed was not the bug but the cost of finding it and of turning it into a working exploit, which Wiz describes as a chain of steps at the edge of what human researchers could practically achieve.

Disclosure did not go cleanly. Amazon's threat intelligence team recorded an exploitation attempt against one of its honeypots on 17 October, four days before the embargo lifted, from an anonymised address; it does not know how the attacker obtained the details and is not certain the attempt would have worked against a real server. Proof-of-concept exploits appeared within hours of the patch, and Amazon now reports broad exploitation attempts in the wild. Government websites in the Netherlands, Finland, France and Denmark were taken offline as a precaution, as were parts of Wikipedia and the Internet Archive. The UK National Cyber Security Centre issued an alert the same day.

Why it matters for UK business

Most UK SME websites run on PHP whether or not anyone in the business knows it. WordPress alone powers roughly 40 per cent of the web, and Reuters cites W3Techs putting PHP at about 75 per cent of websites whose server language can be identified. Brochure sites, booking systems, membership portals, intranets and ecommerce stores on Magento or WooCommerce are all in scope, and so are appliances and SaaS products that bundle PHP internally. The exposure is concentrated exactly where resources are thinnest: small sites on shared hosting where the customer does not control the server and may not know which PHP version it runs. Censys data cited by Reuters shows about 1.5 million of 2.6 million scanned hosts reporting a PHP version for which no fix exists.

The NCSC's guidance is unusually direct. Identify every PHP installation, not just the old ones, and prioritise internet-facing systems. Update, and keep monitoring for further updates. If you cannot update, apply the PHP project's temporary mitigations. If you cannot do that quickly, take the system offline until you can. And if a system has sat exposed, check it for compromise and backdoors before upgrading, because patching over an existing intrusion does not remove it. Amazon's advice points the same way: start any investigation from 17 October, not from the disclosure date.

Two cautions on the mitigations. PHP lists them, including setting the memory limit to unlimited, lowering the maximum POST size and disabling session upload progress, but its own wording is that they reduce exposure to specific attack paths and do not make an installation safe. A web application firewall rule from your CDN or host buys time in the same limited way. Neither replaces the update. The second caution is version support: PHP 8.1 and older receive no updates from the project. The security team has published minimal source backports for 7.4, 8.0 and 8.1 given the severity, and some Linux distributions and long-term-support vendors have shipped their own, but a site on PHP 7 or 8.0 should treat this as the moment to move to a supported version rather than apply a one-off patch and carry on.

The wider lesson is about tempo. Frontier models found these bugs, and the same capability lets attackers turn a patch diff into a working exploit in hours. Amazon's assessment is that a seven-day or thirty-day patching SLA for critical internet-facing flaws assumes a delay that no longer exists. For a UK business that means two things. Patching critical web vulnerabilities is now measured in hours, which in practice means knowing in advance who patches what and having a host or agency that will confirm in writing. And the defensive use of the same tools is no longer optional for anyone shipping code: AI-assisted review that reads for memory handling, error paths and input validation is cheap compared with the alternative. Our guide to security vulnerabilities in AI-generated apps and our briefing on governing coding agents cover how to set that up.

What to do, and what not to do

Do:

• List every site, portal and internal tool your business runs, and for each one establish the PHP version and who is responsible for updating it. Include products you did not build: the NCSC links to a Dutch NCSC inventory of software with a PHP dependency.
• Ask every host, agency and managed service provider to confirm in writing the PHP version your sites are on now and the date it was updated to a fixed release. Do not accept "we have it in hand".
• Where you control the server, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution's backported package) and restart every PHP worker. OpenAI has published a version checker as a Codex skill for operators who need to find vulnerable installs quickly.
• If an update is genuinely impossible this week, apply PHP's temporary mitigations at server level, enable your CDN or firewall rules, and plan the offline window the NCSC recommends if neither can be done.
• Review logs from 17 October onwards for unusual multipart POST requests, repeated HTTP 500 responses, memory-limit errors, unexplained worker restarts and unfamiliar files, processes or administrator accounts. Treat anything you find as an incident.
• Rotate credentials that an exposed server could have held in memory: database passwords, API keys, payment and email service tokens.

Do not:

• Assume a managed WordPress plan is covered. Automattic's statement applies to WordPress.com hosted sites and Tumblr. Self-hosted WordPress depends on whoever runs the server.
• Treat the mitigations or a firewall rule as the fix. They narrow the attack surface; only the update closes it.
• Patch an exposed server and move on without checking whether someone got there first.
• Stay on PHP 8.1 or older on the strength of a one-off backport. Use this as the trigger to move to a supported version.

Where The AI Consultancy fits

We are not a hosting company or an incident responder, and for a suspected compromise the right call is an NCSC-assured provider. Where we help is on the two questions this episode raises for any business that depends on software it did not write: how to know what you are running and who owns keeping it current, and how to use the same AI capability defensively across the code you do own. Our AI App Production Clinic reviews AI-built applications before they carry real users and data, and our AI strategy service covers the governance side, including patching cadence and supplier assurance. We take no referral or reseller income from any vendor named here, as set out on our independence page.

Verified on 24 October 2026 against the PHP project's security release notes of 21 October 2026 and informational advisory of 23 October 2026, Wiz Research's PHP2Shell disclosure (21 October 2026), OpenAI's "Patch the Planet" coordination post (21 October 2026), the AWS Security Blog's MadPot analysis (21 October, updated 22 October 2026), the NCSC alert "Critical security issue affecting PHP" (21 October 2026) and Reuters reporting of 21 and 22 October 2026. This briefing is general information, not security advice for a specific system; confirm your exposure with your host or an assured incident response provider.