PHP2Shell and the Limits of Patching: A SecOps Playbook for Layered Response

Last week’s disclosure of two critical remote code execution (RCE) vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) created an immediate and widespread fire drill among security response teams. Carrying a CVSS v4.0 score of 9.2 and affecting every PHP version released in the last decade (back to PHP 5.4), these flaws let an unauthenticated attacker execute shell commands directly on a vulnerable server. With PHP powering approximately 70% of websites whose server-side language is known, the blast radius is enormous.

In recent days, Zscaler ThreatLabz has monitored industry response, exploit attempts, and remediation trends in an effort to help customers swiftly reduce their exposure while protecting business operations. This post captures exploitation attempts observed in the wild and a summary of remediation status from around the security industry in the immediate aftermath of one of the most impactful vulnerability disclosures in years.

Three observations stand out:

Speed of exploitation. Attackers are working quickly, and they started before most security teams even knew about their exposure.

Prioritization must be automatic. You can't patch everything right away – you need to know which assets to focus on first, and you shouldn't need to hunt for them.

Compensating controls are essential. Not every critical exposure is patchable in a shortened timetable. Security teams need other options to mitigate risk quickly.

Exploitation Attempts Observed by Zscaler ThreatLabz

The speed at which attackers mobilized against PHP2Shell was notable but not surprising, given the role of AI in adversarial activity today. Within hours of the October 21 disclosure, scanning and exploitation attempts surged, with some activity predating the public announcement entirely.

The first 96 hours – by the numbers

Looking at global telemetry captured across Zscaler Deception's internet-facing decoys worldwide, we found a rapid escalation of PHP2Shell exploit activity in real time:

During the first 48 hours of disclosure, ThreatLabz focused on the micro-level payload analysis—analyzing 187 specific events across 23 high-priority IPs that delivered weaponized PHP object injections, memory corruptions, and web shells. By the 96-hour mark, this activity surged to a macro-level 3,038 scanning and exploit attempts from 248 unique IPs.

Key takeaway: Attackers moved before the formal publication of the disclosure. Organizations that rely solely on patch-on-release workflows were exposed before they could act.

Remediation Status

PHP released fixed versions on October 21: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. But patching at the scale PHP demands is a fundamentally different challenge than patching a single application.

Patching is happening, slowly

Industry telemetry reveals a remediation picture that is encouraging but far from complete.

Qualys analysis found that only 199,000 of approximately 156 million PHP installations were patched within the first 12 hours after disclosure, a fraction of 1%.

OX Security produced a similar analysis, showing 99.3% of PHP instances unpatched after 24 hours. Even five days after disclosure, nearly 94% of instances remained unpatched.

It should be noted that these statistics omit important qualifiers, including how many instances were on internet-exposed assets or crown-jewel assets.

Due to extensive news coverage, it’s safe to assume the industry has full awareness of the risk associated with these vulnerabilities. The early statistics indicate another challenge we already understand: organizations cannot patch their way out of widespread exposure.

The long tail of “unpatchable” PHP

To further complicate the remediation challenge, a significant number of PHP installations cannot be patched at all. About a third of PHP sites run PHP 7 or older, branches with no official PHP2Shell fix. Approximately 2.24 million internet-facing hosts advertise PHP, and 59% of those that report a version are running a PHP branch with no official security release.

PHP 8.2 itself loses security support on December 31, 2026. Patching 8.2 buys time, not permanent protection. 

Key takeaway: The reality of enterprise PHP estates means millions of installations will remain vulnerable for weeks or months if remediation is dependent solely on patching. Security teams need layered risk reduction strategies that go beyond patching.

Reduce Risk with Compensating Controls

Security teams must act on what they can control right now, layering practical compensating controls that meaningfully shrink the attack surface while patches roll out. Apply these measures in the following priority order.

Remove PHP applications from the internet

The most effective risk reduction is the simplest: if a PHP application does not need to be directly reachable from the internet, take it off or put a WAF in front of it. Every PHP2Shell exploit path begins with an attacker sending a crafted HTTP request to a PHP worker. Eliminating that inbound path eliminates the risk entirely – no signature tuning, no configuration changes, no residual exposure.

• Prioritize EOL systems. Unsupported PHP versions (8.1 and older) cannot be patched and must be isolated or retired immediately.
• Audit supported installations. Move internal tools and admin panels behind zero trust access to eliminate unnecessary internet exposure.
• Protect public applications. Ensure public-facing sites are patched or protected with compensating controls such as WAF.

Deactivate non-critical services with known exposure

Not every PHP application running in your environment is critical to the business. PHP2Shell is a compelling reason to finally answer the question many organizations have deferred: "Do we still need this running?"

• Identify decommission candidates. Retire unused admin interfaces, staging instances, and legacy tools, which often run unsupported PHP and lack active monitoring.
• Suspend what you cannot retire. Temporarily disable non-critical services as you implement a permanent fix to eliminate attack vectors.
• Track remaining services. Assign owners, document patch status, and set target remediation dates for active services. Track progress in your exposure management solution with dedicated PHP remediation dashboards.

Apply virtual patching for private applications

Many high-risk PHP applications are private, internal systems rather than public websites. Admin consoles, ERP front-ends, and wikis are often difficult to patch quickly due to custom code, complex dependencies, and a lack of deployment automation.

Virtual patching protects these applications at the network layer without modifying application code or the PHP runtime. An AI engine evaluates the application, dynamically generates targeted exploit signatures, and deploys them at an inline enforcement point (e.g., an application connector or gateway) to block malicious PHP2Shell requests before they reach the server.

This approach has several advantages for PHP2Shell specifically:

• Application-aware precision. Context-aware rules minimize false positives and catch exploit variants missed by generic WAF rules.
• No-touch deployment. Applied at the gateway layer without code changes or restarts, making it ideal for legacy or unsupported PHP versions.
• Continuous, autonomous updates. The AI engine detects emerging payload variants and deploys updated signatures automatically without manual intervention.
• Scales across the application estate. Provides immediate baseline protection across large private estates, transforming emergency patching into a manageable process.

Key takeaway: Compensating controls are not a substitute for patching, but they are essential for the reality of enterprise PHP estates. Remove what you can from the internet, retire what you do not need, lock down what remains, and deploy virtual patching to protect what you cannot patch yet.

How Zscaler Agentic SecOps Can Help

PHP2Shell is a textbook case for why modern security operations need to go beyond "find it and patch it." 

The Zscaler Agentic SecOps portfolio can help security teams respond to PHP2Shell – and to the next critical vulnerability that follows it – with the following capabilities:

Zscaler Exposure Management

Exposure Management surfaces PHP risk across your environment and enables a complete find-prioritize-fix-verify workflow:

• Understand PHP risk. Combine native EASM discovery of impacted assets with third-party sources across your environment to understand PHP risk holistically.
• Prioritize high-risk exposures. Identify internet-facing and crown-jewel assets, group and assign tickets to the rightful owners for remediation.
• Prescribe the fix. Generate and share AI-powered fix instructions with ZAgent, then rescan targeted assets to confirm the fix is in place.
• Mitigate risk from EOL assets. Create compliance policies for end-of-life PHP versions, report on compliance with pre-built dashboards, and auto-assign critical violations for unpatchable assets.

Zscaler Deception

Deception detects exploitation attempts with high-fidelity decoys that mimic the applications attackers are actively targeting:

• Application-specific decoys. Deploy Threat Intel decoys for the applications being targeted with PHP2Shell exploits: WordPress Login, Drupal Admin Panel, Joomla Admin Panel, phpMyAdmin, and Nextcloud. These decoys will detect any PHP2Shell exploitation activity against them and provide a high fidelity alert. 

• Automated IP blocking. By integrating decoy telemetry with downstream orchestrations, you can dynamically capture and block attacker IPs on your perimeter firewalls. This compensatory control requires very little operational effort and significantly reduces risk by neutralizing active, local threat actors instead of struggling to block generic, static IP lists.

For Deception customers, when a major CVE is disclosed, Zscaler pushes updated vulnerable application datasets (CVE datasets) directly to your tenant, allowing you to deploy realistic, simulated targets in minutes. When an attacker attempts to exploit one of these decoys, our ThreatParse engine automatically reconstructs the attack log, maps it to the MITRE ATT&CK framework, and tags the alert with the specific CVE ID.

Zscaler Managed Detection & Response (MDR)

For organizations that need to augment their security teams, Zscaler MDR provides 24x7 expert monitoring, proactive threat hunting, and hands-on response so that exploitation and post-exploitation activity doesn't go unnoticed while patches roll out.

• Always-on monitoring. Zscaler MDR analysts monitor your environment 24x7x365, investigating suspicious activity in real time. For a vulnerability like PHP2Shell, this means continuous surveillance for signs of exploitation. AI agents work alongside human analysts to accelerate the path from alert to action.
• Proactive threat hunting. MDR doesn't wait for alerts. Our threat hunters proactively seek indicators of compromise and attacker tradecraft tied to active campaigns like PHP2Shell. When a hunt finds something, they check to ensure our analytics catch it and any new discoveries get engineered into detections, so all customers are protected.
• RCE detection. Detection rules tuned for suspicious remote code execution activity, including Linux web servers spawning suspicious commands and web servers creating inline PHP scripts or spawning reconnaissance commands.
• Active remediation. When a threat is confirmed, Zscaler MDR can implement containment and remediation actions to neutralize threats before they spread. This includes isolating compromised hosts, blocking malicious processes, and coordinating with your internal teams to restore safe operations.

Versatile Risk Reduction is Now a Necessity

There is no one magic bullet to address the risks of PHP2Shell. 

Yes, patching is the only permanent fix, but the data tells us that no security team can patch its way to zero exposure on a timeline that matches real threats. Most organizations are still yet to patch all internet-exposed PHP assets. A third of the PHP estate runs on EOL versions that will never receive an official fix. Attackers started probing four days before disclosure and were already attempting to exploit millions of targets within hours of the announcement. The math does not work in the defender's favor.

The more integrated your security program, the more options you’ll have available for rapid response. Start with this checklist:

✓ Maintain a real-time inventory of all assets, including internet-exposure

✓ Maintain business context such as criticality and business services associated with each asset

✓ Understand which 50 assets must be patched out of thousands of potentially impacted

✓ Deploy virtual patching to shield applications you cannot update

✓ Layer Deception to catch and contain attackers who find a gap

✓ Integrate alert monitoring with exposure management to catch suspicious activity that began prior to protections

Each layer of defense compensates for the limitations of the others, and together they buy the time your teams need to systematically reduce critical exposure in hours, and long tail exposure in days rather than months.

PHP2Shell is not the last disclosure of this kind. Frontier AI models will uncover high-impact vulnerabilities and exploit chains that require rapid response. Security teams that treat PHP2Shell as an isolated fire drill will find themselves repeating the same scramble. 

The organizations that use this moment to build the muscles for exposure visibility, compensating-control playbooks, virtual patching infrastructure, and detection and response readiness will be the ones who are prepared when the next AI-fueled disclosure arrives. And it will arrive.

To learn more about how to protect your organization from PHP2Shell, watch the Zscaler Rapid Response Briefing for Securing PHP.

Contributors: Keith Do, Carol Caley