PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 and published both advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618, remote code execution via out-of-memory corruption) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, remote code execution via stale global state). Every release before those four is affected. PHP rates mod_php the highest risk, with a demonstrated unauthenticated exploit that fires before any application code runs. The sections written before the release are kept below with their sources; the new section at the end carries what PHP published. Sigma rules for both CVEs were added at 15:41 UTC, at the end of the post.
- What: The PHP security team announced on php.net on 20 October 2026 a security release for 21 October at 14:00 UTC that "addresses two critical vulnerabilities, both rated CVSS v4.0 9.2." The leaked IDs are CVE-2026-109618 and CVE-2026-109619.
- Impact: Sansec says the flaws are in PHP itself and are reachable before application code or an application-level shield runs. Details are withheld, and no in-the-wild exploitation has been reported as of 20 October.
- Fix: Released 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no release; the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source or have no LTS vendor.
- Who: Anyone running PHP. Mallory counts 883,717 internet-facing hosts, about 59 percent of those that report a version, on branches that will not be patched.
The PHP security team published advance notice on php.net on 20 October 2026 of a security release "scheduled for Wednesday, 21 October 2026 at 14:00 UTC." The notice says it "addresses two critical vulnerabilities, both rated CVSS v4.0 9.2," and that full details, affected versions and fixed versions will be published with the release. It also says the team reserves "the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild." The notice is at php.net.
Details did become public, in part. The two CVE IDs, CVE-2026-109618 and CVE-2026-109619, leaked the same day, and researchers say a working exploit tool exists. This post covers what is known and who said it, what defenders are watching for before the fix, and what RedEye expects next.
The leak and the timeline
- 20 October: A Hacker News "Tell HN" post by user petecooper (item 50167754, since deleted) said two critical PHP remote code execution flaws rated CVSS 10.0, affecting PHP back to version 5, would be disclosed on 22 October. It named CVE-2026-109618 and CVE-2026-109619. (BleepingComputer, Lawrence Abrams.)
- Planned: Coordinated disclosure had been set for Thursday 22 October at 11:00 ET. watchTowr said: "We were all supposed to wait until Thursday at 11am ET." (BleepingComputer; threatlandscape.io timeline.)
- 20 October: PHP published its advance notice and moved the release up a day.
- 21 October, 14:00 UTC: Scheduled release, with affected and fixed versions.
The severity numbers do not match. PHP rates both flaws 9.2 on CVSS v4.0. The leaked post and watchTowr's early comments said 10.0.
What is known, and from whom
watchTowr
watchTowr CEO Benjamin Harris confirmed the flaws are real and said the company reproduced CVE-2026-109618. watchTowr is withholding details until the fix ships and says it has seen no in-the-wild exploitation. It did not discover the bugs, and the original researchers are not yet public. Its first post mistyped the IDs as CVE-2926; that has been corrected.
Sansec
The Sansec Forensics Team says a screenshot of an exploit tool named PHP2Shell, credited to Calif.IO, leaked alongside the advisory. Its banner claims it works against every PHP release from 5.4.0 on. Sansec says the flaws affect all web servers running PHP 5.4 or later, including Magento, Shopware and WooCommerce stores. Because the attack targets PHP itself, before store code or any application-level shield runs, Sansec says the fix is infrastructure-level and cannot be applied from the application. It says PHP 8.1 and older get no official fix, since PHP supports 8.2 and later, and that it expects mass attacks within 15 minutes of the release. Source: sansec.io.
Huntress
Huntress Rapid Response (John Hammond, with Lindsey Welch and Ben Nahorney) wrote on 20 October that it had seen no exploitation in Huntress partner environments as of that date. It tells defenders to inventory every PHP install, including vendor software that bundles php-cgi.exe or php.exe on Windows, control panels such as cPanel and Plesk, appliances, and PHP applications such as WordPress, Drupal, Joomla and Magento. Huntress says it will publish Sigma and YARA rules to huntresslabs/threat-intel once details are public, and that indicators of compromise are still to be determined. Source: huntress.com.
Mallory
Mallory published numbers on 20 October based on Shodan's "X-Powered-By: PHP/<major.minor>" header per branch. Its read is that expected fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, citing the PHP notice. PHP confirmed those four on 21 October; Mallory had them right. Source: mallory.ai.
Who is exposed
Mallory counts about 1.5 million internet-facing hosts that report a PHP version. Of those, 883,717 run a branch that will get no fix, about 59 percent:
- PHP 5.x: 368,570 hosts
- PHP 7.x: 329,358 hosts
- PHP 8.0 and 8.1: 185,789 hosts
Roughly 740,000 more hosts hide their version. Shared hosting means the number of affected sites is larger than the number of hosts. Sansec's point that the flaw sits below application code means a hardened store or a web application firewall in front of the code is not the same as a patched PHP.
One group's hypothesis, not confirmed by PHP
Written before the release as one research group's working hypothesis. PHP's advisory for CVE-2026-109619 names session.upload_progress.enabled=0 as the mitigation that "blocks the confirmed session paths but not other variants", so the session upload-progress handler is one of the confirmed producers of the stale state. The root cause PHP describes is wider than that handler, and CVE-2026-109618 is a different mechanism altogether (out-of-memory during request startup, worst on mod_php). The section below stays as it was written, with the group's credit for calling the session path.
Andrew Dorman, on LinkedIn, and JackalSyn, in a write-up from the same group, say that based on their own read of php-src the vulnerable path is the session.upload_progress handler for multipart form-data (rfc1867) in ext/session/session.c. They say it has existed since PHP 5.4 and is enabled by default: the compiled-in default is On, and the sample php.ini ships the line commented out. It runs before application code, so on their reading it is reachable before authentication on a default configuration. They describe two heap use-after-free primitives.
The group's reported stopgaps are to set session.upload_progress.enabled to Off and reload PHP-FPM or the web server, which by their own account closes one of the two likely paths, and to tighten or rate-limit multipart POSTs at a WAF or reverse proxy for endpoints that do not take uploads. These are the group's suggestions, reported here as such, not a vendor mitigation. The official advisory is the thing to follow.
What defenders are watching for before the fix
Huntress describes the detection shape it expects, which does not depend on the root cause:
- PHP workers (php-fpm, php-cgi, php-cgi.exe, httpd, apache2) launching shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl) or download and network tools (curl, wget, nc, certutil.exe).
- Reverse-shell patterns such as /dev/tcp/, fsockopen and mkfifo.
- Reconnaissance commands run from web servers, such as whoami, id, uname -a and ipconfig.
For Linux hosts without EDR, Huntress points to Florian Roth's process-watcher.
A "Zer061/CVE-2026-109618" repository appeared on an exploit aggregator on 20 October. Any public proof of concept posted before the fix ships should be treated as bait, not a tool to run.
KEV outlook: RedEye's own assessment
This section is RedEye's assessment, not a CISA statement. CISA's three tests for the Known Exploited Vulnerabilities catalog are a CVE ID, a clear remediation and reliable evidence of active exploitation. The first is met; the second lands at 14:00 UTC today. The closest precedent is CVE-2024-4577, the PHP-CGI argument injection disclosed on 6 June 2024, exploited by ransomware within 48 hours and added to KEV on 12 June 2024, six days later. This one has a wider blast radius, so RedEye expects a KEV listing within days of the fix. RedEye's feed carries a KEV fast lane that flips the moment CISA lists it.
Two things could slow exploitation. PHP's 9.2 rather than 10.0 hints at a precondition, such as a SAPI, a configuration or a request shape, that the leak does not show. And nobody outside the embargo has published a root cause.
After the release: what PHP published
At 13:34 UTC on 21 October 2026 PHP published both advisories on GitHub, and the php.net notice followed with the releases. Both CVEs carry CVSS v4.0 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) and the same weakness list, CWE-416, CWE-755, CWE-824, CWE-1325 and CWE-1419. Reporters credited on both: lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai. Fixes by arnaud-lb, iluuu1994, bukka and ndossche. Affected: every PHP release before 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Sources: GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, php.net, ChangeLog 8.4.27.
CVE-2026-109618, RCE via out-of-memory corruption
PHP uses longjmp() to abandon a request on out-of-memory. In some contexts request memory is reachable before it is fully initialized; if any allocation fails at that point, the early exit leaves the request memory invalid and request shutdown then reads or branches on it. The advisory lists several ways a request can reach out-of-memory while staying inside its apparent limits: a multipart body with no usable Content-Length that passes the initial post_max_size check and keeps supplying decoded data, an unrestricted number of headers per multipart part whose in-memory form costs far more than the wire bytes, and empty file controls that do not count toward max_file_uploads but still build the metadata arrays. Apache mod_php is the worst case: it runs request shutdown unconditionally even when startup failed, so the invalid state is processed before any application code. PHP-FPM exits the child when startup fails, which removes that path, but out-of-memory after normal startup can still reach it.
CVE-2026-109619, RCE via stale global state
Worker-global state (error, session, object and extension state) points at memory owned by one request and must be reset before that memory is released. Some input, configuration, session and error-handling operations run before the next request's normal initialization and consume state the previous request left behind, a use after free. State survives when a fatal error, including memory exhaustion, abandons an operation before its reset, or when a warning or other diagnostic repopulates error state after shutdown already cleared it. Exploitation needs a producer in one request and a consumer in a later request on the same worker; PHP's demonstrated producer and consumer are in different HTTP requests. PHP's mitigations name two confirmed paths: the session upload-progress handler (session.upload_progress.enabled=0, set in php.ini, an FPM pool or server configuration, never ini_set() or .user.ini) and, on PHP 8.5 only, fatal error backtraces (fatal_error_backtraces=0). Each closes its own path and no other.
What PHP says to do
Update. For installations that cannot update at once, php.net lists measures that "reduce exposure to specific attack paths but do not make an installation safe": for CVE-2026-109618, memory_limit=-1 applied where applications cannot override it, a low post_max_size (8M without uploads, 32M with), request-size, field-count, part-count and header-count limits at the web server or proxy that also cover requests without a usable Content-Length, and a container or cgroup limit as the availability boundary rather than RLIMIT_AS or RLIMIT_DATA, which can themselves cause the vulnerable allocation failure; for CVE-2026-109619, the two settings above plus removing invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help. Linux distributions and LTS vendors had the patches in advance; the volunteer remirepo.net RPMs did not get updates on release day, and php.net asks those users to move to distribution packages or build from source.
Status at the time of this update
No in-the-wild exploitation had been reported by the named sources when this update was written, and neither CVE was in CISA's Known Exploited Vulnerabilities catalog. RedEye's assessment above, that a listing is likely once exploitation is observed, stands; the advisories' own wording, a demonstrated pre-authentication exploit on mod_php and public research groups already working the paths, is why.
How this looks in Caver
In Caver, the signal to watch is a notable on OCSF process activity where the parent is a PHP worker and the child is a shell, an interpreter or a download tool, the same shape Huntress describes. The KEV fast lane on the detection feed flips when CISA lists either CVE. The vSOC catches the drill-down: which host, which web worker, which command, and what it reached out to next.
Detection: Sigma rules
Four Sigma rules for PHP2Shell, written by RedEye from PHP's two advisories and the detection shape Huntress published. Neither CVE has a public exploit request yet, so these watch what exploitation does after it lands and the crashes that failed attempts leave, not the request itself. All four are status experimental; backtest them against your own logs before enabling.
Each rule is standard Sigma (process_creation for the first three, a keyword rule for the error-log crash signal) and converts with any Sigma backend. The full rule text is below. Caver runs the process rules on OCSF process activity as they are.
1. PHP worker spawns a shell, interpreter or network tool (Linux, high)
A php-fpm, php-cgi or Apache worker starting sh, bash, python, perl, curl, wget, nc, socat or a recon command such as whoami, id or uname. This is the post-exploitation shape Huntress describes, and it holds whichever of the two bugs is used. Some applications shell out by design, so allowlist by pool and command line before alerting.
title: PHP Worker Spawns a Shell, Interpreter or Network Tool on Linux (PHP2Shell)
id: c8106237-9c3f-4275-b145-ede7b1862642
status: experimental
description: |
Detects a PHP web worker (php-fpm, php-cgi, or Apache httpd running mod_php) starting a shell,
a script interpreter or a download or network tool. This is the post-exploitation shape
Huntress describes for PHP2Shell (CVE-2026-109618, CVE-2026-109619), and it does not depend on
the root cause of either bug. Some applications legitimately shell out (image or PDF conversion,
mail, git deploy hooks), so tune by parent pool and command line before alerting.
references:
- https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- https://threat-intelligence.redeyesecurity.com/blog/php2shell-leaked-php-core-rce-cve-2026-109618-109619.html
author: RedEye Security
date: 2026-10-21
tags:
- attack.execution
- attack.t1059.004
- attack.persistence
- attack.t1505.003
- cve.2026-109618
- cve.2026-109619
logsource:
product: linux
category: process_creation
detection:
selection_parent:
- ParentImage|contains: '/php-fpm'
- ParentImage|endswith:
- '/php-cgi'
- '/httpd'
- '/apache2'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/python'
- '/python3'
- '/perl'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/socat'
- '/busybox'
- '/whoami'
- '/id'
- '/uname'
condition: all of selection_*
falsepositives:
- Applications that shell out by design (ImageMagick, wkhtmltopdf, sendmail wrappers, git hooks); allowlist by parent pool and command line
level: high
2. PHP worker starts a reverse shell pattern (Linux, critical)
The same parents running a command line with /dev/tcp/, mkfifo, fsockopen or nc -e. A hit here is a likely compromise rather than a tuning question.
title: PHP Worker Starts a Reverse Shell Pattern on Linux (PHP2Shell)
id: 8673d08f-c5e5-4fb9-a2dd-964021754d99
status: experimental
description: |
Detects reverse-shell command lines started under a PHP web worker: bash /dev/tcp redirection,
mkfifo pipes, netcat with -e, and PHP fsockopen one-liners. Huntress lists these as the patterns
to watch for PHP2Shell (CVE-2026-109618, CVE-2026-109619). A hit is a likely compromise, not
a tuning question.
references:
- https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- https://threat-intelligence.redeyesecurity.com/blog/php2shell-leaked-php-core-rce-cve-2026-109618-109619.html
author: RedEye Security
date: 2026-10-21
tags:
- attack.execution
- attack.t1059.004
- attack.command-and-control
- attack.t1071
- cve.2026-109618
- cve.2026-109619
logsource:
product: linux
category: process_creation
detection:
selection_parent:
- ParentImage|contains: '/php-fpm'
- ParentImage|endswith:
- '/php-cgi'
- '/php'
- '/httpd'
- '/apache2'
selection_cmd:
CommandLine|contains:
- '/dev/tcp/'
- '/dev/udp/'
- 'mkfifo'
- 'fsockopen'
- ' -e /bin/sh'
- ' -e /bin/bash'
condition: all of selection_*
falsepositives:
- None expected
level: critical
3. PHP worker spawns a shell or living-off-the-land tool (Windows, high)
php-cgi.exe, php.exe or httpd.exe starting cmd.exe, PowerShell, certutil, curl, bitsadmin, mshta, rundll32 or recon tools. Huntress singles out Windows vendor software that bundles php-cgi.exe or php.exe as the PHP that inventories miss.
title: PHP Worker Spawns a Shell or Living-off-the-Land Tool on Windows (PHP2Shell)
id: c7678d8b-0049-405e-8454-2e7bb9cf4c3c
status: experimental
description: |
Detects php-cgi.exe, php.exe or Apache httpd.exe starting cmd.exe, PowerShell, certutil, curl,
or reconnaissance tools. Huntress calls out Windows vendor software that bundles php-cgi.exe or
php.exe as easy to miss when inventorying PHP for PHP2Shell (CVE-2026-109618,
CVE-2026-109619).
references:
- https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- https://threat-intelligence.redeyesecurity.com/blog/php2shell-leaked-php-core-rce-cve-2026-109618-109619.html
author: RedEye Security
date: 2026-10-21
tags:
- attack.execution
- attack.t1059.001
- attack.t1059.003
- cve.2026-109618
- cve.2026-109619
logsource:
product: windows
category: process_creation
detection:
selection_parent:
ParentImage|endswith:
- '\php-cgi.exe'
- '\php.exe'
- '\httpd.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\certutil.exe'
- '\curl.exe'
- '\bitsadmin.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\whoami.exe'
- '\ipconfig.exe'
- '\net.exe'
condition: all of selection_*
falsepositives:
- PHP applications that call system tools by design; allowlist by parent path and command line
level: high
4. PHP worker memory corruption crash (Linux, medium)
Both bugs leave request memory in an invalid state, so failed or unreliable attempts are likely to crash workers. The rule matches the segfault, abort and zend_mm_heap corrupted lines Apache and PHP-FPM write to their error logs. One crash is noise; a burst from one server, next to oversized multipart POSTs in the access log, is the case to look at.
title: PHP Worker Memory Corruption Crash (PHP2Shell Exploitation Attempts)
id: 51661855-a4ee-414d-b391-98d24fe8ceba
status: experimental
description: |
Both PHP2Shell bugs leave request memory in an invalid state: CVE-2026-109618 corrupts it when
an allocation fails during request startup (worst on Apache mod_php), and CVE-2026-109619 is a
use after free across requests on the same worker. Failed or unreliable exploitation is likely
to crash workers. This matches the crash lines Apache and PHP-FPM write to their error logs.
One crash is noise; a burst from one server, especially next to oversized multipart POSTs in
the access log, is the case to triage. Apply it to the Apache error log and the PHP-FPM log.
references:
- https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- https://threat-intelligence.redeyesecurity.com/blog/php2shell-leaked-php-core-rce-cve-2026-109618-109619.html
author: RedEye Security
date: 2026-10-21
tags:
- attack.initial-access
- attack.t1190
- cve.2026-109618
- cve.2026-109619
logsource:
product: linux
detection:
keywords:
- 'exit signal Segmentation fault'
- 'exited on signal 11'
- 'exited on signal 6'
- 'zend_mm_heap corrupted'
condition: keywords
falsepositives:
- Unrelated extension or opcache crashes; baseline your normal crash rate and alert on a rise
level: medium
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us