PHP2Shell: Critical PHP RCE Flaws (CVE-2026-109618 & CVE-2026-109619) Explained

Sıla Özeren Hacıoğlu | 10 MIN READ

| October 21, 2026

PHP shipped an out-of-cycle security release on October 21, 2026, for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which its security team rated CVSS v4.0 9.2 (Critical). The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Researchers call the pair php2shell. Both are unauthenticated remote code execution flaws in PHP’s core, and the release was pulled forward a day after details leaked ahead of the embargo. PHP is explicit that there is no complete mitigation: updating is the only safe choice.

This post explains what PHP’s advisory confirms about CVE-2026-109618 and CVE-2026-109619, why this bug class is dangerous, and, at a conceptual level, how the flaws work, without providing anything that helps weaponize them. If you run PHP anywhere, the affected-assets table and the mitigation steps are the parts to act on now.

How the php2shell PHP vulnerabilities leaked before the patch

On October 20, a now-deleted post on a public tech forum claimed two PHP RCE flaws were headed for disclosure on October 22, scored them CVSS 10.0, and said they hit every version from PHP 5 onward, on nothing more than “source: trust me, bro.” Screenshots spread before the post was pulled, and within hours researchers confirmed the flaws were real and under embargo. PHP responded that evening with an advance notice, pulling its release forward a day to October 21 and reserving the right to ship sooner if details leaked further or exploitation appeared. The fixes landed slightly ahead of the 14:00 UTC schedule.

One thing the leak did not carry was how the flaws actually work. And the widely-shared “10.0” severity was the leaker’s guess; PHP’s own rating is 9.2.

What kind of bugs are these: two memory-safety flaws in PHP core

PHP’s advisory describes two distinct vulnerabilities, not one bug with two numbers. Both sit in PHP’s core, both can be reached by an unauthenticated web request, and both end in remote code execution, but they live in different places and work in different ways.

CVE-2026-109618 RCE via OOM corruption

In vulnerable PHP versions, an out-of-memory (OOM) error can trigger longjmp(), abruptly interrupting request processing while internal request data is only partially initialized. Request cleanup may then act on that invalid data, potentially enabling remote code execution. The confirmed mod_php attack occurs before application code runs; other server interfaces can have different attack prerequisites.

PHP’s technical advisory describes the OOM-handling mechanism and several ways multipart parsing can exhaust memory, alongside application-dependent triggers. Its interim guidance includes limits on decoded request size, input field count, multipart part count, headers within each part, and nesting depth. Administratively enforcing memory_limit=-1 removes the predictable PHP memory-limit trigger, but underlying allocation failures can still reach the vulnerable path. These measures reduce exposure; updating PHP is the only complete mitigation.

CVE-2026-109619 RCE via stale global state

A PHP worker handles many requests in a row. Internal state belonging to one request can survive after the memory behind it has been freed; a later request on the same worker may then use that stale state before normal initialization resets it.

PHP confirms paths in two areas: session.upload_progress, and on PHP 8.5 the fatal error backtrace feature. It is explicit that these are not the only ones: disabling upload progress “blocks the confirmed session paths but not other variants,” and the advisory also points to per-request INI settings that emit diagnostics before normal request initialization, and to fatal errors and execution timeouts an attacker can trigger.

The stale state is consumed at the start of a request, but it can be created by something that happened in an earlier one, including a fatal error or timeout inside application code, which is why PHP’s advice includes fixing those, not just changing ini settings.

The attack surface: which PHP deployments are at risk

Two things make these critical rather than routine.

First, they are in PHP core, not in any one application. The same interpreter runs WordPress, Drupal, Joomla, Magento, and countless custom apps, so a single flaw has an enormous blast radius.
Second, no authentication is needed. PHP’s advisory rates the risk highest for mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

PHP’s advisory covers all PHP installations serving web requests, and names these examples:

PHP-FPM Apache mod_php · highest risk php-cgi FrankenPHP LiteSpeed

This is not tied to one server setup or one application; the flaw is in the interpreter itself. A plugin bug affects the sites using that plugin. The vulnerabilities affect PHP itself rather than a specific application. Exploitability varies by deployment, but all unpatched installations serving web requests should be updated.

The attacker controls the whole request, so no real upload form, upload page, or login is required.

Which PHP versions are affected by php2shell (and which get a fix)

PHP ships source releases (plus Windows binaries) for its four supported branches, 8.2 through 8.5; Linux packages come from the distributions, which received the patches in advance. For end-of-life branches it took the unusual step of publishing minimal source backports for PHP 7.4, 8.0, and 8.1, but there are no releases for those, so anything older than 8.2 needs a backported package from your distribution or LTS vendor, a rebuild from the source backport, or an upgrade.

PHP branch	Status	Fix	Action
8.5	Active support	8.5.12	Update now
8.4	Active support	8.4.27	Update now
8.3	Security fixes only	8.3.36	Update now
8.2	Security fixes only (EOL Dec 31, 2026)	8.2.35	Update now
8.1	End of life (since Dec 31, 2025)	Source backport only	Rebuild or upgrade
8.0	End of life	Source backport only	Rebuild or upgrade
7.4	End of life	Source backport only	Rebuild or upgrade
7.x (other) / 5.x	End of life	No PHP project backport announced	Upgrade or isolate

The harder problem is where PHP hides:

Asset class	Examples	Why it’s at risk
CMS platforms	WordPress, Drupal, Joomla, Magento	Internet-facing, PHP by default
Hosting and panels	cPanel, Plesk, shared hosting	Many PHP versions side by side, often EOL
Vendor appliances	Appliances bundling PHP	Hidden inside, easy to miss in inventory
Windows software	Apps shipping php.exe / php-cgi.exe	Not obviously “a PHP server”
Internal tooling	Dashboards, legacy intranet apps	Frequently unpatched, frequently EOL

One rapid-response scan counted roughly 884,000 internet-facing hosts reporting PHP 8.1 or older on October 20, about 59% of the ~1.5 million that reported any version, with a further 740,000 reporting PHP with no version at all. These are banners, not confirmed-vulnerable systems, but they map the scale.

One trap worth noting: a version check on a workstation can show a patched build while the PHP-FPM pool serving production runs a different, vulnerable binary, so check what each site actually executes.

How to detect php2shell exploitation: watch what PHP spawns

Confirmed mod_php attacks can occur before application code runs. Other attack paths can depend on application execution, configuration, and the PHP SAPI.

Detection has to sit below the app: in worker behavior, error logs, and request shape.

1. Pre-exploitation indications (catch failed attempts too)

Worker crashes: bursts of SIGSEGV/SIGABRT in php-fpm logs, “Segmentation fault” in Apache error logs, php-cgi/FrankenPHP/LiteSpeed worker respawns.
Startup OOMs: Allowed memory size exhausted ... in Unknown on line 0. OOM errors reported as ‘Unknown on line 0’ warrant investigation, but are not specific to php2shell exploitation.
Request shape: huge or deeply nested POST/multipart bodies, thousands of fields or parts, chunked requests without Content-Length, PHP_SESSION_UPLOAD_PROGRESS sent to endpoints that never use it.

2. What PHP spawns

Parents to watch: php-fpm (match by prefix — Debian/Ubuntu use php-fpm8.3 etc.), php-cgi, httpd/apache2 with mod_php, lsphp, frankenphp; on Windows php-cgi.exe or httpd.exe. Alert when they launch:

Shells: sh, bash, dash; cmd.exe, powershell.exe, pwsh.exe
Interpreters: python, perl, ruby, php (CLI from a web worker is unusual)
Network tools: curl, wget, nc, ncat, socat; certutil.exe, bitsadmin.exe
Recon: whoami, id, uname, hostname; ipconfig, systeminfo
Reverse-shell patterns: /dev/tcp/, mkfifo, bash -i, nc -e, base64 -d | sh

Two caveats: baseline first (convert, gs, git, wkhtmltopdf are often legitimate), and combine contextual command-line monitoring with web-shell scanning and runtime telemetry.

3. How to get the telemetry

Linux: auditd execve rule on the web user’s uid, e.g.

-a always,exit -F arch=b64 -S execve -F euid=33 -k php_exec

or Falco/Tracee/Sysmon for Linux. Windows: Sysmon Event ID 1 filtered on ParentImage. Also log outbound connections from the web uid -- a native-code payload can open a socket without ever spawning a shell. Forward logs off-host; an attacker may tamper with locally stored logs where the compromised account has sufficient permissions.

php2shell mitigation: the patch, and what to do after it

PHP’s advisory lists interim settings for installs that cannot update today. They reduce exposure to specific paths, but PHP is explicit that none of them make an installation safe. treat them as temporary exposure-reduction measures, and update as soon as possible.

The patch itself

Install 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or your distro’s patched package (distros were pre-notified).
Remi: no update today. Switch to distro packages or build from source.
7.4 / 8.0 / 8.1: apply your LTS vendor’s backport or the PHP security team’s minimal source backport, then plan the upgrade.
Restart affected services, or use a verified reload procedure that replaces the PHP binary and every worker.
Verify the PHP runtime serving each site through a protected diagnostic endpoint, and confirm the installed package includes both fixes. A command-line version check alone is insufficient.

After the patch

If you applied PHP’s interim settings while waiting (memory_limit=-1, a low post_max_size, session.upload_progress.enabled=0, fatal_error_backtraces=0 on 8.5), roll back the ones that hurt you: restore a sane memory_limit (unlimited is a DoS risk), restore post_max_size to what the app needs, re-enable upload progress and backtraces only if you actually use them. Keep any proxy-level request limits you added; they’re good hygiene.
Assume the window was open. Patching doesn’t evict anyone who got in first. Check: new or modified .php files in web roots and upload dirs, unexpected cron jobs, processes and users, outbound connections from the web user, the crash/OOM log patterns above. If anything looks off, rotate every secret the web user could read (DB creds, API keys, app keys, session secrets).
Keep the process/crash monitoring running permanently; it’s cheap.
Plan the next moves: 8.2 is EOL on 31 Dec 2026, so start the 8.4/8.5 migration now; get off 7.4/8.0/8.1 entirely; if you depend on a volunteer-run repo for updates, fix that dependency before the next advisory.
Watch php.net for a regression release. Same-day four-branch security builds sometimes need a follow-up.

How Picus helps you simulate and defend against php2shell attacks

We also strongly suggest simulating the PHP CVE-2026-109618 and CVE-2026-109619 (php2shell) vulnerabilities to test the effectiveness of your security controls against sophisticated cyber attacks using the Picus Platform. You can also test your defenses against other vulnerability exploitation attacks, such as regreSSHion, Citrix Bleed, and Follina, within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for php2shell (CVE-2026-109618 & CVE-2026-109619) exploitation attacks: