Php Patches Critical Php2shell Vulnerabilities As Hosts Across The Wordpress Ecosystem Race To Protect Customers

Hosting companies across the WordPress space have spent the past day rolling out emergency fixes after the PHP project patched two critical remote code execution vulnerabilities.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released at 14:00 UTC on Wednesday, a day earlier than planned, after information the vulnerabilities started leaking online. Tracked as CVE-2026-109618 and CVE-2026-109619 and known as “PHP2Shell,” both are rated 9.2 under CVSS v4.0. The PHP security team advised that every PHP installation serving web requests was at risk.

According to the PHP Foundation’s account of the release , the vulnerabilities — under the right conditions — let unauthenticated attackers execute code on servers running PHP.

Automattic Head of Security Rudy Faile explained the vulnerabilities in plain language on the company’s blog :

“When PHP handles a request, it sets aside memory to do the work and cleans up afterward. The researchers found that if a request makes PHP fail partway through, for example: by running out of memory while processing a form submission, that cleanup does not happen correctly. Memory gets released while PHP still holds a reference to it, and a later request can reach it. “An attacker who carefully shapes what ends up in that memory can steer PHP into running commands of their choosing. That is the ‘shell’ in PHP2Shell: control of the server.”

“When PHP handles a request, it sets aside memory to do the work and cleans up afterward. The researchers found that if a request makes PHP fail partway through, for example: by running out of memory while processing a form submission, that cleanup does not happen correctly. Memory gets released while PHP still holds a reference to it, and a later request can reach it.

“An attacker who carefully shapes what ends up in that memory can steer PHP into running commands of their choosing. That is the ‘shell’ in PHP2Shell: control of the server.”

WordPress Security Team rep John Blackbourn wrote on WordPress.org that no WordPress update was required or planned, and that site owners should check for updates from their hosts and update PHP as soon as possible.

“These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application,” Blackbourn wrote.

He added that anyone managing their own hosting on a version older than PHP 8.2, which no longer gets security updates, should consider taking their server offline while they prepared to upgrade.

As The Repository reported yesterday , 35.1% of WordPress sites run PHP versions the project no longer patches, though given the severity, the PHP security team has published minimal source backports for PHP 7.4, 8.0 and 8.1.

The largest hosts in the WordPress space followed a similar playbook, putting firewall and configuration mitigations in place first, then rolling out patched PHP versions across their fleets through the day.

According to Faile, sites on WordPress.com, WordPress VIP, WP Cloud and Pressable were already protected, and the company had worked closely with the PHP Security team ahead of the release.

In a post on the WordPress.com blog , Artistic Director and Product Lead Ian Stewart wrote that there was nothing customers needed to do. “On WordPress.com, security is our job to solve, not yours,” Stewart said.

SiteGround Web Hosting Services & Products Expert Aleksandar Kolev wrote that the company had rolled out server-level mitigations across all of its servers hours before the release. WP Engine put mitigations in place at the CDN layer via Cloudflare and Fastly shortly before the release, and finished deploying patches at 01:19 UTC on Thursday. Hostinger Public Relations Manager Gediminas Gasiulis wrote that the company had blocked circulating exploit attempts before rolling out patches, which was completed at 06:44 UTC Thursday.

Kinsta used Cloudflare rules to block attacks while it validated patches version by version, and had them rolling out for every PHP version by 23:25 UTC. 20i completed its rollout , including backported fixes for older PHP versions, by 20:01 UTC.

GoDaddy Technical Product Lead for Hosting Gary Robert wrote that GoDaddy’s Managed Hosting for WordPress was fully patched, while its Web Hosting and Windows Hosting servers were still relying on mitigations at its last update as it waited on patched packages from its vendor. Bluehost patched most of its servers and warned customers they might see limits on upload file sizes in the meantime.

Liquid Web and Rocket.net were still rolling out patches into Thursday UTC, with Liquid Web telling customers on self-managed cPanel servers that they could patch themselves in the meantime.

While hosts mostly kept customers informed via status pages and blog posts, not every customer felt in the loop. Shortly before PHP’s patched versions shipped, developer Jon Brown asked on X whether anyone had received a single notification from a major managed host. His post drew more than 18,000 views.

Security companies on alert

Attacks started before the patches were released, with Patchstack reporting on Wednesday that multiple active exploitation incidents had been confirmed. Sucuri’s Malware Research Team wrote that exploitation attempts were being seen in the wild, though attempts weren’t necessarily successful compromises.

Cloudflare deployed firewall rules for all customers, including those on free plans, which CTO Dane Knecht described on X as a “STOPGAP only.” CEO Matthew Prince posted on X that the company was now seeing “millions” of attempts to exploit the RCEs.

Patchstack CEO Oliver Sild wrote on that he had put the whole company into “emergency response mode,” spending the day researching the vulnerabilities, helping partners and tracking exploitation attempts. He wrote that the vulnerability couldn’t be easily mitigated, and that the only reliable fix was the official patch.

“Today, all my thoughts are with sysadmins and engineers who have scrambled to keep their data and customers secure. Today, downtime is a sign that you care, not the other way around,” Sild wrote.

Wordfence vulnerability researcher Alex Thomas wrote that the company’s Threat Intelligence team achieved code execution for one of the vulnerabilities in a specially configured lab, but the same test only crashed a standard PHP build. In WordPress 7.1.3 tests, the other vulnerability caused PHP failures or restarts in some setups rather than code execution. Attacks may need to be adapted to each server, he wrote, but “an unpatched server should not be considered safe.”

The vulnerabilities were reported to PHP’s security team in August, more than two months before Wednesday’s release, according to the Foundation. Calif researcher Ryan Austin discovered the first vulnerability as part of OpenAI’s Patch the Planet initiative, while Wiz Research independently found and reported both. Calif and Wiz each demonstrated attacks against WordPress that didn’t require logging in.

The PHP project brought the release forward a day after the CVE IDs leaked online on Tuesday. The Foundation said Calif then mistakenly published a video of its exploit, and that Chainguard released patched container images more than six hours before the coordinated release. Sarah Gooding has the full story for Socket .

The Foundation also acknowledged that a core developer first spotted signs of the underlying problem in 2024, but that work on a fix stalled for months, calling the delay “a structural failure.”

Speaking to The Repository before the release, Anne McCarthy, Automattic’s representative on the PHP Foundation board, said it was “a real shame to have to deal with a leak like this for something so severe.”

After the release, she thanked those who had worked on the response.

“An immense amount of work went into handling this for the open web and it behooves us to continue to work together to keep the open web safe. I’m deeply appreciative to every person who worked tirelessly to make this happen and everyone else who is helping with the reaction to the disclosure,” McCarthy said.

What site owners can do

Site owners can check which PHP version their site uses under Tools > Site Health > Info > Server. If your site isn’t running on a patched version of PHP, or you’re not sure, get in touch with your host. Anyone managing their own server needs to update PHP, restart it so every running process uses the new code, and rebuild any containers. With PHP 8.2 reaching end of life on December 31, PHP 8.3 or newer is the safer upgrade target.

Because attacks began before the patches shipped, Wordfence recommends keeping server and firewall logs from at least 48 hours before the release. Sucuri suggests checking for unfamiliar PHP files, unexpected scheduled tasks, unknown admin accounts and suspicious outbound connections, and WordPress.org has guidance for hacked sites .

Disclosure: 20i, Automattic-owned Pressable, Patchstack and WP Engine are sponsors of The Repository.