Updated 21 October 2026, 15:54: PHP has released fixes and published full advisories. This article has been revised with the official details. Earlier updates are listed in the update log at the end.

Two critical remote code execution (RCE) vulnerabilities in PHP, known as PHP2Shell, have been confirmed and patched by the PHP development team. Tracked as CVE-2026-109618 and CVE-2026-109619, both are rated Critical with a CVSS v4.0 score of 9.2.

The flaws allow unauthenticated attackers to execute code on vulnerable PHP servers. Details leaked online on 20 October, ahead of coordinated disclosure, and PHP published its advisories and fixed releases on 21 October 2026 at 14:00 UTC.

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now. Updating is the only complete fix, although several mitigations can help to reduce the potential risk until patches have been installed.

Exploitation Status

Exploitation has been reported in the wild. watchTowr reports observing exploitation attempts against its honeypot network, and Sansec reports that technical write-ups and exploit tooling are publicly available. Mass exploitation should be expected.

We are not linking to any exploit code.

Who Is Affected

The advisories identify PHP installations serving web requests as potentially at risk, including:

Apache mod_php: highest risk. A single unauthenticated request can trigger exploitation before any application code runs.
PHP-FPM: also at risk. The CVE-2026-109619 session path has been validated against PHP-FPM with a normal dynamic pool.
FrankenPHP: likely susceptible, as it handles request shutdown in a similar way to mod_php.
php-cgi and LiteSpeed (LSAPI): potentially susceptible, depending on configuration.

PHP2Shell is a flaw in the PHP runtime itself, not in any particular application. WordPress, Drupal, Joomla, Magento and custom PHP applications are all exposed if they run on an affected PHP installation. Sansec reports confirmed unauthenticated RCE against Magento and several other widely used PHP applications.

Affected Versions

The PHP advisories list the following affected and fixed versions:

Branch	Affected	Fixed
8.5	< 8.5.12	8.5.12
8.4	< 8.4.27	8.4.27
8.3	< 8.3.36	8.3.36
8.2	< 8.2.35	8.2.35
8.1 and older	All	No official release; source backports for 7.4, 8.0 and 8.1

Researchers report that versions as far back as PHP 5.4 are affected.

PHP 8.1 and older are end-of-life and do not receive official releases, but the PHP security team has provided minimal source backports for PHP 7.4, 8.0 and 8.1. Linux distributions and long-term support vendors may also ship patched packages, so check your operating system or hosting provider's advisories before assuming no fix exists. Where no suitable update is available, prioritise upgrading to a supported PHP version.

Technical Details

The two vulnerabilities have different root causes, but both can lead to remote code execution as the web worker account.

CVE-2026-109618: RCE via out-of-memory corruption

When PHP runs out of memory, it abandons the current operation immediately. In some contexts, this can happen while internal request data is only partially initialised. The request clean-up process then treats that invalid data as valid, which an attacker can turn into code execution.

An attacker can deliberately trigger memory exhaustion through multipart request parsing, for example with requests carrying very large numbers of part headers or nested empty file fields, while staying within PHP's apparent size limits. Application-specific inputs that cause large allocations can have the same effect.

PHP has validated a complete unauthenticated exploit against Apache mod_php with default input and memory limits. On mod_php, the whole attack happens during request start-up, before application code runs. Source analysis indicates that PHP-FPM and other server APIs are also susceptible, although no complete exploit has been demonstrated against them for this CVE.

CVE-2026-109619: RCE via stale global state

PHP workers keep some global state between requests. In certain cases, that state still points to memory belonging to a previous request after the memory has been freed. If the same worker handles another request, PHP can read that stale state before normal initialisation resets it, resulting in a use-after-free that a carefully prepared heap layout can turn into RCE.

PHP has confirmed two exploitation paths:

Fatal error backtraces (PHP 8.5): with fatal_error_backtraces enabled, backtrace state is never correctly reset. This is the strongest demonstrated case and the basis of the confirmed mod_php exploit.
Session upload progress: this feature is enabled by default and does not require the application to call session_start(). RCE through this path has been validated against both mod_php and PHP-FPM.

Other request state may also be exploitable depending on the application, its extensions and the server configuration.

Successful exploitation of either vulnerability lets an attacker run commands with the privileges of the PHP process. Depending on the environment, this could lead to website compromise, unauthorised database access, web shell deployment, or access to connected systems.

Mitigation

Updating to a PHP release containing the security fixes is the only complete mitigation.

Apply the security update: install the fixed PHP release or a vendor-provided backport. Prioritise internet-facing systems.
Verify the running version: confirm that the PHP actually serving web requests has been updated. php -v reports the command-line binary, which may differ from the version used by PHP-FPM or mod_php. Restart PHP-FPM, Apache and containers after updating, and check provider-managed environments separately.
Check unsupported installations: identify end-of-life PHP versions and confirm the remediation path with your vendor or internal team.
Reduce exposure if patching is delayed: restrict access to affected applications or temporarily isolate them from public networks, in line with CERT-EU's guidance.
Check for compromise after patching: because exploitation was reported before and during the patch window, review recently exposed systems using the detection guidance below.

Pre-Patch Mitigation

Note

These measures reduce exposure to specific, confirmed attack paths. They do not make an affected installation safe and must not be used in place of patching. Consult the official advisories for exact conditions before changing production systems.

CVE-2026-109619 configuration

Disable session upload progress and, on PHP 8.5, fatal error backtraces. Set these in php.ini, the PHP-FPM pool configuration or the Apache server configuration, so that they apply before request parsing:

session.upload_progress.enabled = 0
# PHP 8.5 only
fatal_error_backtraces = 0

Restart every PHP worker afterwards. These settings block the two confirmed paths but not every possible variant.

You may also want to keep upload progress disabled after patching if your applications do not use it. PHP's advisory notes that this little-used feature is likely to attract further attention from attackers.

Other steps from the advisory that reduce the remaining risk:

Error suppression does not protect you. Changing error_reporting, using @, or disabling display_errors or log_errors has no effect on this vulnerability.
Remove per-request INI overrides that produce warnings. Invalid or deprecated settings applied through .htaccess (php_value/php_flag) or FastCGI PHP_VALUE parameters can act as a trigger. Move settings into php.ini or the FPM pool configuration and remove obsolete directives.
Eliminate fatal errors and timeouts on attacker-reachable routes, including upload, import and error-page handlers.
Consider pm.max_requests = 1 for PHP-FPM if performance allows. This recycles each worker after one request so stale state cannot carry over.

CVE-2026-109618 configuration

PHP's primary configuration mitigation is to enforce an unlimited per-request memory limit, which removes the predictable out-of-memory condition the confirmed exploit relies on. It must be enforced administratively so that applications cannot set it back with ini_set():

# PHP-FPM pool configuration
php_admin_value[memory_limit] = -1

# Apache mod_php (virtual host or server configuration)
php_admin_value memory_limit -1

Restart every PHP worker and confirm that no pool, directory or application setting restores a finite limit.

This is not a complete fix, and it removes PHP's protection against runaway memory use. Assess the resource-exhaustion impact before applying it, and pair it with the following:

Keep post_max_size conservative and enforce request body size limits at the reverse proxy or web server.
Reduce max_input_nesting_level and bound max_input_vars, max_multipart_body_parts and max_file_uploads.
A container or cgroup memory limit can act as an outer safeguard, but it may kill every worker at once and is not a complete mitigation.
Do not use RLIMIT_AS or RLIMIT_DATA (for example via ulimit -v) to cap memory. These cause allocations to fail in a way that triggers the vulnerable code path.

Blocking multipart POST requests

If your applications do not need multipart form submissions, PHP's advisory recommends blocking them before they reach PHP. This reduces exposure to the multipart-based attack paths.

These rules block legitimate multipart requests too, including ordinary HTML forms with file inputs and file uploads. They also rely on the declared Content-Type header rather than the request body. Test them before deploying to production.

Nginx

Add a map directive within the http context:

# Nginx http {}
map "$request_method:$http_content_type" $block_upload {
    default 0;
    ~*^POST:multipart/form-data 1;
}

Add the following ahead of any location blocks in the relevant server configuration:

# Nginx server {}
if ($block_upload) {
    return 403;
}

Test the configuration with nginx -t, then reload nginx.

Apache

This rule works in .htaccess or a virtual host when mod_rewrite is enabled:

# Apache
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST [NC]
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F,L]

Test the configuration with apachectl configtest, then reload Apache.

Cloudflare WAF

If you use Cloudflare, you can deploy the following expression with a Block action, instead of or in addition to the rules above:

(http.request.method eq "POST") and
any(http.request.headers["content-type"][*] contains "multipart/form-data")

Detection and Monitoring

Review PHP and web server logs for unusual requests, and investigate unexpected activity from PHP worker processes such as php-fpm and php-cgi, and web server processes such as httpd and apache2.

Pay particular attention to:

PHP or web server processes spawning shells, scripting interpreters, download tools or networking utilities.
Unexpected file creation in web-accessible directories, including new web shells.
Unexplained changes to application files or server configuration.
Suspicious database access, outbound connections or new scheduled tasks.

PHP's advisory also highlights log entries worth reviewing:

Warnings, deprecations or core errors repeated before scripts run.
Fatal, parse and uncaught errors, especially on upload, import or error-handling routes.
Maximum execution time exceeded errors.
Worker crashes or segmentation faults in the PHP-FPM or Apache error logs.

These are general defensive recommendations rather than confirmed PHP2Shell-specific indicators of compromise. The absence of these signs does not prove a system has not been exploited, and historical logs may have excluded the relevant error levels.

If you find suspicious activity, isolate the affected host where appropriate, preserve PHP and web server logs, and investigate for unauthorised files, scheduled tasks and accounts. If compromise is suspected, assess whether credentials, application secrets or database access may have been exposed, and rotate them from a trusted environment after containment.

Official Advisories

The PHP advisories contain the full technical details and mitigation guidance:

Also monitor advisories from your operating system vendor and hosting provider, as packaged updates and backports may be released on their own schedules.

Update Log

21 October 2026, 15:54

PHP has published its security advisories and fixed releases. This article has been revised with the official technical details, affected versions and mitigations. Exploitation in the wild has been reported.

21 October 2026, 12:24

The pre-patch mitigations were reported as not being a complete fix and should not be relied on alone.

21 October 2026, 10:00

A proof-of-concept exploit was published online, although its validity had not been confirmed at the time. We will not be linking to any PoC code. We also added several pre-patch mitigation options. These were speculative and entirely reversible, and were recommended as a precaution.

References

Adam Govier Founder & Lead Consultant

OSCP OSCE

Adam founded Exploitr and leads its penetration testing practice. He holds OSCP and OSCE certifications and has over 12 years' experience in penetration testing and security consulting.

PHP2Shell Remote Code Execution (CVE-2026-109618, CVE-2026-109619)