PHP2Shell: AI-assisted research finds critical PHP flaws dating back to 2012

PHP shipped emergency security releases on 21 October 2026 to fix two critical flaws in the language itself. Tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, they can let an attacker who has never logged in run code on a web server, read passwords and API keys from its memory, or crash it. PHP rates both 9.2 out of 10 on CVSS v4.0. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP’s advisory says updating is the only complete fix.

The bugs are old. Calif traced the earliest affected code path to PHP 5.4.0, released in March 2012, and Wiz says every PHP version from the last decade is hit by at least one of them. PHP’s reach is wide too: W3Techs finds it on 69.3% of the websites whose server-side language it can identify. That measures PHP’s reach; how many of those sites can be attacked today depends on their version, set-up and patches, and plenty are already patched by their host or shielded by a firewall.

Any website, shop or landing page running on PHP needs its PHP runtime updated, and that job sits with whoever hosts it. Updating WordPress, a plugin or a theme does nothing for this. The flaws also say something about AI: PHP’s developers had seen the first signs of the out-of-memory problem in 2024, but nobody had shown a practical way to exploit it until AI-assisted research did.

Two memory bugs in how PHP recovers from errors

Both flaws come from what PHP does when a request fails halfway through. If a request runs out of memory at exactly the wrong moment, PHP can leave half-built internal data that its clean-up of that same request then trusts (CVE-2026-109618). After a fatal error, PHP can also keep pointers to memory it has already freed, which a later request handled by the same worker then uses (CVE-2026-109619). An attacker who can trigger the failure on purpose, with a crafted upload request for example, can turn the corrupted memory into code execution, running as the web server’s worker account.

PHP rates the risk highest for Apache with mod_php, where an unauthenticated request can trigger the attack before any application code runs, with default settings. PHP-FPM, the setup behind most Nginx sites, is exposed too: remote code execution there was confirmed through application code paths such as session handling, rather than before any application code runs. PHP also lists php-cgi, FrankenPHP and LiteSpeed as at risk.

Which platforms does PHP2Shell affect?

Every application running on an affected PHP version inherits the flaws, because they sit in PHP itself, though how easily they can be exploited depends on the server set-up. Researchers proved the point by taking over eleven widely used platforms before login, on releases that were current when they tested.

The list is a sample. Wiz says even a “Hello World” script on a vulnerable PHP version can be enough, so other PHP software, such as PrestaShop, Moodle and bespoke company sites, carries the same exposure, though no attack on them has been published. Keeping WordPress or Magento up to date gives no protection here: Wiz attacked the latest WordPress, Drupal and Joomla images. Wiz also showed a separate attack that reads passwords, tokens and API keys straight out of server memory without taking the server over.

PHP also sits inside products that do not look like websites, such as appliances and hosted services. The NCSC points to an inventory of software with a PHP dependency, published by its Dutch counterpart, as a starting list for those.

A bug PHP spotted in 2024, made exploitable by AI in 2026

In 2024, during PHP’s first external security audit in years (carried out by Quarkslab through OSTIF and funded by Germany’s Sovereign Tech Agency), a PHP core developer spotted the out-of-memory problem behind CVE-2026-109618. Nobody found a concrete way to exploit it, every candidate fix brought its own trade-off, and the work stalled. The PHP Foundation’s own account calls the delay “a structural failure”, caused by the security team’s decision process and its lack of resources.

OpenAI was one of several reporters. Ryan Austin at the security firm Calif found the first route to remote code execution with OpenAI’s GPT-5.6 Sol, under OpenAI’s Patch the Planet programme, and reported it to PHP on 11 August. OpenAI’s own Codex Security team reported the same root cause that day. Wiz, now owned by Google, reported further attack routes on 24 August, which it says it found independently using Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas, and it gives Gemini 4 Argon particular credit.

AI removed the obstacle that had kept the bug theoretical. Wiz says one researcher working with frontier models finished in a week what would once have taken a top team months, because the models could adapt the exploit to each PHP version, configuration and memory layout through repeated testing. Calif adds a useful corrective: its find used no special harness and no models beyond those anyone can use. Austin knew PHP’s vulnerability history and steered the model towards an old class of bug that, he argues, models would not have gone looking for on their own. OpenAI calls the result “one of the most impactful security issues in recent memory”.

The embargo leaked a day early, and attack traffic followed

Coordinated disclosure held until 20 October. At about 15:00 UTC the two CVE numbers began circulating online, with a wrong release time and a wrong score of 10.0, and PHP pulled its release forward from 22 to 21 October. That evening Calif mistakenly published a video of its exploit working against several targets. Copies spread after it was deleted and, according to the PHP Foundation, sped up the race to build proof-of-concept code. At 07:41 UTC on 21 October, Chainguard published built images containing the fix more than six hours early, which the PHP Foundation says let any attacker study the fix before most users could get it.

Attack attempts started early. Amazon found one in data from its MadPot honeypots dated 17 October, four days before disclosure, though it says it is unclear whether such attempts would have worked against real systems. The PHP security team says it found no working exploit among the code circulating at release. Cloudflare says it saw attack traffic against its customers after the leak, with attackers changing their payloads to slip past its rules, and watchTowr reports exploitation attempts against its honeypot network. CISA, which said it had not observed exploitation when it published its alert, has told organisations to patch immediately. In the UK, the National Cyber Security Centre has issued an alert urging immediate action, and NHS England Digital has rated the flaws high severity in its own alert. Forbes reports that some European governments took their websites offline while they patched. In the Netherlands, the government took Overheid.nl, MijnOverheid and DigiD offline as a precaution, Finland’s state IT provider Valtori closed public government web services to outside traffic, and Wikimedia took Phabricator and other tools offline.

Exploitation has since been confirmed. CISA added both flaws to its Known Exploited Vulnerabilities catalogue on 26 October, and on 29 October Palo Alto Networks’ Unit 42 confirmed that PHP2Shell is being used against PAN-OS firewall management interfaces exposed to the internet. No compromise of an ordinary website has been confirmed, and on 28 October Wordfence said it knew of none on WordPress.

Can UK businesses tell if their sites are exposed?

Yes, once they know which PHP version each site runs. Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is affected unless the host has applied a backported fix, and Calif traces the problem back to PHP 5.4. Most marketing teams do not manage PHP themselves, so the question goes to whoever does: the hosting company, the agency or the in-house developers. On WordPress, the PHP version appears under Tools > Site Health > Info > Server, and WordPress.org has confirmed that no WordPress update is required or planned for these flaws. OpenAI has also published a version checker as a Codex skill. It reads only the version a server reports, so it cannot see backported fixes, and an “unknown” result does not mean a site is patched. Cloudflare says customers using its free or paid web application firewall have been protected by default since 03:02 UTC on 21 October, which buys time, though Cloudflare itself tells customers to patch as well.

Shared hosting needs one extra question. Picking a newer PHP branch in the control panel only helps once the host has installed the patched builds, so ask the host which build is running. Linux distributions received the fix in advance, and the volunteer-run remirepo repository, common on Red Hat-family servers, published patched builds the same day despite PHP’s warning that it might not. If you run your own server, install your distribution’s patched PHP packages and restart every PHP worker. For containers, rebuild them from a patched image, because running workers keep the old code until they restart.

Which hosts and security firms have added protection?

Many large hosts put interim protection in place on 21 October and started rolling out the fixed PHP the same day, though progress varied widely by the evening. GoDaddy, Hostinger, Cloudways, Kinsta and Pantheon finished their rollouts on 22 or 23 October. Firewall rules and switched-off PHP features reduce the risk, while only the patched PHP removes it, so a host that says “you are protected” should still confirm which build is running.

Firewall and network providers moved first. Cloudflare switched on default rules for free and paid WAF customers at 03:02 UTC on 21 October. Fastly published a virtual patch that customers of its Next-Gen WAF have to apply, and warned that blocking at the edge gives only partial protection. Wiz credits Akamai, AWS, Imperva, Microsoft and Vercel with preparing mitigations too. Google Cloud patches App Engine standard apps on PHP 8.2 or newer automatically, as do Cloud Run services and functions with automatic base image updates switched on. Other Cloud Run deployments, GKE and App Engine flexible must be rebuilt or redeployed, and Google will not patch PHP 8.1 or older runtimes.

Among managed WordPress hosts, Automattic says sites on WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr are already protected. SiteGround switched off the affected PHP features on all its servers before the fix shipped. GoDaddy had patched every PHP version on its Managed Hosting for WordPress by 19:30 UTC, while its standard Web Hosting was still on interim mitigations, waiting for vendor packages, and its VPS customers must update themselves. Cloudways applied the configuration changes PHP recommends, began a phased rollout of the official patches, and is using extended-support partners to cover outdated PHP versions. WP Engine is rolling out patched PHP behind its CDN and server protections, and its sister platform Flywheel says the deployment there is finished. Pantheon had patched every live site on PHP 8.2 to 8.5 by 19:49 UTC and is working through older versions, and Kinsta is rolling out patches for every version from PHP 7.4 to 8.5.

Shared hosts depend on control panel and operating system vendors, so many sit a step behind. cPanel has added patched packages to EasyApache 4, including backports for PHP 7.4, 8.0 and 8.1, and Plesk has released fixed PHP 8.2 to 8.5 for Linux. CloudLinux, which runs underneath many cPanel hosts, was still rolling out its builds that evening, and updated its Imunify360 firewall rules three times on 21 October to block the public exploit tool and further variants, including on LiteSpeed servers, though none yet blocks the out-of-memory route behind CVE-2026-109618. Namecheap, DreamHost, InMotion Hosting and the UK’s Unlimited Web Hosting all reported mitigations in place while patches roll out, and OVHcloud says PHP 7.4 to 8.5 was patched on all its web hosting clusters by 17:53 UTC. Some hosts went further: Austria’s Anexia and Germany’s Uberspace and Netcup took PHP services offline until they could patch.

Hostinger, where CybelAngel counts 142,401 internet-facing PHP hosts in Shodan data (second only to Amazon), posted a status notice at 17:44 UTC on 21 October saying its tests had found its platform not vulnerable and that it had added extra protection. Its fuller explanation that evening says it added firewall rules that block the exploits in circulation, switched off session upload progress on its LiteSpeed, cPanel and PHP Selector set-ups and is rolling out the fixed PHP, which installs automatically on every plan except VPS, though its status page still showed upgrades under way on some managed servers that evening. VPS customers must update PHP themselves. Other Hostinger customers can check in hPanel under Websites, Dashboard, PHP Info: a fixed build can keep its old version number, and Hostinger says a build date of 21 October 2026 or later means the fix is in.

What should UK marketing teams do next?

1. Name the owner of every PHP site. List the main site, the shop, microsites, campaign landing pages and any forgotten WordPress installs, with the host and the person or agency that maintains each.
2. Ask for the version number in writing. A reply of “patched” leaves room for doubt. Ask for 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a vendor package confirmed to cover both CVE-2026-109618 and CVE-2026-109619, since backported packages can keep their older version numbers; Hostinger and GoDaddy both say to check the PHP build date instead. On Windows, ask for PHP’s rebuilt packages of 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1 or 8.2.35-1), which also fix a separate flaw in the Brotli library. Whoever checks should look at the PHP serving the website, which can differ from the one a terminal reports, and restart PHP after updating, because running workers keep the old code until they restart.
3. Turn on firewall protection while you wait. Cloudflare covers free-plan sites automatically; on a Pro, Business or Enterprise plan, check that the Cloudflare Managed Ruleset is set to block. A WordPress security plugin cannot stand in for this, because the attack runs inside PHP and, on many servers, before WordPress loads.
4. Treat PHP’s interim settings as a stopgap. Where an update has to wait, PHP’s advisory lists separate changes for each flaw: switching off session upload progress blocks the confirmed session route for CVE-2026-109619, and on PHP 8.5 switching off fatal error backtraces closes the other confirmed route, while removing the memory limit and capping upload sizes narrow CVE-2026-109618. PHP’s follow-up advisory of 23 October makes one exception: keep session upload progress switched off even after updating, until PHP’s next regular bugfix release, because it closes a further, unlikely route (CVE-2026-115560). They belong in the server configuration, where WordPress cannot override them, followed by a restart of PHP, and PHP says plainly that they do not make an installation safe. If even those cannot go on quickly, the NCSC says to consider taking the system offline, and to check anything left running unpatched for signs of compromise and backdoors. If a site does go offline, pause the paid campaigns pointing at it and log the downtime, so reporting does not mistake the outage for a drop in campaign performance.
5. Serve a 503 while a site is down. On the day the fixes came out, Google Search Central reminded site owners to return a 503 status code during patch downtime, which it says keeps already indexed pages in Search. Avoid 404s and error pages sent with a 200 status. The 503 does not have to come from PHP, as Google’s John Mueller pointed out, so a CDN rule or a temporary holding server can send it while PHP is down. Keep the outage short: Google’s crawl-rate documentation advises serving 503s for no more than a day or two, because pages can drop out of the index after several days. Serving a 503 for robots.txt itself pauses all crawling of the site, so do that only on purpose.
6. Assume secrets on unpatched servers may have leaked. The memory flaw can expose passwords, tokens and API keys, and the flaws are now being exploited, so have any server that ran an affected version checked for signs of compromise as well as updated. Amazon advises investigating from at least 17 October, when it found the earliest attempt, so ask for the check to go back that far. Consider rotating the keys stored on it: payment gateway keys, CRM and email platform credentials, and ad platform API tokens. If there are signs of a break-in, have the server cleaned first, so new keys do not land on a compromised machine.
7. Retire old PHP. Sites on PHP 8.1 or earlier get no official release, and W3Techs counts about 27% of PHP sites on version 7 and nearly 8% on version 5. PHP has published source-only backports for 7.4, 8.0 and 8.1, and some Linux vendors ship packaged ones, but PHP 8.2 itself stops receiving security fixes on 31 December 2026. Budget the upgrade now. WordPress.org’s guide to updating PHP recommends 8.3 or higher.

What to watch next

Patch rates over the coming fortnight will show whether the warnings reached the long tail of small sites, where outdated PHP tends to linger longest. Cloudflare and watchTowr will be the early signal if scanning turns into mass compromise, which could surface as defaced WordPress sites, card skimmers on online shops and spam pages. OpenAI says PHP2Shell is one of several significant vulnerabilities it has already found and is working to fix, and expects similar findings to rise sharply in the coming months. It has published a draft framework for handling such disclosures and is asking the security community for feedback. The PHP security team, for its part, has published 15 CVEs since 1 July and worked through more than 100 reports that proved invalid, duplicated or impossible to reproduce. The PHP Foundation is asking the companies and governments that rely on PHP to fund more security engineers. Our Black October round-up puts PHP2Shell alongside the WordPress plugin breaches and attacks on AI tools disclosed the same week.

The real lesson from PHP2Shell

For years, difficulty did quiet work as a defence. A bug that needed weeks of expert effort to weaponise usually ranked below one any script could hit, and the PHP out-of-memory problem waited in that queue from 2024 until August. PHP2Shell shows that ordering breaks down once a model can help do those weeks of work in days, and OpenAI concedes that attackers can use the same capability. Wiz ranks it alongside Heartbleed in 2014 and Log4Shell in 2021 as a possible turning point for security. For businesses, updates to shared software like PHP now need chasing on the day an advisory lands. For help working out which of your sites are affected and who needs to act, talk to AIWIZ.