PHP2Shell (CVE-2026-109618 & CVE-2026-109619): What Happened, Who Is Affected and What to Do

Last updated: 4 November 2026 (CISA KEV listing on 26 October, confirmed exploitation, CVE-2026-115560 still unfixed). This is a fast-moving issue. We will update this page as vendors publish new information.

On 20 October 2026 the PHP security team warned of an emergency release for two critical flaws in PHP itself. Details leaked online the same day, and the patches shipped on 21 October, a day earlier than planned. Together the two bugs are known as PHP2Shell (also written php2shell). Both are rated 9.2 out of 10 (CVSS v4.0), and both can let an attacker run code on a web server without logging in.

Affected by this? Emergency exposure check, ₹2,999, 48 hours. Send us up to 5 hosts, sites or product versions. Within 48 hours you get a written verdict for each one, what to patch first and how to verify the fix. Book the check or ask a question first.

PHP runs roughly 7 in 10 websites whose server language is known, including every WordPress, Drupal, Joomla and Magento site. So this is one of the most widely relevant server bugs in years. This post explains what happened in plain language, who is affected and what to do first.

PHP2Shell in 30 seconds

• What: two memory-handling bugs inside the PHP interpreter, CVE-2026-109618 and CVE-2026-109619. They are not WordPress or plugin bugs.
• Impact: unauthenticated remote code execution (RCE), and memory disclosure that can leak passwords, tokens and API keys.
• Affected: PHP 8.2, 8.3, 8.4 and 8.5 before the fixed releases. Older branches back to PHP 5.4 contain the vulnerable code too.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or your Linux distribution’s patched package.
• Do now: update PHP and restart every PHP worker. If you can’t update today, apply the temporary settings below and limit public access.

What exactly are the two bugs?

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

While PHP sets up an incoming request, it builds internal data structures. If the process runs out of memory at just the wrong moment, those structures are left half-built. PHP’s cleanup code later treats the half-built data as valid, and a carefully crafted request can turn that into code execution. PHP confirmed full RCE over HTTP against Apache mod_php with default input and memory limits.

CVE-2026-109619: stale global state (use-after-free)

PHP keeps some request-specific state after the memory behind it has been freed. When the same worker process handles the next request, it can read that stale state before it is reset. This is a classic use-after-free. Researchers used it for memory disclosure and for RCE. One confirmed trigger path is the session upload progress feature, which is on by default, but researchers say it is not the only path.

Both flaws are reached before your application code runs, so a well-written WordPress or Laravel app does not protect you. The fix has to happen in PHP.

Timeline

Exploitation is confirmed. Amazon saw the first attempts on 17 October, four days before the patches. On 24 October a security researcher recorded 35 successful shell executions on honeypots running PHP 8.4.26 under Apache mod_php, from two IP addresses; the traffic matched CVE-2026-109618. TU Delft’s threat intelligence lab has tracked more than 50,000 exploitation requests from over 600 addresses in 70 countries, and 171 of those addresses sent exploit code or malware droppers. Two early claims were later withdrawn: Sophos revised its report to scanning and failed attempts, and Palo Alto Networks dropped the link it had drawn between the flaws and an intrusion at a European government agency. Treat it as actively exploited.

CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on 26 October and gave US federal agencies until 29 October to patch. The deadline only binds US agencies, but a KEV listing is the clearest public signal that a bug is being used in real attacks. If you have not patched yet, do it now, and start any investigation from 17 October, as Amazon recommends.

Which PHP versions and setups are affected?

Distribution packages can keep the old version number. Ubuntu 24.04, for example, fixed PHP 8.3 in package 8.3.6-0ubuntu0.24.04.13, which still reports itself as “8.3.6”. Hosting platforms do the same: CloudLinux’s patched alt-php85 8.5.11-5, for example, contains the fix but still reports 8.5.11. Always compare the full package version with your vendor’s advisory, not just php -v. Our step-by-step patching guide shows how.

Every way of running PHP for the web is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk, because the demonstrated exploit fires before any application code runs. PHP-FPM blocks one specific out-of-memory path at startup, but PHP still validated RCE against FPM, so FPM needs the update too.

What to do now (priority order)

1. Find every PHP install: web servers, containers, control panels (cPanel, Plesk), vendor appliances. The CLI php -v may not be the binary your web server uses.
2. Update to the fixed version for your branch, or to your distribution’s patched package.
3. Restart all PHP workers (PHP-FPM, Apache, LiteSpeed), then confirm the running version.
4. If you can’t patch today: set session.upload_progress.enabled = 0 at the server or pool level (not with ini_set()). On PHP 8.5, also set fatal_error_backtraces = 0. Restart workers. PHP lists more temporary measures, and none of them is a full fix.
5. Reduce exposure: put internet-facing sites behind a WAF (Cloudflare added free rules for known vectors), or restrict access until patched.
6. Look for signs of compromise from 17 October onwards: PHP processes starting shells or curl/wget, new PHP files in the web root or uploads, new cron jobs or admin accounts.

On shared or managed hosting you can’t patch PHP yourself. Your host has to. Our 15-minute checklist for WordPress and shared-hosting owners covers what you can check and what to ask your host.

Update 23 October: a related issue, CVE-2026-115560

Two days after the emergency release, PHP published an informational advisory for a third issue, CVE-2026-115560. PHP calls it an unlikely route to code execution, because it needs an unusual session setup. All of these must be true:

• session.serialize_handler is set to php_binary or php_serialize in the configuration,
• the application switches it to php with ini_set() before session_start(), and
• session upload progress is still enabled (the default).

The 21 October releases do not fix it. PHP will fix it in its next regular release, with a full advisory, and has given no date. No exploitation has been reported. Until then, PHP recommends session.upload_progress.enabled = 0, set at the server or pool level. That is the same setting already advised for CVE-2026-109619, so if you set it on 21 October, keep it and you need do nothing else. On shared hosting, ask your host whether they have applied it.

Update 4 November: PHP has not published a regular release since 21 October, so CVE-2026-115560 is still unfixed. The only new builds are the Windows rebuilds of 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1), which bundle Brotli 1.2.1 for CVE-2026-111497, an out-of-bounds write reachable through cURL’s automatic decompression. Keep upload progress off until the next release.

Is this the same as wp2shell?

No. wp2shell (CVE-2026-63030 and CVE-2026-60137, July 2026) was a WordPress core bug chain, fixed in WordPress 6.8.6, 6.9.5 and 7.0.2. PHP2Shell is a bug in PHP itself, so updating WordPress does not fix it. A site can need both fixes, but they are separate.

FAQ

Does a WAF or security plugin protect me?

A network WAF such as Cloudflare’s can block known exploit patterns and buys you time. A WordPress security plugin runs inside PHP, after the vulnerable code, so it cannot stop this bug. Only a patched PHP closes the hole.

Is changing php.ini enough?

No. PHP’s settings changes reduce known attack paths, but PHP and the researchers stress that updating is the only complete fix. Some sources say config changes alone are not a suitable mitigation at all.

How do I know which PHP version my site runs?

In WordPress, go to Tools → Site Health → Info → Server. On a server, check your package manager and the running FPM or Apache process, not just the CLI. Our free Website Safety Check tests HTTPS, headers and email security, but it cannot see your PHP version for you.

Need help?

We patch, harden and audit Linux and PHP servers for small businesses. If you aren’t sure your servers are patched, or you think one was attacked, see our Linux server hardening & audit and VAPT services, or contact us.

Related guides

• How to Audit Web Servers and Web Applications: Checklist
• Operating System Protection and Security: Threats and Defences
• The TCP/IP Model Explained: Layers, Protocols and Data Flow
• System Acquisition, Development and Maintenance: ISO 27001:2022 Secure Development Controls

Sources

• Qualys: PHP patches two critical RCE vulnerabilities
• Tenable: php2shell FAQ
• Huntress: Rapid response to php2shell
• watchTowr: PHP2Shell intelligence
• JFrog Security Research: All you need to know
• Help Net Security: PHP2Shell patched
• Ubuntu: php2shell fixes available
• CISA: Critical vulnerabilities in PHP require immediate patching
• AWS: php2shell exploitation seen before disclosure
• The Hacker News: PHP warns of CVE-2026-115560
• Red Hat bulletin RHSB-2026-013 (php2shell)
• CloudLinux: package status for hosting servers