PHP2Shell: Critical PHP Vulnerabilities Were Targeted Before Public Disclosure

Your website may be fully updated, its plugins secure, and its access controls properly configured. Yet attackers could still compromise the underlying server without logging in. Two critical PHP vulnerabilities, collectively known as PHP2Shell, expose a security risk that extends beyond individual websites. New findings from Amazon reveal that exploitation attempts began four days before the vulnerabilities were publicly disclosed.

On October 21, 2026, two critical vulnerabilities were disclosed in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619. Both received a CVSS v4.0 score of 9.2 out of 10 and can enable unauthenticated remote code execution (RCE) under vulnerable conditions.

PHP powers a substantial proportion of the world's websites, including e-commerce platforms, customer portals, and content management systems such as WordPress, Drupal, and Joomla. Researchers at Wiz estimate that PHP is used by approximately 70% of websites. This does not mean that 70% of websites are exploitable: actual exposure depends on the PHP version, deployment configuration, and available security patches.

Unlike typical application vulnerabilities, PHP2Shell affects the underlying PHP runtime rather than a particular plugin, CMS, or application. Updating WordPress alone will not resolve the issue if the server continues running vulnerable PHP code.

How PHP2Shell Works: Exploitation Before Application Code Runs

Both vulnerabilities involve memory-safety issues in PHP's handling of HTTP requests, but their underlying mechanisms differ.

CVE-2026-109618 – Remote code execution through out-of-memory corruption

When memory allocation fails during request processing, PHP may leave internal request structures only partially initialized. During subsequent cleanup, the runtime can mistakenly process invalid data as legitimate, potentially enabling arbitrary code execution.

CVE-2026-109619 – Remote code execution through stale internal state

The second vulnerability involves request-specific internal state surviving after its underlying memory has been freed. A later request processed by the same PHP worker may reuse this invalid state before normal initialization resets it, potentially allowing unauthorized memory access and code execution.

Security researchers independently reproduced exploitation of PHP2Shell. Datadog Security Labs documented an attack involving CVE-2026-109618 in which an unauthenticated HTTP request triggered malicious code execution before the target application's code was reached.

This is what makes PHP2Shell particularly dangerous: application-level authentication and security checks may never get the opportunity to stop the attack.

Successful exploitation could allow an attacker to access sensitive information, execute malicious processes, deploy malware, or use the compromised server as a foothold for further attacks. The extent of the impact depends on the permissions of the PHP process and the surrounding infrastructure.

Why AI Played a Significant Role in the Discovery

According to Wiz Research, some of the vulnerable PHP mechanisms date back to PHP 5.4, released in 2012.

Researchers from Wiz, Calif, OpenAI, and Quarkslab contributed to the discovery, analysis, and coordinated remediation effort. Advanced AI models helped researchers investigate complex memory behavior, develop exploits, and validate fixes.

Wiz reports that AI-assisted research significantly accelerated the adaptation of working exploits across different application environments.

This highlights a broader change in cybersecurity. Vulnerabilities that once required extensive manual research may become easier to analyze and exploit with advanced AI tools.

For security teams, the practical implication is a potentially shorter window between vulnerability disclosure and real-world exploitation. PHP2Shell demonstrates why vulnerability management must be able to respond quickly.

Amazon Detected Exploitation Attempts Four Days Before Disclosure

New findings published on October 22 by Amazon Threat Intelligence reveal that PHP2Shell was being targeted before the vulnerabilities became public.

Amazon identified an exploitation attempt on October 17, 2026, through its MadPot honeypot infrastructure, four days before the official disclosure. The activity originated from an IP address associated with a commercial anonymization network.

Further attempts were observed on October 21, including activity originating from different anonymized sources. The findings suggest that more than one actor may have had access to information about the vulnerabilities before their public release.

After the patches became available, publicly accessible exploit implementations appeared and were quickly observed targeting Amazon's sensors.

Cloudflare separately confirmed malicious traffic associated with PHP2Shell, including attempts to evade its protective security rules. The company deployed Web Application Firewall (WAF) mitigations across its customer base, including free-tier users.

These observations are particularly significant because exploitation attempts preceded public disclosure. Organizations investigating potential exposure should therefore review historical activity rather than limiting their analysis to events occurring after the release of security patches.

However, exploitation attempts observed by honeypots and security providers do not automatically establish successful compromise of production systems.

Which PHP Installations Are Affected?

The PHP security team identifies risks across web-serving PHP environments, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed.

Apache with mod_php is considered particularly high-risk, with demonstrated unauthenticated exploitation before application code execution. Other deployment methods should not be assumed safe without verification.

The following patched releases became available on October 21, 2026:

PHP 8.1 and older branches are no longer supported by the PHP project. However, some Linux distributions and long-term support vendors provide backported security fixes. The PHP security team has also made minimal source patches available for PHP 7.4, 8.0, and 8.1.

Organizations should therefore verify vendor security advisories and package changelogs rather than relying exclusively on version numbers.

Five Actions Organizations Should Take Now

1. Identify every PHP deployment. Inventory internet-facing applications, internal systems, containers, third-party products, and embedded PHP runtimes. Prioritize services accessible from the internet and systems handling sensitive business data.

2. Apply security patches immediately. Upgrade to a fixed PHP release or install a vendor-supported patched package. Restart Apache, PHP-FPM, and other long-running PHP workers, then verify that the updated runtime is active. For containerized environments, rebuild affected images and redeploy running workloads. Updating a source repository alone does not remediate production systems.

3. Investigate potential compromise, including activity before disclosure. Review relevant security telemetry from at least October 17, when Amazon observed an early exploitation attempt. Examine suspicious HTTP requests, unusually large form submissions, memory-exhaustion errors, unexpected child processes spawned by PHP, and unauthorized file modifications. Correlate web server, endpoint, and network telemetry wherever possible.

4. Reduce exposure where immediate patching is not possible. Apply vendor-recommended WAF protections, restrict unnecessary public access, and consider temporarily isolating vulnerable services. These are risk-reduction measures, not complete fixes.

5. Validate security after remediation. Confirm that vulnerable runtimes have been replaced, verify the effectiveness of deployed security controls, and investigate whether suspicious activity occurred before patch deployment. Remediation and compromise assessment are separate tasks.

Why a Working Website Does Not Mean a Secure Server

Datadog's research highlights an important detection challenge: successful exploitation does not necessarily cause the PHP worker to crash.

A compromised server may continue responding normally, leaving administrators with no obvious indication of an attack.

Security teams should therefore investigate more than service availability. Relevant signals include unexpected command execution, unusual PHP process behavior, memory-related errors, and suspicious HTTP traffic.

Network detection provides additional visibility. Corelight has published Zeek and Suricata detections, while Elastic has outlined behavioral detection approaches focused on suspicious processes and post-exploitation activity. These measures can help identify attacks, although their effectiveness depends on visibility, configuration, and the techniques used.

Google Cloud has also published guidance on protecting cloud environments, emphasizing that organizations must update deployed workloads, not merely their source code. This is especially important for containerized applications, where vulnerable runtime images may remain active even after updated versions become available.

Temporary configuration changes have limitations. For example, disabling session.upload_progress may reduce exposure to certain attack paths, but it does not eliminate the vulnerabilities.

Applying the relevant PHP security updates remains the essential remediation.

What PHP2Shell Means for CIOs, CTOs, and CISOs

PHP2Shell raises a question that extends well beyond PHP itself: How much visibility does your organization have into the technologies running beneath its business applications?

An application may pass security reviews, use strong authentication, and receive regular updates while remaining exposed through its runtime, dependencies, or server configuration.

For technology and security leaders, three capabilities are especially important:

• Technology visibility: Knowing which runtimes, libraries, and dependencies are deployed across business-critical systems, including those managed by external providers.
• Rapid remediation: Being able to identify affected assets, deploy patches across production environments, and verify remediation without unnecessary delays.
• Compromise detection: Having sufficient telemetry and incident response capabilities to determine whether an exposed system has already been attacked, including before public vulnerability disclosure.

The Amazon findings add another important consideration. Organizations cannot assume that the period before public disclosure was necessarily safe. When credible evidence of earlier exploitation emerges, incident investigations may need to cover a longer historical window.

These capabilities are not limited to PHP2Shell. They are essential for responding to future vulnerabilities in widely used software components.

PHP2Shell Is a Reminder That Application Security Does Not End with Application Code

PHP2Shell demonstrates how vulnerabilities in underlying technologies can undermine otherwise well-secured applications.

The immediate priorities are clear: patch vulnerable PHP installations and investigate potential exploitation, including activity that may have occurred before public disclosure.

Beyond the immediate response, organizations should assess whether their security processes provide sufficient visibility into application dependencies, server configurations, and possible attack paths following an initial compromise.

Professional penetration testing helps organizations identify weaknesses across web applications and infrastructure, validate their exploitability, and understand their potential business impact.

Need to assess the security of your web applications or infrastructure? Citadelo's security experts can help identify vulnerabilities, evaluate exposure, and prioritize remediation based on real-world risk.