PHP2Shell (CVE-2026-109618, CVE-2026-109619): What to Preserve Before You Patch

This is not a news recap. The coverage of PHP2Shell is moving by the hour and several of the early claims have already been corrected. This page sticks to what the PHP advisory and named researchers have published. It then covers the part most write-ups skip: what an investigator needs from a PHP server before the patch restarts every worker and wipes the live state. Every status claim below is stamped as of 21 Oct 2026 (PDT) and will change.

Key facts as of 21 Oct 2026 (PDT)

CVE IDs

CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state")

Severity (PHP)

9.2 Critical, CVSS v4.0, rated by the PHP security team. Vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

Severity (other)

10.0, a figure watchTowr's CEO gave BleepingComputer on 20 Oct 2026 before PHP published its advisory. The PHP Foundation says the 10.0 score that circulated before release was incorrect.

Authentication

None. Application login does not block it.

Affected

PHP serving web requests on builds older than the fixed releases. The earliest affected code path dates to PHP 5.4.0.

Fixed

8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 Oct 2026

End of life

7.4, 8.0 and 8.1: source backports only, no official release. 5.4 to 7.3: no fix from the PHP project.

Exploitation

Reported in the wild by some vendors and still under investigation. CISA had not observed exploitation at the time of its alert.

CISA KEV

Not listed (KEV catalog version 2026.10.21, checked 16:27 PDT on 21 Oct 2026)

What the two flaws do

The PHP security advisory describes CVE-2026-109618 as a fault in out-of-memory handling: "out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid." The matching GitHub advisory (GHSA-w8hw-w9fx-j79w) states that the confirmed impact is unauthenticated remote code execution as the web worker account.

CVE-2026-109619 is a stale state problem. In the advisory's words, "request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it." Its GitHub advisory (GHSA-6wmf-4rv5-p3rp) lists a heap use-after-free with memory disclosure as well as remote code execution. Memory disclosure matters for scoping: a worker can leak data that an earlier request left in memory.

Both flaws sit in PHP's own request handling, below your application. Help Net Security reports that a working exploit triggers the attack with a single unauthenticated request before any application code runs. A login page, an application role check or a plugin firewall never gets the chance to say no.

PHP says every installation that serves web requests is exposed, naming PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php. Sansec reports that researchers confirmed unauthenticated remote code execution against Magento 2.4.9 and ten other PHP applications. It adds that default configurations are vulnerable.

The CVSS vector rates attack complexity as high. Datadog Security Labs explains one reason: when the exploit guesses a memory address incorrectly, the Apache worker crashes with a segmentation fault. For an investigator that cuts both ways. Failed attempts can leave crashes in the logs. A successful attempt may leave nothing so obvious.

Affected and fixed versions

CISA's guidance is blunt. Organizations that cannot update immediately should take PHP-based systems offline until they can be patched or updated. The same applies to anyone still running PHP 8.1 or earlier.

Check your distro's security notice, not php -v

Much production PHP comes from a Linux distribution package rather than a php.net build. Distributions often backport a fix into the version they already ship and keep the old version number. Datadog puts it directly: "vendors sometimes backport fixes without changing the upstream version number."

Ubuntu 24.04 is the clearest example. Ubuntu's fixed package for PHP2Shell is 8.3.6-0ubuntu0.24.04.13. On a patched server, php -v still reports PHP 8.3.6, which looks far older than the upstream fix in 8.3.36. The reverse also holds: an unpatched Ubuntu build reports the same 8.3.6. The version number alone cannot answer the question.

Debian follows upstream more closely this time. Its security tracker lists 8.4.27-1~deb13u1 for trixie (DSA-6574-1) and 8.2.35-1~deb12u1 for bookworm (DLA-4848-1). Sansec reported that packages from Remi's repository did not carry the fix on 21 Oct 2026.

To check a host, compare the installed package against your distribution's notice for the exact build. On Ubuntu, Ubuntu's PHP2Shell post suggests apt list '?installed ?name(^php[0-9.]+$)'. On RPM-based systems, search the package changelog for the CVE IDs. Then confirm the running workers were restarted after the update, because a patched package on disk does nothing for a worker process that loaded the old library.

Exploitation status as of 21 Oct 2026 (PDT)

The sources disagree. That is normal on day one. It is also why every line below carries an attribution.

• CISA: "has not observed exploitation of these vulnerabilities as of the time of publication" (alert of 21 Oct 2026).
• watchTowr: reports observing active exploitation attempts against both CVEs.
• Datadog Security Labs: "As of October 21, we have multiple reports of active exploitation in the wild." It also reports broad untargeted scanning.
• Cloudflare, as reported by Sansec: early attacks at 07:43 UTC on 21 Oct 2026, before the 14:00 UTC release.
• Huntress: had not seen in-the-wild exploitation across its partner base as of 4:30 pm ET on 21 Oct 2026.
• PHP Foundation, as quoted by Tenable: the team "did not identify any functional exploits at the time of release/public disclosure."
• CISA KEV: neither CVE is in the Known Exploited Vulnerabilities catalog (version 2026.10.21, checked 16:27 PDT).

The timeline explains the noise. On the morning of 20 Oct 2026, a post on Hacker News claimed that two critical PHP vulnerabilities were headed for public disclosure. PHP published an advance notice the same day. Coordinated disclosure had been set for 14:00 UTC on 22 Oct. Because of the leak it was moved forward to 14:00 UTC on 21 Oct. Researchers published technical details that afternoon. Treat any internet-facing PHP server that was unpatched from 20 Oct onward as possibly probed.

What to preserve before you patch

Patching is the fix. It also restarts every PHP worker. A restart clears process memory, live network connections and the worker state an examiner would use to tell a failed probe from a successful one. Do not let preservation delay the patch for hours. On a single server, the steps below usually take minutes, so capture first and then patch.

1. Snapshot the host. On a virtual machine or cloud instance, take a disk snapshot first. Take a memory snapshot too if your platform supports it.
2. Capture volatile state. Record the full process tree with parent and child relationships. Record network connections with the owning process, paying attention to outbound connections from the web user (www-data, apache or nginx). Save the web user's crontab and the list of logged-in users.
3. Copy the logs. Take the web server access and error logs, including rotated files. Take the PHP-FPM log, the PHP error log and the system journal, which records segfaults and out-of-memory kills around the time of a request. Take reverse proxy, CDN or WAF logs too. Default access log formats record the request line and response size, not the request body, so the proxy layer is often the only record of an oversized request.
4. Inventory the web roots. List every .php file and other executable content in web roots and upload directories with size, modification time and change time. Hash them with SHA-256. Copy anything new or changed. Do not open suspect files through the browser. Compare against version control or a clean release of the application.
5. Record the package history. Save the package manager log so the timeline shows when PHP was updated and when the workers restarted.
6. Hash and document. Hash each collected file, note the time zone of every log source and record who collected what. That record is what makes the evidence usable later with an insurer, a regulator or a court.

Then update, restart every worker (Apache for mod_php, every PHP-FPM pool) and confirm the new build is the one running.

What the logs can show and what they can't

Datadog Security Labs published the clearest detection notes so far, from its own lab reproduction. For CVE-2026-109618 it describes the exploit request. It uses the application/x-www-form-urlencoded content type. Its body contains a single field name of about 3.5 MB. It also contains binary data, including raw null bytes, in the value of a field with an empty name. In its lab, the exploit attempt produced this PHP error:

PHP Fatal error: Allowed memory size of 16777216 bytes exhausted
(tried to allocate 3500032 bytes) in Unknown on line 0

Datadog notes that "Unknown on line 0" means PHP failed during request initialization, before any script started running. A wrong memory guess produced an Apache worker crash:

AH00052: child pid ... exit signal Segmentation fault (11)

Treat these as patterns to search for, not exact strings. The byte counts in Datadog's lab depend on its memory limit and will differ on your server. More important, Datadog warns that a successful exploit may return HTTP 200 and leave the worker running. An absence of crashes is not evidence that nothing happened. For CVE-2026-109619, Datadog suggests reviewing early configuration warnings, shutdown diagnostics, fatal errors and execution timeouts on reachable routes.

After a successful exploit the attacker runs commands as the web user, so the strongest evidence is behavioural. Huntress, SOCRadar and CISA all point to the same signal: a PHP worker process (php-fpm, php-cgi, httpd or apache2) starting a shell, a script interpreter (python or perl) or a network tool (curl, wget or nc). Huntress also lists command-line strings such as /dev/tcp/, fsockopen and mkfifo. It adds reconnaissance commands run from the web server, such as whoami, id and uname -a.

As of 21 Oct 2026 (PDT), none of the sources cited here has published file hashes, IP addresses or domains tied to PHP2Shell activity. Huntress states that "No indicators of compromise have been confirmed yet." This page lists none. Be cautious with any indicator list that does not name a primary source.

Patching does not evict an attacker

The update closes the flaw. It does not remove anyone who already used it. Code that ran as the web worker account could write web shells into the web root or upload folders. It could modify application files, add cron entries or create accounts in the application database. All of that survives the patch and the restart.

Memory disclosure widens the scope. Huntress reports that Wiz demonstrated a separate memory disclosure path that could expose passwords, tokens, API keys and certificates. If an exposed server shows signs of probing, assume the secrets its PHP workers held may be gone. That means database credentials, API keys, session signing keys and any private key the worker could read. Rotate them after the evidence is preserved, not before, so the old values stay available for the investigation.

Config workarounds reduce exposure. They don't make a server safe.

The PHP advisory is explicit: "while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe." If you cannot update today, these are PHP's measures:

• CVE-2026-109618: set memory_limit=-1 where applications cannot override it, such as php_admin_value in the FPM pool or Apache configuration. Set a low post_max_size (8M without file uploads, 32M with them). Use a container or cgroup memory limit as the availability boundary. Do not substitute RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure.
• CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0. Apply both in php.ini, the FPM pool or the server configuration. Do not rely on ini_set() or .user.ini. Hiding diagnostics does not help.
• Edge filtering: Cloudflare deployed WAF rules for known exploit vectors and describes them as a stopgap only.

Datadog adds that memory_limit=-1 is not a long-term setting. Every one of these measures is a bridge to the update, not a substitute for it.

Check what your server reveals

Our free scanner flags PHP versions in the affected range when the server reveals them. A clean result is not proof of safety, because many servers hide their version. A server that shows a distribution build gets a warning to confirm the build with the host. So does a server that shows PHP without a version. Run it from the Hack Your Own Website tool or the free security scorecard. The scanner is passive. It reads the version the server already shows and sends no exploit traffic.

When to bring in Sherlock Forensics

Call for a compromise assessment if any of these apply to an internet-facing PHP server:

• It ran an affected build at any point from 20 Oct 2026.
• Its PHP error log shows memory exhaustion "in Unknown on line 0" near unusual requests.
• Its web server log shows worker segmentation faults you cannot explain.
• A PHP worker started a shell, an interpreter or a download tool.
• New or changed .php files appear in a web root or upload folder.

The Sherlock Forensics incident response team preserves the evidence, builds the request and process timeline, hunts for web shells and persistence, scopes what the worker could reach and documents the findings for insurers, regulators or counsel. Work is remote by default.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two flaws in PHP's request handling that PHP fixed on 21 October 2026. CVE-2026-109618 comes from out-of-memory handling. CVE-2026-109619 comes from stale state that a later request on the same worker can reuse. Both allow unauthenticated remote code execution through crafted HTTP requests.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 7.4, 8.0 and 8.1 received source backports only, with no official release. PHP 5.4 to 7.3 get no fix from the PHP project. Distribution packages may carry the fix under an older version number, so check your distro's security notice.

Does a login page or web application firewall stop PHP2Shell?

A login page does not. The flaws sit in PHP's own request handling. Help Net Security reports that a working exploit triggers with a single unauthenticated request before any application code runs. Edge WAF rules can filter known exploit patterns, but Cloudflare calls its own rules a stopgap. Only the update fixes the flaws.

Is PHP2Shell being exploited?

As of 21 Oct 2026 (PDT), sources disagree. watchTowr and Datadog report exploitation activity. Cloudflare reported early attacks before the release. CISA had not observed exploitation when it published its alert. Neither CVE is in the CISA Known Exploited Vulnerabilities catalog.

Why does php -v still show an old version after patching?

Linux distributions often backport the fix without changing the upstream version number. Ubuntu 24.04's fixed package is 8.3.6-0ubuntu0.24.04.13. On that build php -v still reports 8.3.6. Compare the installed package against your distro's security notice for the exact build. Then confirm every PHP worker was restarted.

Does patching remove an attacker who already got in?

No. Patching closes the flaw. Web shells, modified files, cron entries or accounts created through the web worker account survive the update and the restart. A server that was exposed before the patch needs a compromise assessment.

What should I preserve before patching a PHP server?

Take a disk snapshot. Capture the process tree and network connections. Copy the web server logs, the PHP-FPM log, the PHP error log and the system journal. List new or changed .php files in web roots with hashes. Then patch and restart every PHP worker.

Sources

1. PHP Group, Security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026), with GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp
2. Tenable, php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions
3. Datadog Security Labs, PHP2Shell: detection, analysis and remediation
4. Sansec, PHP2Shell: Critical PHP RCE
5. SOCRadar, PHP2Shell: CVE-2026-109618 and CVE-2026-109619
6. Help Net Security, PHP2Shell: Critical PHP vulnerabilities patched
7. CISA, Critical Vulnerabilities in PHP Require Immediate Patching and the Known Exploited Vulnerabilities catalog
8. NIST NVD, CVE-2026-109618 and CVE-2026-109619
9. Ubuntu, php2shell vulnerability fixes available
10. Debian, security tracker entry for CVE-2026-109618
11. watchTowr, CVE-2026-109619: PHP Remote Code Execution
12. BleepingComputer, PHP warns admins of two critical flaws
13. Huntress, Rapid Response: php2shell