PHP2Shell: The Critical PHP Vulnerabilities That Turned Ordinary Web Requests Into a Server-Side…

How two memory-safety flaws exposed PHP-powered applications to unauthenticated remote code execution — and why defenders had only hours to respond.

The Warning That Arrived Before the Headlines

On October 17, 2026, an unusual request reached an Amazon threat-intelligence honeypot. The request appeared to be an attempt to exploit a vulnerability in PHP, one of the internet's most widely deployed server-side programming languages.

At the time, the vulnerability had not been publicly disclosed.

Four days later, the security community learned about two critical PHP vulnerabilities now collectively known as PHP2Shell: CVE-2026–109618 and CVE-2026–109619.

Amazon Web Services (AWS) subsequently reported that it had identified the October 17 attempt through its MadPot honeypot telemetry. After the public disclosure on October 21, AWS observed additional exploit attempts and reported widespread exploitation activity in the wild. It cautioned, however, that the success of the earlier attempts against real-world systems remained uncertain. AWS Security Blog

This sequence illustrates an uncomfortable reality for security teams: attackers do not necessarily wait for a vulnerability advisory before attempting exploitation.

But what makes PHP2Shell so dangerous? The answer lies beneath the websites themselves — in the PHP runtime responsible for processing their requests.

What Is PHP2Shell?

PHP2Shell is the collective name for two critical vulnerabilities in PHP's core execution engine. Both involve unsafe memory handling when request processing terminates abnormally.

Each vulnerability received a CVSS v4.0 score of 9.2, indicating critical security risk. Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code on a vulnerable server. The flaws may also expose sensitive data held in PHP process memory.

The distinction matters: these are not simply vulnerabilities in a WordPress plugin, Drupal module, or Joomla extension. The underlying PHP runtime is affected, making the risk broader than any one web application.

Researchers demonstrated successful remote code execution on systems running WordPress, Drupal, and Joomla. These platforms illustrate the potential impact, but an application-specific coding flaw is not required for exploitation. Wiz Research

How Does the Attack Work?

Imagine a web server receiving an ordinary HTTP request. PHP begins processing it, allocates memory, handles request data, and prepares to return a response.

Now imagine the request pushes PHP into an exceptional error condition. Instead of leaving the runtime in a clean, predictable state, vulnerable code can leave behind invalid or stale memory references.

An attacker who can trigger that condition and carefully influence how memory is used afterward may turn a runtime error into a security breach.

At a high level, the attack chain looks like this:

Crafted HTTP request → abnormal error handling → unsafe memory state → memory corruption or use-after-free → potential remote code execution.

The two CVEs follow different paths.

1. CVE-2026–109618: When PHP Runs Out of Memory

PHP uses an out-of-memory (OOM) handling mechanism to interrupt normal execution when memory allocation fails. This process can involve longjmp(), which transfers control away from the current execution context.

The vulnerability occurs when certain internal request data has not been fully initialized before this interruption. Later, PHP's request-cleanup logic may treat that invalid data as if it were valid.

The result is an unsafe memory-access condition that can be exploited to corrupt process memory and potentially execute code.

Crafted HTTP requests, including specially constructed multipart requests, can help trigger the vulnerable processing path.

2. CVE-2026–109619: When Old Memory State Survives a Request

The second vulnerability involves stale global state.

PHP maintains internal state while processing requests. Under certain fatal-error conditions, a global reference can continue pointing to request-owned memory even after that memory has been freed.

If a subsequent request handled by the same worker encounters and uses that stale reference before the state is correctly reinitialized, it can trigger a use-after-free condition.

With sufficient control over the affected memory, the attacker may be able to turn this condition into remote code execution.

One confirmed path involves PHP session upload-progress functionality, which is why the PHP team's temporary mitigation guidance addresses that feature.

The technical distinction is important: one vulnerability involves unsafe handling of an out-of-memory interruption, while the other involves stale state after abnormal request termination. Both can undermine the runtime's memory safety.

Sources: Official PHP security advisory | NHS England Digital advisory

When Did PHP2Shell Emerge?

The events leading to public disclosure unfolded over several weeks.

• August 19, 2026: Wiz Research discovered the first vulnerability with assistance from AI-powered research tools.
• August 20–21: Researchers confirmed unauthenticated remote code execution against Drupal and WordPress test environments.
• August 24: The vulnerabilities were reported to the PHP security team.
• September 21: PHP acknowledged the reports and began coordinating a fix.
• October 17: AWS later identified a PHP2Shell exploitation attempt against a honeypot, before public disclosure.
• October 20–21: Information about the vulnerabilities leaked, and PHP moved forward its security release.
• October 21: PHP published patched releases and the vulnerabilities were publicly disclosed. Additional exploitation attempts followed.

The responsible-disclosure timeline comes from Wiz Research, while the pre-disclosure activity was documented by AWS. These observations do not establish that every attempt succeeded, but they demonstrate why the earliest known attack activity can matter more than the advisory publication date. Wiz Research | AWS threat-intelligence report

Where Is the Risk?

The affected component is PHP itself, so exposure is not limited to one CMS or web framework.

The PHP security team identified web-serving installations using configurations including:

• Apache with mod_php
• PHP-FPM
• php-cgi
• FrankenPHP
• LiteSpeed

The PHP team considers mod_php particularly high-risk because a demonstrated attack can trigger the vulnerability before application-level code executes.

This matters because application-level authentication and authorization checks may never get the opportunity to protect the request. A vulnerable runtime can be exposed even when a website's own code is otherwise well secured.

The risk can also extend beyond conventional websites. Devices, appliances, containers, management interfaces, and commercial products may include their own PHP runtimes. Organizations must therefore inspect embedded and bundled PHP components, rather than relying exclusively on their web application's dependency inventory.

Why Does PHP2Shell Matter So Much?

There are three major reasons.

First, the potential impact is severe. Successful remote code execution can give an attacker the privileges of the vulnerable PHP worker. Depending on those permissions and the environment, the attacker could alter website files, run unauthorized processes, steal application data, or establish persistence. Separately, access to PHP process memory could expose passwords, API tokens, and other secrets.

Second, authentication is not a reliable barrier. The vulnerabilities can be triggered through network requests without requiring a legitimate account or user interaction. Application-level security controls cannot be assumed to stop every exploitation path.

Third, the window between disclosure and exploitation can be extremely short. Researchers reported using AI-assisted techniques to analyze the vulnerable code paths and develop working exploits. This does not mean AI is required to exploit PHP2Shell. It means advanced analysis and exploit adaptation may require less time and specialist effort than defenders have historically expected. Wiz Research

PHP's emergency patches were therefore not routine maintenance. They addressed vulnerabilities that could potentially turn a publicly reachable PHP service into an entry point for server compromise.

What Should Security Teams Do Now?

As of October 22, 2026, the priority should be to identify exposure, patch affected runtimes, and investigate possible compromise.

1. Update PHP immediately.

The security releases are:

PHP branch Fixed version PHP 8.58.5.12 PHP 8.48.4.27 PHP 8.38.3.36 PHP 8.28.2.35

PHP 8.1 and older are no longer maintained by the PHP project. Organizations using these branches should check whether their Linux distribution or long-term-support vendor supplies a backported security fix, and plan to move to a supported version.

2. Inventory all internet-facing PHP services.

Check web servers, containers, cloud workloads, third-party appliances, and embedded runtimes. Confirm the actual PHP version handling requests, not merely the version installed on an administrator's workstation.

3. Apply temporary exposure-reduction measures if patching is delayed.

Follow the official PHP advisory for configuration-specific mitigations. These include disabling session.upload_progress where appropriate, restricting request and multipart-upload sizes, and restarting affected workers when required. A web application firewall can provide an additional protective layer.

These measures do not constitute a complete fix. PHP's security team identifies updating to a fixed release as the safe remediation.

4. Investigate activity dating back to October 17.

Review web-server and application logs for suspicious POST requests, unexpected upload-related activity, PHP worker crashes, unusual child processes, unexpected file modifications, and unexplained outbound connections. Where available, correlate web logs with endpoint and cloud telemetry.

The October 17 date is a useful minimum starting point for an investigation because of the activity AWS reported. It does not prove that a particular system was targeted or compromised.

Official guidance: PHP security advisory | Canadian Centre for Cyber Security

Conclusion: Patch the Runtime, Not Just the Website

PHP2Shell is a reminder that application security does not begin and end with plugins, frameworks, or application code. The language runtime underneath them is part of the attack surface too.

A request that appears ordinary at the network layer can take advantage of a deeper memory-safety failure. Once that failure is exploitable, the impact can extend well beyond the original HTTP request.

The lesson for defenders is straightforward: maintain visibility into the software that actually runs production services, prioritize critical patches according to exposure and exploit activity, and investigate credible signs of exploitation rather than assuming that a patched system was never compromised.

The most important action is to update every affected PHP runtime — and then verify that no attacker gained access before the fix was applied.

#php2shell #cybersecurity #recentthreats #php #aws #cve #blueteam