PHP2Shell: When the Patch Is Ready, but the Organization Isn’t
IDC ·
On October 21, two critical flaws in PHP left organizations with a choice that cybersecurity authorities stated plainly: update affected systems immediately or take them offline. Known together as PHP2Shell, the flaws (CVE-2026-109618 and CVE-2026-109619) can allow attackers to run code on affected servers without logging in. PHP runs websites and applications, including platforms such […] The post PHP2Shell: When the Patch Is Ready, but the Organization Isn’t appeared first on IDC .
On October 21, two critical flaws in PHP left organizations with a choice that cybersecurity authorities stated plainly: update affected systems immediately or take them offline. Known together as PHP2Shell, the flaws (CVE-2026-109618 and CVE-2026-109619) can allow attackers to run code on affected servers without logging in.
PHP runs websites and applications, including platforms such as WordPress and Drupal. But knowing that a company uses PHP is different from knowing every place it runs. A patch only helps once an organization knows where it is needed, who can apply it, and how to make the change safely. Those decisions are harder to make for the first time during an emergency.
IDC’s DevSecOps and Software Supply Chain Security Survey of U.S. enterprises illustrates the challenge. Asked to name their two hardest challenges if vulnerability discoveries rose sharply, respondents most often chose knowing where vulnerable software runs (30.7%) and deciding what to fix first (28.8%), ahead of fixing vulnerabilities quickly enough (23.6%). These findings suggest that faster remediation depends on work that begins well before a vulnerability is disclosed.
PHP can run inside vendor products, administrative tools, older internal systems, and websites managed by hosting providers. An application inventory may identify the website without recording the PHP version beneath it or who controls its updates.
Updating a website or its plugins is not enough unless the update also replaces the vulnerable PHP software. The fix may require action from an internal infrastructure team, a hosting provider, or a product vendor.
Log4Shell exposed the same gap in 2021, when Log4j turned up in applications whose owners did not know they contained it. The U.S. Cyber Safety Review Board found that the organizations that responded most effectively already knew where they used Log4j and had mature processes for managing assets.
No single inventory source should be assumed complete. Attack surface management and vulnerability management tools can help discover exposed services and identify affected software, while cloud security platforms can connect findings to deployed workloads and their exposure. Software bills of materials and provider confirmation can add component information. Organizations should verify that these capabilities also connect findings to accountable owners and business services.
An inventory must therefore answer more than “What applications do we have?” It must also show the software they depend on, its version, and the team or provider responsible for updating it.
The researchers who reported PHP2Shell used frontier AI models to uncover flaws in PHP’s core that had been there for more than a decade. Models can read large codebases, follow how memory and errors are handled across many files, and, once they find one flaw, search for others that follow the same pattern. PHP’s security team now receives far more reports than it did before.
AI can also help attackers with the slower step that follows: turning a flaw into an attack that works against a particular system. That step has historically required skill and repeated testing; AI models can now compare a patch with the code it replaced, draft an exploit, test it, and adjust it after each failure. PHP developers spotted one of the PHP2Shell flaws in 2024 but found no concrete way to exploit it; with AI models, the reporting researchers built attacks that worked against several widely used applications.
More disclosures and a shorter path to attack leave organizations less time to act on each advisory, and PHP2Shell showed how little time that can be. The earliest reported exploitation attempt came four days before disclosure, and PHP moved its release up a day after news of the flaws leaked.
Forthcoming IDC research will examine why AI is shortening disclosure embargoes and making them less reliable, and what buyers should ask of suppliers that receive embargoed fixes.
Finding an affected system does not mean an organization can immediately change it. Operations teams need confidence that an urgent update will not cause an outage, but testing, scheduling, and approval can introduce delays when multiple teams or providers are involved. In the same survey, 20.4% chose coordinating fixes across application, infrastructure, and open source teams as one of their two hardest challenges.
Organizations can reduce avoidable delays by agreeing on emergency change procedures in advance. Those procedures should specify which updates qualify for a preapproved process, what testing is required, how a failed change will be reversed, and who coordinates the response. Providers of maintained software packages and container images can help by supplying updated components when vulnerabilities are disclosed, while patch management and deployment tools can support the rollout and verification of patches. Both work best when the path from provider to production is set before an emergency.
When an update cannot be applied immediately, temporary protections such as restricting network access, changing vulnerable configurations, or blocking known attack patterns can reduce exposure, depending on the vulnerability and deployment.
For PHP2Shell, PHP’s maintainers state, “There are no complete mitigations, updating is the only safe choice.” Organizations need to verify what a control covers and take a system offline when the remaining risk is unacceptable.
That decision requires the same visibility and ownership needed for patching. Each temporary measure needs a named owner, a scheduled fix, and a review date.
Organizations responding to PHP2Shell should use the work to strengthen four practices:
No organization can control when the next critical flaw is disclosed. Each can control what the first hours look like: whether teams start patching systems they already know about, with owners and change procedures in place, or start searching for systems they did not know they had.
The post PHP2Shell: When the Patch Is Ready, but the Organization Isn’t appeared first on IDC .