PHP2Shell: A Clear Explanation and Response Framework

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, known as PHP2Shell. Both can let an unauthenticated attacker run code on servers running PHP. The disclosure was also disrupted. According to the PHP Foundation, the vulnerability IDs leaked ahead of the release and patched builds appeared hours before the coordinated release, giving attackers a head start on exploitation (though no confirmed exploitation has been reported).

If you run PHP, update now. The PHP project says configuration changes can reduce exposure, but only an update fully fixes the problem.

What is PHP2Shell?

PHP2Shell is the name for two related vulnerabilities in the core of PHP. Both sit in memory management and error handling, parts of PHP that nearly every web request touches. That's why they're serious, and it's also why they were hard to fix without breaking compatibility or hurting performance.

PHP2Shell at a glance:

CVE-2026-109618: RCE via OOM corruption 

Every PHP request has a memory limit. If a request hits that limit at exactly the wrong moment, PHP can be interrupted while it's still setting up internal data for the request. When PHP cleans up afterward, it can treat that half-built data as valid, which corrupts memory. 

An attacker who can cause the memory failure at the right point could turn that corruption into remote code execution. On Apache with mod_php, an unauthenticated request can trigger the attack before any application code runs, and researchers demonstrated full remote code execution with default settings. 

Remote code execution was also confirmed on PHP-FPM through code paths inside applications.

The full technical details are in PHP's advisory.

CVE-2026-109619: RCE via stale global state

PHP servers handle requests with long-running worker processes, and each worker handles many requests in turn. Workers keep some internal state between requests, such as error and session information, and that state can point to memory belonging to the current request. 

PHP is supposed to reset it before freeing that memory. A fatal error at the wrong point, such as running out of memory or hitting the maximum execution time, can skip the reset. The worker is then left holding a pointer to memory that has already been freed, like a note giving the address of a house that has since been sold. 

When the same worker handles the next request, PHP can follow that stale pointer before its normal setup replaces it. This type of flaw is called a use-after-free, and it can let an attacker read memory or run code with the web server's privileges. 

One confirmed attack path abuses session upload progress, a feature that is enabled by default and can be reached even if the application never calls session_start().

Researchers demonstrated remote code execution against a real-world application on mod_php, and the session upload progress path was also validated on PHP-FPM.

Who is affected?

According to the PHP project's security advisory, every PHP installation that serves web requests is at risk. That covers all the common ways of running PHP:

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

The PHP project considers the risk highest for mod_php, where the demonstrated exploit works before any application code runs.

End-of-life versions are a particular concern. PHP 8.1 and older no longer receive updates from the PHP project, so organizations still running them can't simply install a patch. 

Given how severe these vulnerabilities are, the PHP security team made an exception and published minimal source-code fixes for PHP 7.4, PHP 8.0 and PHP 8.1. These are meant for people who build PHP from source or don't have access to a long-term support vendor. 

Some Linux distributions and long-term support vendors also provide their own backported fixes. For anything older than PHP 7.4, the PHP project hasn't released a fix, and the only option is to upgrade or ask your vendor.

PHP also runs inside products and services that organizations don't manage directly. Cisco's advisory lists around 30 of its products and cloud services under investigation, including Identity Services Engine, Catalyst Center, Webex and its AppDynamics PHP Agent. It lists no workarounds for its affected products.

A disrupted disclosure

Serious vulnerabilities are normally handled through coordinated disclosure. Researchers report the bug privately to the project’s security team, which builds a fix. The fix is shared in advance with trusted distributors, such as Linux distributions, long-term support vendors and container image providers, so they can have updated packages ready. Everyone involved agrees to stay quiet until an agreed release time, a period known as an embargo.

When the embargo lifts, the vulnerability details and the fix go public together. That timing is critical, it allows defenders to start patching at the same moment attackers learn about the flaw. Disrupt this sequence, and attackers can get a head start before defenders have a fix to install. 

According to the PHP Foundation, that’s what happened with PHP2Shell.

How to respond

Follow this framework to secure your environment quickly. For more in-depth response guidelines, refer to PHP's full advisory.

1. Find every PHP instance 

You can't patch what you don't know about. Start with internet-facing systems, then work inward. Look beyond the obvious web servers to legacy and forgotten sites, staging environments, container images, and appliances or third-party products with PHP built in.

For containers, updating the base image isn't enough on its own. Images have to be rebuilt and redeployed before the fix takes effect.

2. Prioritize by deployment 

The PHP project considers every PHP installation serving web requests at risk, but exposure differs by how PHP is run. Use this to decide what to patch first, not what to skip:

• Apache with mod_php is the highest risk. An unauthenticated request can trigger the attack before any application code runs. According to GHSA-6wmf, mod_php also applies .htaccess and Apache php_value, php_flag and php_admin_* settings before PHP initializes each request. That opens an extra early path for CVE-2026-109619.
• PHP-FPM is exposed through code paths inside applications, where remote code execution has been confirmed for both vulnerabilities. It's also exposed when nginx, Apache mod_proxy_fcgi or another front-end server passes PHP_VALUE or PHP_ADMIN_VALUE settings that trigger a warning before PHP initializes the request. FPM pool settings and .user.ini files don't create that path.
• LiteSpeed (LSAPI) can apply certain configuration values early, which makes it a conditional candidate for the same configuration-based path.
• FrankenPHP has no confirmed configuration-based path in its default setup. The advisory notes this doesn't make it immune, because applications or extensions may expose other paths.
• php-cgi is listed by the PHP project as at risk. The advisories don't break down its exposure further.

3. Update PHP 

The only complete fix is to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source code is on PHP's downloads page, and Windows source and binaries are on the Windows downloads page. 

Linux distributions and long-term support vendors received the patches in advance, so check your vendor for updated packages. 

If you rely on the volunteer-maintained rpms.remirepo.net, the PHP project recommends switching to your distribution's packages or building from source, because that repository wasn't updated on release day.

4. Address end-of-life versions 

PHP 8.1 and older no longer get updates from the PHP project. The long-term answer is to upgrade to a supported branch. In the meantime, check whether your distribution or long-term support vendor offers a backported fix.

You can also build from the PHP security team's minimal source fixes for PHP 7.4, PHP 8.0 and PHP 8.1 as a stopgap. 

Anything older than PHP 7.4 has no fix from the PHP project.

5. If you can't update immediately, apply interim mitigations. 

The PHP project's advisory lists interim mitigations for each vulnerability. The project is clear that these measures "reduce exposure to specific attack paths but do not make an installation safe." Treat the mitigations as a way to buy time until you can update, not as a fix.

When applying them, follow two rules.

• Set each change in startup configuration that applications can't override, such as php.ini, the FPM pool configuration, or Apache configuration with php_admin_value. Settings applied at runtime with ini_set(), or through FPM's .user.ini files, take effect too late or can be overridden.
• Restart every PHP worker afterwards, because workers that are already running keep their old settings.

6. Audit, but don't rely on your logs 

Reviewing logs can help you find and fix errors that make attacks easier. GHSA-6wmf recommends a temporary audit with log_errors=On, a working error_log, and error_reporting=E_ALL set in startup configuration. It also lists what to look for in Apache, PHP-FPM, reverse proxy and service logs:

• warnings that repeat before scripts run
• diagnostics raised during cleanup
• fatal, parse and uncaught errors
• "Maximum execution time exceeded" messages
• failures limited to routes or inputs an attacker controls

Clean logs are not proof of safety, though. Historical logs may have excluded the relevant warnings, an audit only covers the routes it actually exercised, and a failure can happen before PHP writes anything. Use logs alongside a review of your configuration and application code, not instead of one.

7. Check your vendors 

Your exposure doesn't end at your own servers. Many vendors run PHP in their products and services, and some may be on end-of-life versions with no easy fix. Ask your critical vendors whether they run PHP, which versions and deployment types they use, and when they will patch. 

How UpGuard is helping its customers

UpGuard has added CVE-2026-109618 and CVE-2026-109619 as verified vulnerabilities in Breach Risk and Vendor Risk. Detection is based on the PHP version, so any domain or IP running an affected version gets flagged. 

We chose version-based detection because the PHP project says updating is the only reliable fix, and interim mitigations can’t be reliably observed from outside a server. Security teams can see where their organization and their vendors are potentially exposed, and prioritize patching and remediation requests.

Don't delay, respond now

PHP2Shell combines unauthenticated remote code execution, a version range that includes end-of-life releases with no easy fix, and a disclosure that gave attackers a head start. There's no confirmed exploitation in the wild yet, but proof-of-concept code is already public, and that window may not stay open for long.

Start with your own systems. Find every PHP instance, prioritize mod_php and other internet-facing deployments, and update to a fixed release. Where you can't update immediately, apply the interim mitigations in the PHP project's advisory to buy time, without treating them as a fix. Then look beyond your own perimeter, and find out which of your vendors run PHP and when they plan to patch.

Want to see how UpGuard tracks emerging vulnerabilities across your attack surface and supply chain? Book a demo.