The PHP2Shell Vulnerabilities: Why Managed Hosting and Patch Speed Matter in the AI Era

On October 21, 2026, the PHP project released emergency patches for two critical remote code execution flaws, which let an attacker run their own code on any PHP server that handles web requests, without logging in. PHP runs roughly 70% of websites with a known server-side language, including most Drupal and WordPress sites. Researchers demonstrated the attack against the standard Drupal, WordPress and Joomla container images, and named the pair PHP2Shell.

If you're an ImageX client, your site was patched at the platform level and you didn't need to do anything. Our team checked PHP versions across every client environment once the fixed releases came out.

Even if your site is covered, how these bugs were found should shape how you think about hosting. They’ve been in PHP since version 5.4, which came out in 2012. In August 2026, several research teams found them independently with help from AI models, and it took only a few days to go from finding a bug to building an attack that worked. When attacks come together that quickly, how fast your host patches matters a lot more than it used to.

What Actually Happened

PHP2Shell covers two entries in the Common Vulnerabilities and Exposures (CVE) list, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 out of 10 on the Common Vulnerability Scoring System (CVSS 4.0), which puts them in the critical range. They are memory-safety bugs in how PHP's core engine handles fatal errors, particularly out-of-memory conditions. When PHP bails out of a request that way, it can leave a corrupted state behind that a later request or worker reuses. Four underlying bugs sit under those two identifiers, including a use-after-free in the upload-progress unserializer, an OPcache type confusion, and a remote memory disclosure that can leak passwords, tokens, API keys and certificates.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP project also issued source backports for 7.4, 8.0 and 8.1, which are past end of life, and most Linux distributions shipped patched packages the same day. Amazon's honeypot network recorded an exploitation attempt on October 17, four days before the vulnerabilities were public and while they were still under embargo.

Why CMS Updates Couldn't Fix It

Security updates for a Drupal or WordPress site usually happen inside the application. When a contributed module has a flaw, the Drupal security team publishes an advisory and site maintainers update the module. Everyone involved knows the process and who's responsible for it.

PHP2Shell sits a layer below the CMS, in the PHP runtime that Drupal and WordPress run on. No Drupal core patch, module update or plugin removal could fix it. A Drupal 11 site with every security advisory applied was as exposed as a neglected one, and on servers running Apache's mod_php, the attack can start before any application code runs. The only fix was installing the patched version of PHP on the server.

That puts the fix outside the reach of the content team or communications director who manages the website day to day. It belongs to whoever runs the servers. Whether they patched on October 21 or days later made the difference between a normal Wednesday and a weekend spent checking for incidents. 

How AI Shortened the Path to an Exploit

The bugs behind PHP2Shell are more than a decade old, and researchers turned them into a working attack in 2026 with help from frontier AI models. Wiz Research's write-up says the models helped chain several bugs into a single exploit and then adapt it to different PHP versions, configurations and memory layouts. Adapting an exploit to each target is the slow, repetitive part of building one, and it's the part the models sped up. Bugs that had sat in PHP since 2012 became a working attack within days.

Here's how the disclosure unfolded, based on accounts from Calif and Wiz Research:

• August 11, 2026: Calif, a security research firm working through OpenAI's Patch the Planet program, finds the first bug in this class
• August 19, 2026: Wiz Research independently finds a PHP2Shell vulnerability
• August 20, 2026: Wiz confirms unauthenticated remote code execution against Drupal
• August 21, 2026: Wiz confirms the same against WordPress
• August 24, 2026: Wiz reports its findings to the PHP security team
• September 21, 2026: PHP acknowledges the reports and begins a coordinated fix
• October 17, 2026: An exploitation attempt hits Amazon's honeypot network while the flaws are still embargoed
• October 20, 2026: Details begin leaking online
• October 21, 2026: PHP releases the patches and discloses the vulnerabilities publicly
• October 23, 2026: PHP publishes an additional security advisory, CVE-2026-115560, identifying a separate potential remote code execution vulnerability involving session handling

Wiz went from its first finding to a working attack on Drupal in one day, and on WordPress in two. Someone was trying the attack against live servers four days before the fix was public.

Building a working attack from a flaw like this has traditionally taken skilled researchers a long time, so an attacker had to want a specific target badly enough to put in the effort. As the August timeline shows, AI models shorten that process. The same tools help defenders, and they did here, because the researchers who used them reported the bugs to PHP so they could be fixed. Defenders still have to patch thousands of running servers, though, while an attacker only needs to find one that's behind.

What This Meant for Our Clients

No ImageX client had to take action on PHP2Shell, and no client site needed an emergency patch window.

That outcome came from where our clients chose to host their sites. We build on managed platforms such as Acquia and Pantheon, which patch PHP at the infrastructure level for every customer environment at once. When the fixed releases came out on October 21, the platforms were already rolling out patches before most site owners had read the advisory.

Our job was to verify the patches. We confirmed PHP versions across client environments, checked that development and staging environments were covered alongside production, and followed platform advisories as they were published. None of it required an emergency response.

A Drupal or WordPress site on unmanaged infrastructure, such as a virtual private server someone configured years ago or a self-managed server in an organization's own data centre, needed a person to notice the advisory, find every affected server and apply the patch. Many haven't yet. Censys counted about 1.57 million of 2.58 million exposed PHP hosts still unpatched in the days after the release.

What to Ask Your Hosting Partner

To find out how your organization would have fared, ask whoever runs your servers these questions:

• Who patches PHP, the web server and the operating system, and how fast? These sit below the CMS, so your Drupal or WordPress maintainer may not cover them. Ask for a specific time frame, such as "within 24 hours of a critical release."
• Which PHP version is each environment running? Include campaign microsites and staging servers nobody logs into anymore. If your provider can't produce this list quickly, they'll have trouble finding every server that needs a patch.
• Are you on a supported PHP version? PHP 7.4, 8.0 and 8.1 got minimal source-code patches this time, which someone still had to build and install. PHP 7.3 and older got nothing, and about 8% of PHP sites still run PHP 5. PHP 8.2 reaches end of life on December 31, 2026, so sites on it should plan an upgrade now.
• Who reads the security advisories? Someone should be responsible for watching php.net, drupal.org/security and your hosting platform's status page, so they hear about a critical disclosure within hours.
• Are you relying on a web application firewall instead of patching? Cloudflare and other firewall providers released rules to block the known PHP2Shell attacks around the time of disclosure, and those rules bought time to patch. A firewall only blocks the attack patterns it's been told about, so the PHP update still has to happen.

If your provider gives clear, specific answers to all five questions, the next critical PHP release should be a routine update for your site. If any answer is vague, start there, because PHP has already announced another vulnerability that will need patching.

What to Expect Next

Wiz Research says the October 21 patch fixes the root cause, but it also says untracked variants likely exist. PHP has already announced another vulnerability, CVE-2026-115560, and will publish its full advisory with the next release. If AI-assisted research can find decade-old bugs in PHP, it can find them in other widely used software too. We expect more vulnerabilities like this, found faster and exploited sooner after disclosure.

Keeping your CMS secure through module and core updates still matters. PHP2Shell shows that a site's security also depends on how quickly every layer underneath it can be patched, and on whether that patching happens automatically or waits for someone to notice an advisory.

If you're not sure how your organization would handle the next one, we're happy to help. A short conversation about your hosting, PHP versions and environments will show where your site stands.