top of page
Book a discovery call

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): What It Is, Who Is Affected and How to Fix It

Alekh & Jasleen
9 hours ago
7 min read

Quick answer: PHP2Shell is the nickname for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, each scored 9.2 out of 10 (CVSS v4.0). They can let an unauthenticated attacker run code on a server that serves PHP web requests. PHP released fixes on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and attacks have already been observed. The only complete fix is to update PHP and restart every PHP worker, because PHP says there is no complete mitigation [1][7].



What is PHP2Shell?

PHP2Shell is the name that stuck to two related flaws in the PHP interpreter after details and a working proof of concept leaked on 20 October 2026, a day before the planned release [8][10]. PHP's own advisories refer to them only by CVE number [6].


CVE-2026-109618 is remote code execution through out-of-memory corruption. When PHP runs out of memory in the middle of a request, it can be interrupted while internal request data is only partly set up, and the cleanup that follows can treat that broken data as valid [8][10]. CVE-2026-109619 is remote code execution through stale request-owned global state: a request that dies at the wrong moment can leave state behind in a PHP worker, and a later request handled by the same worker can read it after it has been freed [3][8].


Both flaws are reached while PHP is parsing an incoming request, before any application code runs [8]. Datadog's researchers reproduced them independently and confirmed that application-level authentication cannot block an attack, because PHP processes the malicious request before the application sees it [7].


Is PHP2Shell being exploited?

Yes. ELLIO's sensors recorded the first PHP2Shell request at 08:36 UTC on 21 October, about five and a half hours before the fix was public [8]. Sophos reports that exploitation attempts have been observed since at least 17 October [4]. Over the following day ELLIO documented scanners, probes for the session upload path, a Mirai-variant botnet loader, and a request sequence that ended with a PHP web shell written into a site's web directory [8]. The sources differ on exact start dates, but they agree that attacks began before or at the moment of disclosure, so treat any unpatched, internet-facing PHP server as potentially compromised until you have checked.



Which PHP versions are affected?

Every PHP release before the fixed versions below is affected [3][5].

PHP branch

Vulnerable versions

Fixed in

Support status

8.5

before 8.5.12

8.5.12

Supported

8.4

before 8.4.27

8.4.27

Supported

8.3

before 8.3.36

8.3.36

Supported

8.2

before 8.2.35

8.2.35

Security fixes only until 31 December 2026 [9][10]

7.4, 8.0, 8.1

all versions

No official binary release; PHP published minimal source-only backports [4]

End of life

7.3 and older, including PHP 5

all versions

No fix available [5]

End of life

If you run an end-of-life version, the realistic options are a patched package from your Linux distribution or a commercial long-term-support vendor, or a move to a supported branch. Sophos notes that these updates are not installed automatically, so someone has to apply them [4].


Which servers and software are affected?

Any server that processes web requests with unpatched PHP is potentially exposed. PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed [3]. PHP considers Apache mod_php deployments to be at the highest risk [4]. PHP confirmed remote code execution against PHP-FPM through CVE-2026-109619, while for CVE-2026-109618 its analysis says PHP-FPM is susceptible but no complete exploit against it had been shown [6].


Because the flaw sits in the PHP runtime, this covers WordPress, Drupal, Laravel, Symfony and custom PHP applications alike. Updating a CMS or a plugin does not change the PHP runtime. Only a patched runtime fixes the problem, whether it sits on your own server, in a container image or at a managed host.


How do I check my PHP version?

Start by finding every place PHP runs: servers, virtual machines, container images, staging environments and managed hosting accounts. For each one, check the version that actually serves web requests, which is not always the same as the command-line version.


On a server you control, php -v shows the command-line version, and you should also check the web-serving component, such as PHP-FPM or the Apache PHP module, with your package manager. For containers, check the PHP version inside each image that serves traffic. On managed hosting, look in the control panel or ask the provider which PHP version your site uses.



Be careful with version strings. Linux distributions often backport security fixes without changing the PHP version number, so an older-looking version can be patched, and a matching version number does not prove you are safe until the process has been restarted. Check your distribution's security tracker or package changelog for the two CVE numbers. AlmaLinux, for example, shipped patched packages for its PHP streams on 21 October [6].


How do I fix PHP2Shell?

  1. Update PHP. Install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or the equivalent patched package from your operating system vendor, hosting provider or appliance vendor [1][3]. PHP states that updating is the only safe choice [1].

  2. Restart every PHP worker. Restart PHP-FPM, Apache, LiteSpeed or whatever runs PHP, so no vulnerable process stays in memory. Restarting also matters because CVE-2026-109619 involves state left in long-running workers.

  3. Handle end-of-life versions. For PHP 8.1 and older, get a vendor-patched package or move to a supported branch. Plan the move now, since PHP 8.2 itself receives only security fixes until the end of 2026 [9][10].

  4. Keep front-end limits after patching. Block multipart form uploads to applications that accept none, and where uploads are needed cap the request size, the number of parts and the number of headers per part. A size limit alone is not enough [8].

  5. Check for compromise before you relax. Patching closes the hole but does not remove a web shell or malware that is already in place (see below).


Are there stopgaps if I cannot patch today?

There are partial measures, but PHP states plainly that there are no complete mitigations [1]. The two flaws need different stopgaps, and early coverage often mixed them up [8].

Flaw

Stopgap

What it does and does not cover

CVE-2026-109619

Set session.upload_progress.enabled=0 and restart workers; on PHP 8.5 also set fatal_error_backtraces=0 [8]

Closes the session upload-progress path only [8][9]

CVE-2026-109618

PHP's advisory suggests enforcing memory_limit=-1 so it cannot be changed by applications, restarting workers, and using container or cgroup memory limits instead of RLIMIT_AS or RLIMIT_DATA [8]

Reduces one trigger; read the advisory in full before applying [2]

The upload-progress feature has existed since PHP 5.4 and is enabled by default, but turning it off does nothing for the out-of-memory flaw [8][9]. Treat these steps as a bridge of hours or days, and patch as soon as you can.


How do I know if I have been compromised?

Assume exposure until verified, especially for internet-facing PHP servers that were unpatched on or after 17 October. Look for signs such as these:

  • PHP worker processes exiting on memory errors in bursts, or a PHP worker starting a shell, an interpreter or a network tool [8]

  • New or unexpected PHP files in web directories or upload folders, including small files that run commands passed in a request

  • Outbound connections from the web server to unfamiliar addresses, and processes that borrow the names of system services but run from unusual paths [8]

  • Web server logs showing multipart POST requests with a PHP_SESSION_UPLOAD_PROGRESS field, which needs checking before you act on it, because sites that use upload progress send it legitimately too [8]


ELLIO's post publishes detailed indicators of compromise, including user agents, file hashes and network addresses, and is updated as new activity is found [8]. If you find evidence of compromise, isolate the server, rotate any secrets it could read (database passwords, API keys, session secrets), and rebuild from a known-good image and clean backups instead of cleaning in place.



Why is PHP2Shell so serious?

Three things make it dangerous. First, it sits in PHP's core request handling, which nearly every PHP web request touches, so one flaw affects countless applications at once. Second, it needs no login: an unpatched PHP server that accepts a POST request is exposed with no application bug required [8]. Third, exploitation began before many operators knew about it, and public proof-of-concept code lowered the bar for attackers [4][8].


Timeline

Date (2026)

Event

August

Reports reach PHP's security team (11 August per Sophos [4], 27 August per ELLIO [8])

17 October

Earliest exploitation attempts Sophos reports having seen [4]

20 October

Details and a working proof of concept leak; PHP announces an emergency release [8][10]

21 October, 08:36 UTC

First PHP2Shell request recorded by ELLIO sensors, before the fix [8]

21 October, 14:00 UTC

PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with advisories [8]

21 October, evening

Patched distribution packages begin reaching production repositories, for example AlmaLinux at 21:15 UTC [6]


Frequently asked questions


What is CVE-2026-109618? 

It is a critical PHP vulnerability (CVSS v4.0 score 9.2) in which running out of memory during a request can corrupt request data and lead to unauthenticated remote code execution [3][8].


What is CVE-2026-109619? 

It is a critical PHP vulnerability (CVSS v4.0 score 9.2) in which stale request state left in a worker can be reused by a later request, leading to unauthenticated remote code execution [3][8].


Which PHP version fixes PHP2Shell? 

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026 [1][3].


Is my WordPress site affected?

It is if the PHP runtime behind it is unpatched, because the flaw sits in PHP itself. Updating WordPress or plugins does not change the PHP runtime. Ask your host which PHP version you are on and whether it has been patched.


Does disabling session.upload_progress fix it? 

No. It closes only the session path of CVE-2026-109619 and does nothing for CVE-2026-109618. PHP says updating is the only complete fix [1][8][9].


Can a firewall or login protect me? 

Authentication cannot stop it, because PHP handles the request before the application runs [7]. Front-end limits on uploads reduce exposure but do not replace patching [8].


Is PHP 7.4 or 8.1 fixed? 

Not through an official binary release. PHP published source-only backports, so you need a vendor-patched package or an upgrade [4]. PHP 7.3 and older, including PHP 5, have no fix [5].


Sources

[1] PHP development team, release announcements for PHP 8.5.12 and PHP 8.4.27 (21 October 2026).


[2] PHP security advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).


[3] NCSC-NL, "php2shell vulnerabilities (CVE-2026-109618, CVE-2026-109619)": operational information.


[4] Sophos, "Advisory: PHP2Shell Vulnerabilities" (sophos-sa-20261021-php2shell). https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell


[5] watchTowr, "PHP2Shell FAQ: CVE-2026-109618 and CVE-2026-109619 fixes." https://watchtowr.com/intelligence/php-cve-2026-109618-faq/


[6] AlmaLinux, "php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages released."


[7] Datadog Security Labs, "PHP2Shell: critical vulnerabilities in PHP." https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/


[8] ELLIO Threat Research Lab, "PHP2Shell: attacks before the patch, and automation by nightfall" (updated through 22 October 2026). https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/


[9] Brandefense, "PHP2Shell: two critical PHP flaws reported as RCE." https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/


[10] SOCRadar, "PHP2Shell (CVE-2026-109618 and CVE-2026-109619): critical PHP RCE flaws, affected versions, and how to fix them." https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/


Comments

bottom of page