PHP2Shell Critical RCE Flaws: Exploited Within Hours of Disclosure

Last updated: October 22, 2026. This story is still developing, and we’ll update this post as new details are confirmed. 

Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, are putting a large share of the web at risk. The vulnerabilities, collectively named PHP2Shell, both carry a CVSS score of 9.2, and both allow remote code execution (RCE). Security teams should treat these vulnerabilities urgently and respond accordingly. 

What Happened? 

Both flaws can allow an attacker to execute arbitrary code remotely on a server running a vulnerable version of PHP, with no physical access or prior foothold required. One is reached through out-of-memory handling; the other involves stale request-memory state. 

In practice, a vulnerable system is any server that: 

• Runs PHP. This covers web servers and application hosts that execute PHP code. Most PHP-based websites are believed to be affected, including those built on WordPress and other popular content management systems.
• Runs an unpatched PHP version. Which versions are affected is still being confirmed. Check the official PHP advisory for the current list. Until a fixed release is available for your version, treat it as exposed.
• Processes untrusted input. PHP applications that accept requests from the internet, such as public websites, web apps, APIs and customer portals, are the most likely targets. Internal-only systems are less exposed, but not immune. An attacker who gains a foothold in your network could reach them. 

Details of the flaws leaked before a patch was available and reportedly attacks began within hours. Regulators have taken notice, too. One EU agency warned that some affected sites might need to be taken offline until they can be secured.  

Mainstream outlets, including the BBC and Reuters, are covering the story, which speaks to the severity and breadth of the exposure. 

Why This One Is Different 

PHP2Shell underscores the fact that the gap between disclosure and exploitation is shrinking. Attackers allegedly had working exploits within hours. A monthly patch cycle can’t keep up with that kind of rapid pace, forcing organizations to assess and answer several questions under pressure, including: 

• Where does PHP run in our environment?
• Who owns each of those systems?
• Who controls the PHP version: us, or a hosting provider?
• Which exposures are most likely to be hit first? 

Organizations that already have those answers are best positioned to react fast. The rest will spend days just figuring out where to start. 

What Should We Do Now? 

Security teams can take several steps immediately to reduce the risks associated with these exposures: 

1. Inventory PHP exposure. Include third-party applications, CMS platforms, and hosted sites, not just code you maintain.
2. Confirm ownership and patch paths. For each asset, identify who is responsible. Managed hosts such as WP Engine have said they will apply the PHP 8.2.x patch automatically once it’s released, so no customer action is needed in those cases. Confirm this with your own providers.
3. Prioritize by exposure and exploit activity. Internet-facing systems with a known exploit path go first.
4. Patch or mitigate. Apply the fix as soon as it’s available for your version. Where you can’t patch right away, reduce exposure with compensating controls.
5. Track to closure. Verify that fixes landed and document the exceptions. 

How Nucleus Helps 

Nucleus is built for this kind of moment, allowing our customers to: 

• Discover what you have. Unify asset data so you can see where affected PHP versions run and who owns them.
• Prioritize what matters. Combine vulnerability severity with threat intelligence and business context, so the most exposed systems rise to the top.
• Automate remediation. Route fixes to the right owners and track them to completion, with workflows that can be set up ahead of events like this. 

Key Takeaways 

Both PHP vulnerabilities have exposed just how fast exploitation can move today, and it affects systems the whole internet and numerous organizations rely on.  

It’s worth mentioning, however, that while proofs of concept were posted quickly thanks to advanced AI models, many of them require specific configurations to actually turn into successful attacks. These configurations may not be realistic in a standard PHP-powered website, or they might get as far as exposing the vulnerability without causing harm by way of stealing data, causing disruptions, or creating a lasting footprint on the system. 

While it’s likely too early to accurately assess the impact of PHP2Shell, there’s no doubt that the next critical disclosure will likely move just as fast. Organizations that already know their assets, their owners, and their patch paths will be the ones most likely to limit or completely avoid damage as a result.