Keep Calm and Patch PHP2Shell

Q: How do I patch PHP2Shell?

Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Source downloads are available on php.net, and Linux distributions and LTS vendors received patches in advance. After updating, restart PHP-FPM, Apache modules, and all long-running PHP processes such as queue workers and schedulers; these continue running the old binary until restarted. Container images must be rebuilt and redeployed with the patched PHP version. Confirm the fix through package changelogs or vendor advisories rather than version strings, since distributions often backport fixes without changing the upstream version number.

October 21, 2026
Justin Timothy
With contributions by the GuidePoint Security GRIT team

BLOG

10 min.

How to Respond to CVE-2026-109618 and CVE-2026-109619

*Note: This is an actively developing situation and the information from this blog is accurate as of writing. Please refer to PHP’s official guidance for any newly released information and additional patching and mitigation recommendations.

The newly released ‘PHP2Shell’ vulnerabilities have become a hot topic hitting the desks, feeds and wires of every cybersecurity professional around the world. Starting October 20th, leaked details, disputed PoCs, conflicting exploitation reports and a patch that was scheduled but not yet released started circulating among security professionals online.

TL;DR – LPHP2Shell is a critical, highly exploitable set of two vulnerabilities that could potentially affect a massive percentage of internet facing websites. The patch is available and the time to patch is now.

CVE-2026-109618 and CVE-2026-109619, collectively nicknamed “PHP2Shell”, are critical severity vulnerabilities that require immediate attention.
Patches are available for supported versions of PHP. PHP supplied Linux distributions and LTS vendors the patches in advance. Experts recommend isolating or decommissioning systems running versions older than 7.4.
It’s important to patch internet-facing systems first, rebuild containers that contain PHP, restart all affected systems after patching and conduct retrospective threat hunts to ensure no threat actors slipped through before the patches were applied.

The instinct during these types of high-impact vulnerability disclosures is to either panic or wait for certainty. Panic can lead to uncoordinated patching and inconsistent workarounds. Waiting means the exploit code is circulating before you hit your change window.

It wasn’t until PHP released their official post announcing the two CVEs and the mitigation options that the world was able to definitively understand the impact and start implementing patch management strategies.

This is why a balanced approach works best: act on what’s confirmed, prepare for what’s coming and make deliberate decisions about the tradeoffs you’re accepting.

What We Know About PHP2Shell

All PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are affected by these vulnerabilities. PHP considers the risk highest for mod_php, where the demonstrated exploit achieves unauthenticated remote code execution before application code runs. Both CVEs have been rated CVSS 9.2 (Critical) under CVSS v4.0 by PHP.

CVE-2026-109618: RCE via OOM Corruption

PHP handles out-of-memory (OOM) conditions, unwinding straight out of the current execution context and aborting the request. In certain early-request contexts, request-scoped memory is reachable before it has been fully initialized.

If any allocation fails in that window, the non-local exit skips the initialization and PHP’s error path does not account for the half-built state. The request shutdown routine then reads or branches on that memory. The failing allocation does not need to be related to the corrupted memory, so the trigger is generic: any OOM during the window is enough.

Several OOM-induction strategies trigger it consistently, which makes exploitation reliable and leads to Remote Code Execution (RCE).

CVE-2026-109619: RCE Via Stale Global State

PHP workers are long-lived and reused across requests and they keep some global state (error, session, object and extension data) that points to memory belonging to a single request. That state should be cleared before the request’s memory is freed. A fatal error can stop an operation before it cleans up.

Examples include running out of memory, hitting the execution time limit or a failed compile. A later warning during shutdown can also refill error state that was already cleared. The request’s memory is then freed while the worker still points to it, which is a use-after-free. When the same worker handles its next request, early steps that run before normal setup (input, configuration, session and error handling) can read, free or act on that stale pointer.

With a carefully crafted memory layout, an attacker can turn this into RCE, meaning they run their own code on the server. Exploitation takes two separate HTTP requests handled by the same worker: the first leaves stale state behind and the second uses it.

PHP2Shell encompasses two critical-severity vulnerabilities in one of the most widely deployed server-side runtimes on the internet. A patch has now been made available and we encourage all organizations to patch where possible.

Why PHP2Shell Deserves Your Attention

Not every vulnerability warrants immediate attention; however, this one does. The characteristics, including the potential impact and the exploitability demand quick action.

The parsing layer is the attack surface: Initial reporting indicates that the PHP2Shell vulnerability triggers during multipart/form-data parsing, before your application code executes. CMS maintenance modes, security plugins, authentication layers… none of it matters once it’s under attack. The request body gets parsed by PHP itself and that’s where the flaw lives.
The affected footprint is potentially enormous: PHP powers a significant portion of global websites with their server-side language. It’s embedded in WordPress, cPanel, WHM, Laravel-based internal tools, hosting panels, appliances and countless containerized microservices. Many organizations running PHP don’t think of themselves as PHP shops.
End-of-life PHP versions won’t get a fix: PHP 8.1 and earlier are considered end-of-life by the vendor. Any system running a legacy PHP version will not receive an official patch. If the claims about the vulnerability affecting versions as far back as PHP 5, many systems may face the need for rapid upgrade or decommissioning to ensure security.
The exploit interest is high and the details are public: The advisories are linked, the root causes are documented and the confirmed attack paths are described. The window between “patch available” and “weaponized exploit code circulating” is narrowing. We know from experience that threat actors weaponize large scale, public exploits within 24-48 hours of their disclosure.

How to Patch PHP2Shell

PHP has released the following versions that have addressed the vulnerabilities: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 and PHP 8.2.35.

Source downloads are available on php.net. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.

Patching alone does not fully mitigate the possibility of exploitation. Keep in mind exploitability and follow this recommended execution sequence to reduce the highest risks first:

Patch internet-facing systems first: With systems that face the internet, the attack surface is remote and unauthenticated. Internet-facing PHP hosts are the front line. Secure them before all others to close the widest gap.
Confirm the fix through package changelogs, not version strings: Distributions frequently backport security fixes without changing the upstream version number. A system reporting PHP 8.4.26 might already contain the fix if the distribution backported it. Check the package changelog or the distribution’s security advisory for confirmation.
Restart everything: Patching the binary on disk doesn’t protect running processes. Restart PHP-FPM, Apache modules and every long-running PHP process. This includes queue workers, schedulers and daemons. Without a restart, these processes continue running the old, vulnerable binary.
Rebuild and redeploy container images: If PHP runs in containers, updating the host package isn’t enough. Rebuild images with the patched PHP version and redeploy. Every running container based on the old image remains vulnerable.
Watch your distribution’s timeline: Not every package repository will have the fix today. The volunteer-run Remi repository (widely used on RHEL-based servers) will not publish updates on October 21st. PHP’s advisory urges Remi users to switch to distribution packages or build from source so the fix can be applied immediately.

What to Do If You Can't Patch PHP2Shell Immediately

PHP’s guidance is clear: the only complete solution is an update.

PHP has published specific interim measures that reduce exposure to confirmed attack paths. These mitigations are not equivalent to patching. They mitigate the risk of exploitation, but they do not eliminate it completely.

The multi-part rejection workaround remains valid as an additional layer for both CVEs. Rejecting requests whose Content-Type contains multipart/form-data at the web server, before they reach PHP, is still a strong stopgap. Cover all HTTP methods, not just POST (PHP 8.4+ parses multipart bodies on other methods) and apply it to every virtual host and default server that passes requests to PHP. This breaks file uploads until removed.

For CVE-2026-109618 (OOM corruption):

Set memory_limit=-1, preferably in a way applications can’t override (e.g., php_admin_value in the FPM pool or Apache configuration). Verify that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don’t require file uploads, post_max_size = 8M. If file uploads are necessary, post_max_size = 32M. Keep upload_max_filesize below post_max_size. Enforce limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause vulnerable allocation failure.

For CVE-2026-109619 (stale global state):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. The setting needs to take effect before the parser runs.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.

The Systems That Won't Get an Official Fix (But Might Get Help)

PHP 8.1 and earlier are end-of-life, so normally, those versions would not receive updates. Notably, PHP published minimal source-backports for PHP 7.4, 8.0 and 8.1 to help organizations building from source or without access to an LTS vendor. This is not a full-support commitment. However, it is a valuable lifeline for teams that can compile from source and need to close the gap.

For systems that can’t be patched or compiled from backports (and especially for anything older than 7.4) the guidance from multiple regulatory boards and industry experts stands: isolate internet-facing PHP systems from public networks or take them offline entirely. That’s a hard conversation for teams running legacy applications on unsupported PHP versions and it’s a conversation that needs to happen today.

With a widely available patch for supported versions and the lifeline thrown for some legacy code, threat actors will weaponize these exploits against unpatched and end of life systems.

After Patching: Hunt Backwards

Patching closes the door, which reduces your risk going forward. However, it doesn’t guarantee that a threat actor wasn’t able to slip through the cracks while you were busy patching. A retrospective threat hunt based on these behavior signals can help you eliminate the possibility of infiltration:

PHP worker child processes spawning shells or download utilities (PHP-FPM, Apache or other PHP workers)
Unexplained worker crashes or segmentation faults in PHP-FPM and web server logs (plausible side effects of memory-corruption exploitation attempts)
Unusual multipart/form-data requests from October 20th, 15:00 UTC onward, particularly to endpoints that don’t accept uploads
New or modified files in web roots, upload directories, plugin directories and mu-plugins
Changes to .user.ini files or the auto_prepend_file setting
Persistence indicators: new cron entries, systemd units, Supervisor entries, SSH authorized_keys additions, newly created application admin accounts or unexpected outbound connections from PHP service accounts

A clean result doesn’t rule out compromise, but it does indicate that the available behavioral indicators didn’t fire. That’s a meaningful data point. That said: preserve your logs. Web server and PHP logs from October 20th, 15:00 UTC onward are your forensic baseline. Log rotation, redeployment and container rebuilds can destroy the evidence needed for a compromise assessment. Back them up before patching changes anything.

Stay Tuned for Updates

GuidePoint Security’s GRIT team is actively tracking PHP2Shell and its impact. We will provide updated advisories, emerging exploit techniques and confirmed indicators of compromise as they become available. If PHP workers are spawning shells, unexpected files appear in web roots or you discover persistence mechanisms on a PHP host, the GuidePoint Security Incident Response team is ready to help.

FAQs

What is PHP2Shell?

PHP2Shell is the collective name for two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) disclosed on October 20, 2026. Both are rated CVSS 9.2 (Critical) and can allow unauthenticated remote code execution on PHP web servers. CVE-2026-109618 exploits out-of-memory corruption during request processing and CVE-2026-109619 exploits stale global state that persists across requests within the same PHP worker process.

What PHP versions are affected by PHP2Shell?

All PHP installations serving web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk configuration. Patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are end-of-life and will not receive official patches, though PHP published minimal source-backports for PHP 7.4, 8.0 and 8.1. Unconfirmed reports indicate the vulnerabilities may affect versions as far back as PHP 5.

How do I patch PHP2Shell?

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are available on php.net and Linux distributions and LTS vendors received patches in advance. After updating, restart PHP-FPM, Apache modules and all long-running PHP processes such as queue workers and schedulers; these continue running the old binary until restarted. Container images must be rebuilt and redeployed with the patched PHP version. Confirm the fix through package changelogs or vendor advisories rather than version strings, since distributions often backport fixes without changing the upstream version number.

What should I do if I can't patch PHP2Shell immediately?

PHP’s official position is that only a full update is a complete solution. Interim measures that reduce exposure include: rejecting requests whose Content-Type contains multipart/form-data at the web server before they reach PHP (covering all HTTP methods, not just POST); setting memory_limit=-1 to remove the controllable OOM trigger for CVE-2026-109618; and setting session.upload_progress.enabled=0 for CVE-2026-109619. For systems running PHP 8.1 or earlier that cannot be patched or compiled from PHP’s source-backports, the recommended action is isolation from public networks or taking them offline.

How do I detect PHP2Shell exploitation on my servers?

As of October 21, 2026, no vendor-published indicators of compromise exist yet, so detection relies on behavioral hunting. Look for PHP worker processes spawning shells or download utilities, unexplained worker crashes or segmentation faults in PHP-FPM and web server logs, unusual multipart/form-data requests (especially to endpoints that don’t accept uploads) from October 20, 2026 onward, new or modified files in web roots and upload directories, changes to .user.ini files or auto_prepend_file settings and new persistence indicators such as cron entries, SSH authorized_keys additions or unexpected outbound connections. Preserve web server and PHP logs from October 20 onward before patching or redeploying.

Justin Timothy

Justin Timothy is a Principal Consultant on GuidePoint Security’s Research and Intelligence Team (GRIT), where he focuses on threat intelligence research, incident response investigations and reporting to support clients across various industry verticals. Before joining GuidePoint, Justin worked on the Malware and Cyber Threats team at the National Cyber-Forensics and Training Alliance. While there, he focused on threat intelligence collections, malware analysis and supporting clients’ cyber threat intelligence teams. Justin holds a Bachelor of Science in Computer Science from Seton Hill University.