PHP2Shell: Two Critical PHP RCE Flaws and How to Patch

6 min read · Last updated: October 24, 2026

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that let an unauthenticated attacker run code on a web server. The PHP project shipped emergency fixes on October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Update your branch and restart every PHP worker.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The announcement

• PHP.net news archive: advisory, patched releases and mitigations, Oct 20-23, 2026
• GitHub advisory for CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)
• GitHub advisory for CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)

The analysis

• watchTowr FAQ, updated Oct 23, 2026
• Akamai Security Intelligence, Oct 22, 2026

The receipts

• BleepingComputer, Oct 21, 2026
• Help Net Security, Oct 21, 2026
• VirusTotal exposure sizing, Oct 21, 2026

Key takeaways

• Two unauthenticated RCE bugs, both rated CVSS v4.0 9.2 by the PHP project.
• Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026.
• PHP says only an update is a complete solution. No config change makes you safe.
• Risk is highest on Apache mod_php, where an attack can land before any of your code runs.
• VirusTotal counted about 5.1 million internet-facing PHP hosts and about 758,000 on end-of-life branches that get no official fix.
• watchTowr reports exploitation in the wild since October 21, 2026.

What is PHP2Shell and what happened?

PHP2Shell is a nickname for two critical flaws in the PHP runtime itself. Both allow unauthenticated remote code execution, meaning a stranger can run commands on your server with the privileges of the web worker, without logging in. The PHP project rated each 9.2 on CVSS v4.0.

On October 20, 2026, PHP announced an out-of-band security release for October 21 at 14:00 UTC. It reserved the right to go earlier if details leaked or exploitation appeared. Details did leak ahead of the planned October 22 disclosure, per watchTowr. The patches shipped on schedule, and BleepingComputer credits Calif, OpenAI and Wiz with the discovery.

Why does PHP2Shell matter to a developer?

The bugs are in the PHP engine, not in your application. Clean code, a framework, and a WAF-free staging box do not change that. If PHP serves web requests on your server, you are in scope, whether that is WordPress, Laravel, or a ten-year-old script someone forgot.

Three facts make it urgent:

• Exposure is huge. According to VirusTotal's October 21, 2026 scan, about 5.1 million IPs fingerprint as PHP, and about 3.8 million have at least one open port.
• Exploitation is live. watchTowr reports in-the-wild exploitation since October 21 through its honeypot network. BleepingComputer reports that Amazon saw a honeypot exploitation attempt on October 17, four days before the patch, and that Cloudflare's CTO described early attacks.
• Many servers cannot self-update. VirusTotal found about 758,000 PHP hosts on end-of-life branches (5.4 to 8.1), including about 187,000 on PHP 7.4.

As of October 22, watchTowr noted that CISA had not added either CVE to its Known Exploited Vulnerabilities catalog.

Which PHP versions are affected and which are fixed?

Every PHP installation serving web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches get no official release, only minimal source backports for 7.4, 8.0 and 8.1.

Branch	Affected	Fix
8.5	below 8.5.12	8.5.12
8.4	below 8.4.27	8.4.27
8.3	below 8.3.36	8.3.36
8.2	below 8.2.35	8.2.35 (reaches end of life December 31, 2026)
8.6.0	earlier builds	8.6.0 RC4 contains the fixes
7.4, 8.0, 8.1	all versions	No official release. Use a distro or LTS vendor package, or PHP's minimal source backports
7.3 and older	all versions	No fix. Move to a supported branch

The sources are not fully uniform on very old versions. watchTowr says unsupported branches including PHP 5 are affected. Treat anything old as vulnerable.

How do the two PHP2Shell bugs work?

CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request. CVE-2026-109619 is a use-after-free in the file upload progress feature. Both leave PHP holding invalid internal data that an attacker can shape into a call to code of their choosing.

CVE-2026-109618 (out-of-memory corruption). Per Akamai, an attacker pushes memory use to the configured memory_limit. PHP then aborts with longjmp(), skipping normal cleanup and leaving half-built memory. During request shutdown, the engine reads forged structures. That is why mod_php is the worst case: the attack can happen before application code runs.

CVE-2026-109619 (stale global state). Per Akamai, the upload progress feature caches pointers into a session table. A later update frees the old table but keeps the old pointers. The attacker sprays the heap and writes through them. The feature, session.upload_progress.enabled, is on by default, and any endpoint that accepts uploads is reachable, even one that ignores them.

Do the workarounds protect you?

No. The PHP project states that only an update is a complete solution, and that its own mitigations do not make an installation safe. They shrink known paths while you schedule the patch. Apply them in php.ini or the FPM pool, not at runtime.

; php.ini or FPM pool config (applies before request parsing)
memory_limit = -1
post_max_size = 8M          ; 32M if you need uploads
upload_max_filesize = 8M    ; keep below post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0  ; PHP 8.5 only

Rules from PHP's advisory:

• Restart every worker after changing these.
• Do not rely on ini_set() or FPM .user.ini.
• Do not use RLIMIT_AS or RLIMIT_DATA as a substitute, because they can cause the vulnerable allocation failure.
• Hiding errors with error_reporting, display_errors or @ does not help. Hiding the version with expose_php = Off does not remove the flaw either, per VirusTotal.

What changes in practice after PHP2Shell?

Three things change. Patching PHP becomes a same-week task, not a quarterly one. Unsupported branches stop being a quiet risk and become a live one. And the story is not over: on October 23, php.net said a further advisory for CVE-2026-115560 will follow "with the next release" and suggested keeping session.upload_progress.enabled=0 until then.

If you run PHP in containers, an image rebuild is the patch. Our Docker explainer covers why rebuilding beats patching a running container. A base image that still ships an old PHP is just as exposed.

Also note where the bugs live. They are in the runtime's memory handling, which no review of your own code can catch. That is a limit of the habits in how to review AI-generated code: review your code, and still patch your dependencies.

What should you do this week?

1. Inventory every PHP install. Start with internet-facing hosts, and put Apache mod_php servers first.
2. Check versions. Run php -v on each host and compare with the table above. Do this for CLI and for the web SAPI, since they can differ.
3. Update to the fixed release for your branch, or install your distro's patched package. Check your vendor, since patches reached Linux distributions and LTS vendors before the public release.
4. Restart every PHP worker (FPM, Apache, LiteSpeed, FrankenPHP) so the fix takes effect.
5. Apply the ini mitigations on anything you cannot update today.
6. Isolate what cannot be fixed. The UK NCSC urges taking such systems offline. Restricting internet access is the minimum.
7. Plan the upgrade off 7.4, 8.0 and 8.1. PHP 8.2 itself reaches end of life on December 31, 2026.

Searchlight Cyber has released a scanner called php2shell-scanner that tests whether a host is exposed. Cloudflare has deployed temporary WAF rules for known exploit methods, but those are not a fix.

FAQ

Is PHP2Shell being exploited right now?

watchTowr reports exploitation since October 21, 2026, seen on its honeypot network. BleepingComputer reports Amazon saw an attempt on October 17. As of October 22, neither CVE was on CISA's Known Exploited Vulnerabilities list. Assume attackers are scanning.

Am I safe if I use PHP-FPM instead of mod_php?

No. PHP-FPM, php-cgi, LiteSpeed and FrankenPHP are all in scope. PHP considers mod_php the highest risk because an attack can succeed before any application code runs, but FPM still needs the update.

Does turning off upload progress fix it?

Only partly. Setting session.upload_progress.enabled=0 blocks the confirmed session paths for CVE-2026-109619. It does not cover CVE-2026-109618 and PHP says it does not block other variants. Patch the runtime.

Can I fix PHP 7.4 or 8.1?

The PHP project provides minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship backported fixes. There is no official release. If you have neither, move to a supported branch.

Patch first, then browse the free tools on Art of Code while the restarts run, and check the jobs board if your PHP estate suddenly needs more hands.

Written by Adithya Guttha, Founder of Art of Code.