By now, most security pros are well-aware of the patches released Oct. 21 for PHP2Shell, the two PHP open-source coding bugs that were patched this morning following a disclosure before the originally scheduled patch on October 22.
According to OpenAI, researchers at Calif identified the critical flaws using GTP-5.6 Sol as part of OpenAI’s Patch the Planet initiative; Wiz also independently discovered and reported both vulnerabilities.
The two CVSS 9.2 flaws — CVE-2026-109618 and CVE-2026-109619 — were discovered of late and not more than 20 years ago as was reported incorrectly. What’s actually the case is that the underlying legacy code and the specific memory-handling flaws weaponized by PHP2Shell were dormant in the core PHP engine since July 2004, when PHP 5 was first released.
The Cybersecurity and Infrastructure Security Agency (CISA) advised all organizations running PHP-based websites to apply the patches released by PHP right away.
Given that nearly 70% of all websites run PHP-scripted applications, security pros agreed with CISA that this was a “patch now” moment. PHP code powers many important content management systems, such as WordPress, Drupal, and Joomla — it also runs over WooCommerce and Adobe Commerce.
Security pros expected more reports of exploits in the hours and days ahead, and point to the speed of attacks teams face in the AI era.
Roman Y. Sannikov, global research coordinator at iCounter, said PHP2Shell showed how quickly the window between disclosure and exploitation has closed. Sannikov said PHP planned an orderly release, but the CVE IDs were posted on Hacker News before the patches shipped, watchTowr said it has already reproduced one of the two flaws, and Cloudflare said it’s already seeing early attack attempts.
“Attackers don’t need a public proof of concept to start working,” said Sannikov. “They scan the internet for PHP servers now and build their target lists, so when technical details land, they are ready to exploit on Day 1.”
Sannikov said defenders should treat today’s patches as urgent and start with internet-facing systems, including the older PHP 4, 5, 7, 8.0, and 8.1 sites that tend to get forgotten. He pointed out that cursory research by Modat shows almost 80% of PHP sites use versions that are no longer supported, and thus will not have been patched.
“WAF rules and the workarounds circulating online can buy time, but none of them are verified, and PHP’s own developers say patching is the only real fix,” said Sannikov.
Andrew Obadiaru, vice president and CISO at Cobalt, said once an embargo breaks, the disclosure timeline stops belonging to defenders.
“Attackers don’t need a full technical write-up, they just need to know a flaw exists and roughly where to look, and the moment patches ship they’ll diff them to see exactly what changed,” said Obadiaru. “That means the real test today isn’t how quickly teams can apply an update, it’s whether they actually know every place PHP is running. In most environments that includes legacy applications, vendor appliances, internal tools nobody has touched in years, and older versions that may never receive a fix.”
Denis Calderone, chief technology officer at Suzu Labs, added that his team spent the morning hunting through client environments, and it’s about as bad as it gets for the web tier: these are pre-authentication remote code execution (RCE) flaws in the PHP interpreter itself, and the trigger fires before WordPress, Drupal, or any application code even runs.
Calderone said every mitigation layered at the application level is downstream of the bug. Think about the exposure math: PHP runs about 70% of websites with a known server-side language, and one internet scan this week counted 4.4 million exposed PHP services across 1.9 million hosts.
“About 79% of those are running versions PHP no longer supports, which means no official fix is coming for them, ever,” said Calderone. “Cloudflare was watching attack traffic, and watching attackers mutate their payloads to get around the emergency rules, hours before details went public.”
Itai Goldman, co-founder CTO of Miggo Security, who wrote a blog on this PHP2Shell case, pointed out that PHP has been a backbone of the internet for nearly three decades, powering everything from WordPress and Drupal to countless business applications. The challenge with PHP2Shell is that organizations may not even know how many systems in their environment depend on it: PHP often gets bundled into other software, appliances and services, creating exposure that team can easily overlook.
“This isn't as simple as telling everyone to drop everything and patch,” said Goldman. “For organizations running supported versions of PHP, updating immediately is essential. But older, end-of-life versions won't receive standard security updates from PHP, and upgrading them may require significant changes to the applications that depend on them. Those organizations need to work with their software distributors and hosting providers on available fixes, isolate exposed systems where necessary and put temporary protections in place while they work toward a permanent update.”
Alon Noy, co-founder and CEO of Astelia, added that roughly 2.2 million hosts advertise PHP, and about almost 900,000 of them run end-of-life versions that won’t get a fix.
“Patching alone won’t cover that,” said Noy. “What matters for each server is whether an attacker has a reachable network path to it.”
Here’s how Astelia recommends organizations respond today:
- Inventory every PHP installation, including web applications, internal servers, and containerized workloads.
- Determine which PHP services are reachable from the internet and focus remediation there.
- Restrict access to non-essential PHP servers until they’re patched.
- Apply the security updates now, starting with reachable services.
- Isolate legacy servers on PHP 8.1 or older, use a WAF as an interim measure, and plan an upgrade to a supported version.
- Rebuild and redeploy container images from the updated official PHP images.
