Two pre-authentication remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, are being exploited in the wild, according to watchTowr’s Attacker Eye honeypot network. Public analysis calls the pair “php2shell,” assigns both a CVSS v4.0 score of 9.2 (Critical), and traces the primary demonstrated path to a heap use-after-free in PHP’s session upload-progress handling. PHP has published fixes in 8.5.12, 8.4.27, 8.3.36, and 8.2.35, while patch coverage for older branches remains inconsistent across the public sources.
Disclosure overtook the planned schedule
Details of the two PHP core bugs appeared online on October 20, ahead of coordinated disclosure, according to a public advisory repository. A social-media post cited in the original report said an announcement covering two PHP remote code execution vulnerabilities was scheduled for October 22, 2026, at 18:00 CEST. The poster cautioned that the claim rested entirely on trust in that source and had not been independently confirmed when it was published.
The timeline then moved faster than the plan. watchTowr says exploitation was observed as of October 21 through its global honeypot network. A mechanics repository lists the MITRE entry as published on 2026-10-21 and notes that a php.net advisory was published. Backport documentation says the two core fixes were released on 2026-10-21.
Some sections of watchTowr’s FAQ still contain pre-disclosure language saying that no vendor fix or workaround existed, while its summary states that PHP has now published patches. The practical reading is that the disclosure was updated after the initial leak, but not every section was rewritten.
What the vulnerabilities are
CVE-2026-109618 and CVE-2026-109619 are flaws in PHP itself, not in a CMS plugin or framework. Both are described as pre-authentication remote code execution issues that can let an unauthenticated attacker run code on a server hosting PHP, potentially taking control of the host. Public analysis says the attack is triggered before any application code runs.
The primary demonstrated vector is a heap use-after-free in PHP’s core session upload-progress mechanism. The mechanics repository says successful exploitation reaches arbitrary command execution through zend_call_function / system().
The reported version scope is unusually broad. The original report says every PHP version from PHP 5 onward is affected, and separately states that PHP 5, 7, and 8 are affected in their entirety. A separate proof-of-concept repository says reports indicate PHP 5, 6, 7, and 8 may be affected.
The initial report did not describe a specific configuration or feature requirement. Later technical analysis centers on session.upload_progress, which is the feature the patch set explicitly disables in code.
How the attack path works
PHP’s session upload-progress feature reports the status of file uploads, typically during multipart form submissions. Public analysis describes a heap use-after-free in that mechanism: request-scoped memory can be freed while a reference to it remains live. A use-after-free becomes dangerous when the freed allocation is reused and the stale reference is later followed, allowing data or control flow to be influenced by the attacker.
The patch notes in the backport repository, which mirror the official minimal PHP 7.4 backport at php-src commit 712e60f9ed, describe several related hardening changes:
- Allocation-failure handling: The patch removes
longjmp()on out-of-memory and integer-overflow conditions. A fatal allocation error now terminates the process with_exitinstead of unwinding through partially initialized request state. This is associated with CVE-2026-109618. - Request-state reset: Error and exception handlers, superglobals, SAPI request fields,
modules_activated, and the object store are cleared at request shutdown so a later request cannot consume stale values. This is associated with CVE-2026-109619. - Session upload-progress disabled in code: This closes the confirmed producer/consumer path for CVE-2026-109619.
- Multipart parsing hardened: Only the headers actually used are retained.
The mechanics repository claims a working remote chain for PHP 8.4.x, three additional exploit paths, and post-patch status information. The public excerpt available here does not include a complete request payload, exploit listing, or byte-level reproduction, so this post does not invent one. The repositories linked below are the appropriate place to examine the published mechanics.
Exploitation, exposure, and attribution
watchTowr says exploitation activity was observed as of October 21 through Attacker Eye. The vendor also says its Rapid Reaction team identified exposure across its client base and that Active Defense was used to deploy autonomous investigation capabilities.
The public material does not name a threat actor behind the honeypot hits. It also does not provide hashes, IP addresses, domains, or file paths, so there are no incident-specific IOCs to reproduce here.
The original report points readers to the CISA Known Exploited Vulnerabilities catalog for CVE-2026-109618 but does not state whether the CVE has been added. Check the live catalog for current KEV status.
Fixed versions and the older-branch problem
The watchTowr FAQ says the following releases address the vulnerabilities:
| PHP branch | Fixed release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
The original FAQ also says patches have not been made available for PHP 5 or 7. That statement conflicts with later public documentation, and the differences matter for anyone running end-of-life PHP.
A separate backport repository says PHP ships fixes for 8.2 and later, plus minimal source backports for 7.4, 8.0, and 8.1. It describes its own patches for 5.4 and 7.3 as unofficial, minimal source backports against the last release of those branches, not official PHP releases. The repository states plainly that upgrading to a supported PHP version is the only complete fix.
An earlier version of another analysis warned that fixes were primarily expected for supported PHP 8 branches, leaving PHP 5.x, 7.x, 8.0, and 8.1 exposed without official vendor patches. The sources do not agree on how far official EOL coverage extends. Treat the supported PHP 8 releases as the fully fixed path and verify the vendor status of any older branch before relying on a backport.
Verify exposure and reduce risk
The commands below are generic audit and verification checks, not exploit code. Run them against every PHP runtime in the estate, including containers, packaged appliances, and separate SAPIs.
Check the runtime version:
php -v
php -r 'echo PHP_VERSION, PHP_EOL;'
Check whether upload-progress handling is enabled:
php -i | grep -E '^session\.upload_progress\.'
Compare the result with the fixed releases above. If the installation is on PHP 5 or 7, or on an unsupported 8.x branch, prioritize a migration rather than assuming a source backport is equivalent to a supported release.
If an immediate upgrade is not possible, disabling the upload-progress feature is a stopgap consistent with the published patch analysis. This can break applications that display upload progress bars, so test it before rolling it out:
session.upload_progress.enabled = Off
Reload the relevant PHP service after changing the configuration. The unit name varies by distribution and SAPI:
sudo systemctl reload php-fpm
Hunt for suspicious process relationships while the patch is being deployed. This is a generic behavioral check; it is not an IOC list:
ps -eo pid,ppid,user,etime,cmd --forest | grep -E 'php-fpm|apache2|httpd|nginx|/bin/sh|/bin/bash'
Unexpected shell processes, download utilities, or other command interpreters parented by a web-server worker deserve investigation. Establish a baseline first, because some deployments legitimately spawn helper processes.
The public proof-of-concept repository also publishes deployment-specific mitigation examples for Cloudflare WAF custom rules, FrankenPHP’s Caddyfile, Lighttpd, and Apache using ModSecurity or .htaccess. Those controls are useful as defense in depth, but they are not a substitute for patching, and each rule should be validated against the local traffic profile before blocking.
Because the flaw is pre-authentication and executes before application code, application-level logging may not record the relevant activity. Process monitoring, web-server logs, and network egress controls are more likely to provide visibility.
Technical background
A use-after-free is a memory-safety bug in which an object is freed but a pointer to it is still used. In a request-oriented runtime such as PHP, the risk is amplified when state that should belong to one request survives into another, or when an error path unwinds without cleaning up partially initialized structures. The patch set addresses that class of failure directly: it stops fatal allocation errors from unwinding through live request state, clears request-owned globals at shutdown, removes the upload-progress path, and tightens multipart parsing.
That combination explains why the disclosure is treated as a core PHP emergency rather than a single-application bug. Any internet-facing PHP service can be in scope, regardless of the CMS or framework running on top, if it exposes the affected code path.