At 14:00 UTC on October 21st, PHP released patches to two critical CVEs, both of which can lead to remote code execution. CVE-2026-109618 addresses an RCE through an out-of-memory error, and CVE-2026-109619 addresses an RCE through a stale global state issue.  The flaws were discovered by researchers at Wiz and at Calif, the latter as part of OpenAI’s Patch The Planet project. Both were given a CVSS score of 9.2.  

On its own, this would be a significant incident that requires all hands on deck to find affected systems and apply, test, and deploy the patches. PHP is ubiquitous on the Internet, so much so that organizations may not fully understand everywhere it is deployed. There is an obvious parallel to the Log4Shell December 2021 vulnerability that ruined many holiday celebrations for security engineers and left a long tail to patch systems. What made the PHP2Shell incident really stand out was that it deviated from standard disclosure processes. The two flaws were leaked online on October 20th, forcing the PHP team to follow up with an announcement of an emergency patch.  The result: an ~18 hour period where security leaders lacked details on the flaws, searched for mitigations, and waited for attackers to develop and deploy exploits before patches were available. Some web application protection vendors rolled out updated protections overnight. 

When releasing PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, PHP’s guidance was severe: “There are no complete mitigations, updating is the only safe choice.” Those on older, unsupported versions (PHP 8.1 or earlier), will find themselves racing to implement incomplete mitigations while determining upgrade paths or temporarily shutting down some sites (as the Netherlands and Finland did for their government sites in advance of patch availability). If you are a security leader, you’ve likely already started to look at your environment’s PHP exposure. Here are the minimum eight steps you need to take: 

      1. Identify where you are vulnerable

        This is where having a software bill of materials (SBOM) is a critical tool in helping to identify where you are using PHP libraries and where you might be vulnerable.  Software composition analysis (SCA) such as Endor Labs and JFrog, are able to generate and analyze SBOMs to not only provide you an inventory but also identify vulnerable versions and remediation upgrade steps. Don’t forgot about your 3rd party supplied applications these include a range of commercially developed, open-source software, and SaaS applications. If you have been requesting SBOMs from your suppliers or generating them for open source software when not readily available, you will be able to use SBOM management solutions such as Sonatype SBOM Manager and Manifest software to see where you need to reach out to your suppliers. This is also a great reminder that being secure by demand puts you as the chooser in a better overall footing when new vulnerabilities are disclosed.  

      2. Add business context to your prioritization

        PHP2shell is not just a patching exercise but puts resilience programs to the test. Security teams must make decisions while information remains incomplete, exploits might emerge, and the full extent of exposure may still be unclear. That starts with knowing which critical business services depend on PHP, including dependencies hidden within third-party products and services.  Organizations then must decide whether they can keep those services running safely or whether taking them offline presents the lower business risk until they can patch. If that interrupts a critical business process, business continuity plans need to provide a workable alternative.

        Security cannot make these decisions alone. IT, business continuity and service owners must make these calls together balancing the risk of continued exposure against the business impact of disrupting a critical service. 

      3. Patch now where you can and hunt for a compromise

        Prioritize internet facing applications to be patched first. If you are hosting a content management system such as WordPress, it is not enough to just update WordPress and any plugins; you must ensure that the underlying PHP runtime is patched. Where you can’t patch, conduct a risk assessment that considers whether an application’s memory stores passwords, tokens, or API keys. The PHP team provides guidance where an upgrade to a fixed version is not feasible, while noting that this reduces the exposure for specific attacks but does not make the application or system safe for all potential attack paths. If none of these avenues are available, the last resort is to take the system offline.

        At the same time, hunt for signs of compromise. Attackers had a head start, so patching alone does not close the incident. Look for web shells, suspicious child processes spawned by PHP, unexpected file changes, and new admin accounts on any system that ran a vulnerable version. 

      4. Identity and mitigate unsupported PHP versions

        PHP is not releasing patches for PHP 8.1 or earlier, though they have added some backports for those customers building from source, and some Linux distributions and LTS vendors are offering backports. In a published blog, security vendor Mallory noted that 59% of internet facing hosts are a version that will not receive a patch. If your SBOM inventory indicates that any applications, containers or appliances are on an unsupported version, you will need to put together a mitigation plan, Depending on the deployed version,  this could be significant upgrade project. In the short term, services such as HeroDevs offer backporting the fix to older versions.  

      5. Consult with your web application protection and proactive security platform providers

        As of this writing, a handful of web application protection platform providers have posted public guidance for their customers and the market, highlighting updated rulesets and protections that would block CVE-2026-109618 and CVE-2026-109619 exploits. Other vendors may have provided updates or guidance directly to customers through alerts in the product, support organization communications, or posts in a customer community. If you haven’t heard from your provider yet, reach out to them now and understand what protections are automatically in place or if you must update any configurations. Treat WAF rules and protections as an additional mitigation and layer of protection, not as a replacement for patching.

        Meanwhile, many proactive security platform vendors, such as Tenable and Wiz, provide emergency response playbooks that have already identified areas of vulnerability so that you can kick off remediation workflows. You may need to update plugins from these vulnerability management vendors for additional discovery. 

      6. Test and control rollout

        The desire to patch systems immediately is understandable and no doubt management is pressuring for the “all clear” as soon as possible. But hasty deployments could lead to production instability. When patching systems in the cloud, try using green/blue deployments or use load balancers to send a portion of the traffic to the fixed systems to watch and monitor for any issues. For endpoint applications, utilize ring deployment roll outs to update a small group of systems first, check for problems, and then rollout to large groups.  

      7. Beware of misinformation

        Overnight on the 20th/21st, some proposed mitigations circulated on social media, including a setting change in a PHP configuration file. Later, the security firm that proposed the fix provided an update that the configuration change was insufficient. In a dynamic situation, particularly before a patch is available, it’s understandable that researchers would experiment with other mitigations. Be careful about taking these at face value, however, until they have been fully vetted and verified. PHP has since provided guidance on settings that can reduce exposure, but project owners were careful to warn users that these settings “do not make an installation safe.” 

      8. Don’t wait for the KEV. If there’s an exploitable attack path, close it.

        Researchers cited that the discovered vulnerabilities exist in versions of PHP up to a decade old and that they would not have been able to identify the vulnerabilities if it wasn’t for their ability to use the latest frontier models to help with discovery and analysis. This is another example of AI getting better at vulnerability discovery, but AI also accelerates the ability to write working exploits. Now that exploits for new vulnerabilities are trivial, waiting for proof of an active exploit becomes less important to factor into your prioritization strategyPHP2Shell vulnerabilities have not been registered in the CISA KEV, but CISA released an alert urging organizations to patch immediately. Other KEV sources and vendors report that they’ve seen exploitation and probing attempts, but it remains unclear if there have been any successful exploitations in the wild. Your days of waiting for CISA to publish a KEV before expediting a remediation are over.  

A vulnerability this large is a board level concern. Forrester has released the CISO Board Update: PHP2Shell to help you brief your board on this issue. If you have any additional questions, feel free to set up a guidance session with us. 

Share