PHP2Shell Vulnerability: How It Was Exposed, the Risks and the Fix

The PHP2Shell vulnerability, publicly disclosed on 21 October 2026, exposed two critical security flaws in PHP that can allow attackers to execute malicious code on vulnerable web servers without authentication. Both vulnerabilities carry a CVSS v4.0 severity score of 9.2 out of 10, making them a serious concern for website owners, developers and hosting providers.

The problem extends beyond any single website platform. PHP powers WordPress, Drupal, Joomla and many other web applications. Because PHP2Shell affects the underlying PHP runtime rather than a particular plugin, theme or content management system, even a fully updated website can remain vulnerable if its server is running an affected PHP version.

The way PHP2Shell came to light is also remarkable. The underlying problem had been recognised years earlier, but AI-assisted security research helped turn it into demonstrable remote attacks. A disrupted disclosure process then forced developers to release security updates earlier than planned, while evidence subsequently emerged of attempted exploitation before the vulnerability became public.

The essential fix is to update PHP itself. Updating WordPress or another application alone will not address the underlying flaws. Website administrators must ensure that the appropriate patched PHP runtime is installed and running.

What Is the PHP2Shell Vulnerability?

The PHP2Shell vulnerability is the collective name for two related memory-safety flaws in PHP’s core engine. They involve the way PHP handles memory allocation, fatal errors and data left behind when request processing is interrupted unexpectedly.

Although the two flaws have different causes, both can potentially allow unauthenticated remote code execution (RCE). In certain circumstances, researchers also demonstrated the ability to expose sensitive process memory.

The vulnerabilities are identified as:

• CVE-2026-109618: Remote code execution through out-of-memory (OOM) corruption. When a memory allocation fails at the wrong moment, PHP can leave internal data partially initialised. Subsequent cleanup operations may then treat that invalid data as legitimate, potentially corrupting memory.
• CVE-2026-109619: Remote code execution through stale global state. A fatal error can leave PHP holding references to memory that has already been freed. A later request handled by the same worker may access that stale memory, creating a use-after-free condition.

Both vulnerabilities affect fundamental PHP operations rather than optional features that are easily isolated from applications.

The PHP Foundation confirmed successful remote code execution against Apache configurations using mod_php, including an attack that can be triggered before application code starts running. Exploitation was also demonstrated through application-level paths using PHP-FPM.

This is why PHP2Shell is different from an ordinary website vulnerability. Fixing an insecure plugin or strengthening website passwords cannot resolve a weakness inside the language runtime.

The official PHP security announcement provides the technical classification, affected environments and remediation guidance.

How Was the PHP2Shell Vulnerability Discovered?

One of the most important details about PHP2Shell is that the underlying problem was not entirely new when it was publicly disclosed.

The warning signs existed before 2026

PHP has a long history of security research involving memory management and unexpected execution failures. Some of the techniques relevant to the current vulnerabilities can be traced to earlier investigations dating back more than two decades.

In 2024, the PHP Foundation organised an external security audit carried out by Quarkslab, with support from the Open Source Technology Improvement Fund (OSTIF) and funding secured through the Sovereign Tech Agency.

During follow-up work, a PHP core developer identified signs of the out-of-memory issue that would later become CVE-2026-109618.

However, researchers had not demonstrated a practical remote code execution route at that stage. The PHP team investigated potential fixes, but each approach introduced difficult trade-offs involving compatibility, performance, third-party extensions or potential denial-of-service behaviour.

The PHP Foundation has since acknowledged that limited engineering resources and difficulties reaching a decision contributed to the delay in resolving the underlying issue.

The vulnerability therefore illustrates an important distinction in software security: identifying a potential weakness does not always establish the full extent of what an attacker can achieve with it.

AI-assisted research demonstrated the security risk

The investigation accelerated during the summer of 2026.

On 30 July, security research company Calif began auditing PHP through OpenAI’s Patch the Planet initiative, which supports the discovery and coordinated remediation of vulnerabilities in widely used open-source software.

Calif researcher Ryan A reported a remote code execution vulnerability to the PHP security team on 11 August, connecting the exploit to the underlying out-of-memory problem previously identified in 2024.

Other researchers subsequently reached related findings. Wiz Research independently discovered and reported vulnerabilities in August, while OpenAI researchers identified the same underlying cause and additional attack paths.

Artificial intelligence played a substantial role in these investigations. Researchers used AI-assisted analysis to examine PHP internals, investigate memory handling, identify exploitable conditions and develop proofs of concept.

Importantly, the discoveries were not simply a case of an AI model independently finding and fixing everything. Experienced security researchers guided the investigations, established the practical impact and worked with PHP maintainers to validate and resolve the problems.

Calif’s original PHP2Shell research and Wiz Research’s technical analysis describe the research process and demonstrate how the weaknesses could be exploited against real PHP applications.

How Was the PHP2Shell Vulnerability Exposed to the Public?

The original plan was to coordinate the release of security patches and vulnerability details on 22 October 2026. That arrangement was intended to give PHP distributors, hosting companies and infrastructure providers time to prepare updates.

However, the disclosure began to unravel on 20 October.

20 October: Vulnerability information begins circulating

At approximately 15:00 UTC, the CVE identifiers for both vulnerabilities began appearing on online forums and social media.

According to the PHP Foundation, these early posts included inaccurate information, including an incorrect severity score of 10.0 rather than the confirmed CVSS v4.0 score of 9.2. The initial leak did not contain the technical details needed to reproduce the vulnerabilities.

Nevertheless, the information was enough to prompt a change in the release schedule.

The PHP project brought forward its pre-announcement and moved the security update from 22 October to 21 October.

An accidental exploit demonstration added pressure

Following the earlier announcement, Calif mistakenly published a video demonstrating its proof-of-concept exploit against several targets.

Although the video was removed, copies quickly circulated online. This exposed additional technical information and contributed to faster development of other proof-of-concept attacks.

According to the PHP Foundation, patched container images were also published by Chainguard more than six hours before the agreed release time. This potentially allowed people to examine the security changes before other PHP users could obtain the scheduled updates.

On 21 October, PHP officially released the patched versions.

The PHP Foundation’s disclosure account explains the sequence of events and the coordination difficulties involved.

Attack attempts were observed before disclosure

There is another important part of the story.

Amazon Threat Intelligence subsequently reported that its MadPot honeypot network had recorded an attempted PHP2Shell exploit on 17 October 2026, four days before the official public disclosure.

The activity originated from infrastructure associated with a commercial anonymisation network. Amazon could not establish how the actor obtained information about the vulnerability before disclosure.

Further attempts appeared around the release, with Amazon reporting that different payloads and infrastructure suggested activity from multiple actors.

Cloudflare also documented attack traffic and the emergency deployment of web application firewall protections.

These findings establish that attempted exploitation was occurring. They do not establish that every observed attempt succeeded or provide a confirmed total of compromised production websites.

Amazon’s PHP2Shell threat intelligence report contains further details.

What Are the Risks of the PHP2Shell Vulnerability?

The main risk of the PHP2Shell vulnerability is unauthenticated remote code execution. In simple terms, a successful attacker may be able to run code on an affected server without first obtaining legitimate login credentials.

The consequences depend on the server configuration, the permissions of the affected PHP process and the attacker’s ability to exploit the environment.

Unauthorised control of a website

Successful code execution could allow an attacker to alter accessible website files, install malicious scripts, interfere with application behaviour or establish persistent access.

For a business, that may mean website defacement, malicious redirects, compromised content or interference with services used by customers.

Exposure of customer information and credentials

Researchers also demonstrated the possibility of disclosing sensitive information held in PHP process memory.

Depending on the application and its configuration, this could include authentication tokens, credentials, API keys or other data processed by the server.

If an attacker obtains credentials for connected services, the effects of a successful compromise may extend beyond the original website.

Website downtime and operational disruption

The underlying memory-handling flaws can also cause worker crashes or interruptions to request processing.

For websites handling orders, bookings, customer enquiries or account access, availability problems can affect ordinary business operations.

Not every vulnerable installation will be exploitable through the same method. The practical attack paths depend on factors such as the PHP version, server interface, configuration and application behaviour.

However, the demonstrated impact is serious enough that both the PHP project and the UK’s National Cyber Security Centre recommend urgent remediation.

Which PHP Versions Are Affected?

On 21 October 2026, PHP released fixes across its supported security branches.

The first patched upstream versions are:

Earlier releases in these branches are affected unless a vendor has supplied an appropriate backported fix.

Older versions, including PHP 8.1 and earlier, are also affected. These versions no longer receive standard upstream security releases, although some Linux distributions, hosting vendors and extended-support providers offer patched packages.

Those packages may retain an older version number. Administrators must therefore check the complete package revision and the relevant vendor security advisory rather than assuming that a particular version string alone proves whether the server is patched.

For unsupported PHP versions, migrating to a maintained branch remains the preferred long-term solution.

How to Fix the PHP2Shell Vulnerability

The correct solution to the PHP2Shell vulnerability is to install a patched PHP runtime, confirm that the affected services are using it and investigate whether there is evidence of earlier compromise.

The process differs depending on whether the website runs on shared hosting, managed infrastructure or a server maintained directly by its administrator.

1. Identify the PHP version actually serving your website

For WordPress, version information is usually available through Tools > Site Health > Info > Server.

Hosting control panels such as cPanel and Plesk also provide information about PHP versions and configuration.

For developers with authorised server access, the PHP command-line version can be checked using:

php -v

However, this command only identifies the command-line PHP installation. It may not be the same version handling requests from your public website.

Administrators should inspect the actual web-serving runtime, including PHP-FPM pools, Apache modules, container images and any separate PHP installations used by individual applications.

2. Install the appropriate security update

Where possible, upgrade to the relevant patched PHP release:

• PHP 8.5.12 or later within the PHP 8.5 branch.
• PHP 8.4.27 or later within the PHP 8.4 branch.
• PHP 8.3.36 or later within the PHP 8.3 branch.
• PHP 8.2.35 or later within the PHP 8.2 branch.

Where PHP is installed through a Linux distribution or hosting provider, use that vendor’s supported security packages and verify that the necessary fixes are included.

If the site runs on managed hosting, ask the provider to confirm that the PHP2Shell vulnerability has been patched in the runtime actually serving the website.

Following installation, restart affected PHP workers and services to ensure that the patched code is loaded.

Applications using Docker or other container systems may need their images rebuilt and redeployed. Updating PHP on the host operating system does not necessarily update PHP bundled inside a container or third-party application.

3. Verify that the website still functions correctly

After applying the update, confirm that the website operates normally.

Important checks include:

• Contact forms and enquiry submissions.
• Login and customer account functionality.
• Checkout, payment and booking processes.
• File uploads and document processing.
• Scheduled tasks, integrations and custom PHP features.

For complex websites, compatibility testing may be necessary. That testing should be planned around the urgent security update rather than used as a reason to leave a critical vulnerability unresolved.

4. Investigate suspicious server activity

A security update prevents the identified exploit paths from being used against the patched code. It does not automatically remove malicious files or restore credentials that may have been compromised earlier.

Administrators should review relevant security, PHP and web server logs for unusual requests, repeated memory failures, unexplained worker crashes or suspicious process execution.

Amazon’s investigation highlighted unusual multipart POST requests involving PHP_SESSION_UPLOAD_PROGRESS as one potential indicator worth examining.

Because attempted exploitation was observed as early as 17 October, investigations should consider historical activity before the official public disclosure wherever logs are available.

These indicators must be interpreted in context. Suspicious traffic does not automatically demonstrate successful compromise, and the absence of obvious indicators does not prove that a vulnerable system was unaffected.

If compromise is suspected, a proper incident investigation may need to include credential rotation, removal of persistence mechanisms and restoration from a verified clean state.

Can a Firewall Protect Against PHP2Shell?

A web application firewall (WAF) can reduce exposure to some known PHP2Shell attack methods, but it should not replace the PHP security update.

Cloudflare developed emergency protections during the coordinated response and deployed them ahead of public disclosure. Other infrastructure providers also introduced defensive measures.

These protections are useful because they can identify and block suspicious requests before those requests reach the application server.

However, the PHP2Shell vulnerabilities involve multiple attack paths. A firewall rule designed to stop one known payload may not prevent other ways of reaching the vulnerable code.

The PHP team published temporary configuration mitigations for operators unable to patch immediately. These included changes involving memory limits, request-size handling and session upload progress.

Such changes can have operational consequences and do not constitute complete protection.

The UK’s National Cyber Security Centre recommends considering taking affected services offline where neither the required patch nor adequate temporary mitigations can be applied promptly.

The priority remains patching the underlying PHP runtime.

Additional PHP security advisory: 23 October 2026

On 23 October, PHP published a further informational advisory concerning an unusual session upload-progress scenario, tracked separately as CVE-2026-115560.

The issue requires a particular combination of session serialisation settings and application behaviour. PHP recommends temporarily setting session.upload_progress.enabled=0 for affected configurations until the next regular bug-fix release.

This is separate from the two original PHP2Shell CVEs and does not change the need to install the 21 October security fixes.

Administrators should consult the latest PHP security information when assessing whether additional configuration changes are necessary.

Why WordPress Security Updates Alone Cannot Fix PHP2Shell

For WordPress website owners, the PHP2Shell vulnerability demonstrates an often-overlooked distinction between application security and server security.

WordPress core, themes and plugins can receive security updates independently of the PHP runtime installed on the hosting server.

That means a WordPress website may be completely up to date from the dashboard’s perspective while its underlying PHP environment remains vulnerable.

This is also true for other PHP applications. Updating Drupal, Joomla or Laravel application dependencies cannot fix an unrelated vulnerability inside the installed PHP runtime.

In our earlier article, Should You Update WordPress Immediately After a Security Release?, we discussed the importance of applying updates while managing compatibility and operational risk.

PHP2Shell adds another consideration: businesses need to know who maintains the software underneath their website, not just who manages its content and plugins.

For businesses using managed hosting, that responsibility may belong primarily to the hosting provider. For organisations operating their own servers, it will generally sit with their infrastructure or development team.

The important questions are straightforward. Who monitors PHP security advisories? Who installs critical runtime updates? How is successful deployment verified? And who investigates if the server may have been exposed before a fix became available?

These responsibilities are part of a wider approach to website security and web application protection, where access control, software maintenance, server configuration and ongoing monitoring all contribute to reducing risk.

What PHP2Shell Reveals About Modern Website Security

PHP2Shell is significant for more than the severity of its vulnerabilities.

The underlying out-of-memory problem had been recognised before researchers demonstrated how it could be used to execute code remotely. AI-assisted investigation helped establish that missing connection, while experienced engineers remained essential to assessing the impact and developing compatible fixes.

The disclosure process also demonstrated how difficult coordinated security releases can become when information starts circulating before patches are widely available.

For businesses, however, the practical lesson is simpler.

A secure website depends on more than the application running on it. The PHP runtime, hosting environment, operating system, installed dependencies and update processes all require attention.

If your website uses PHP, confirm that its runtime includes the October 2026 security fixes. Check the version actually serving requests, verify the patch with your hosting provider where appropriate and investigate any evidence of earlier exploitation.

PHP2Shell should not be interpreted as proof that every PHP website has been compromised. It is a reminder that even well-maintained applications can depend on underlying software with vulnerabilities of its own.

The responsibility is to know what your website runs on, keep that software supported and ensure critical security fixes reach the live environment promptly.