On this pageUpdate PHP and restart workers
Updated 22 October 2026, 16:04 BST: We’ve added reporting from watchTowr and AWS on exploitation attempts, including activity observed before public disclosure. This update includes associated IP addresses as investigative leads and clarifies the distinction between widespread exploitation attempts and successful compromise.
PHP is a server-side scripting language that powers a substantial portion of the internet, underpinning everything from small websites to major content management systems such as WordPress. Its widespread adoption makes vulnerabilities in the PHP interpreter particularly concerning, as a single flaw can potentially expose millions of web applications.
On 21 October 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both capable of enabling unauthenticated remote code execution (RCE). Crucially, and unlike vulnerabilities affecting individual PHP applications, exploitation does not necessarily require an attacker to authenticate, upload a malicious PHP script, or exploit a vulnerability in the application itself. These flaws exist within PHP's underlying execution engine, meaning that an application running a PHP version vulnerable to these attacks could be compromised by attackers.
In the most concerning demonstrated scenario, a malicious HTTP request can trigger memory corruption before PHP even begins executing the requested application's code. Notably, Apache deployments using mod_php have been confirmed to be exploitable; this is concerning since it is an extremely common stack used to deploy PHP web applications on the internet.
The PHP security team also identifies susceptible or potentially susceptible paths in PHP-FPM, FrankenPHP and LiteSpeed deployments. Practical exploitation conditions and the level of validation differ considerably between these configurations.
Exploitation attempts have begun in the wild, however, an important distinction exists between widespread exploitation attempts and widespread successful compromise. AWS acknowledges uncertainty over whether some of the early attempts observed against its honeypot infrastructure would have succeeded against real-world systems.
While the potential impact is substantial, developing reliable memory-corruption exploits remains technically challenging, and differences between target environments can significantly affect their success rates. The greater concern is how this threat may evolve over time, as attackers progressively refine their techniques and develop more reliable exploits targeting different server configurations.
Update PHP and restart workers
The patched supported releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Update to a release containing both fixes and restart every PHP worker so the patched interpreter is loaded. The PHP advisories state that updating is the only complete mitigation; configuration changes do not cover every vulnerable path.
Why These Vulnerabilities Are Especially Dangerous
Strand has been monitoring this case as it unfolds, reviewing details as they become available and assessing the threat.
There are two factors which make these vulnerabilities particularly concerning:
PHP is Extremely Popular
PHP applications are widespread across the internet, in the form of user-facing web portals as well as back-end processing infrastructure.
A Censys query run on the morning of 21 October 2026 helps to illustrate this footprint:
Censys returned 10,093,696 web properties exposing the X-Powered-By header with a value matching PHP 7.X. This is a count of matching web properties, not a verified count of vulnerable servers.
This query does not measure the full PHP footprint, for two reasons:
The
X-Powered-Byheader can be entirely disabled or reconfigured, meaning there are many more webservers running PHP which are not included in this result set.The query searches only for PHP version 7 and therefore excludes other PHP versions, including affected releases of PHP 8.
These are not Application-Level Vulnerabilities
The vulnerabilities exist within PHP itself - exploitation may take place during the processing of seemingly ordinary HTTP requests, particularly those containing multipart form data. Application security measures designed to prevent SQL injection, command injection or malicious file uploads will not necessarily prevent exploitation.
This creates concern for defenders, since they may not be able to rely on tooling that was in place at the time of an attack.
Additionally, CVE-2026-109619 introduces a cross-request element, where the request responsible for creating the vulnerable memory state may be different from the request that ultimately triggers exploitation. This complicates forensic reconstruction, as investigators cannot necessarily identify the entire attack by examining a single suspicious HTTP transaction.
Successful exploitation achieving RCE will provide an attacker with code execution capability within the security context of the affected PHP or web-server worker. From there, they may access application secrets, database credentials and sensitive files, or deploy additional malware, depending on the privileges and configuration of the compromised service.
Although this creates such problems for defenders and incident responders, it also hinders the efforts of threat actors looking to exploit these vulnerabilities at scale; further information on the expected impact is available further down in this blog.
Analysis of the Vulnerabilities
CVE-2026-109618: Unsafe recovery from OOM conditions
The first vulnerability concerns PHP's handling of Out-Of-Memory (OOM) conditions.
Like other programming languages, PHP imposes configurable limits on the amount of memory a script can consume. When a request exceeds its permitted allocation, PHP normally interrupts execution rather than allowing the process to continue allocating memory indefinitely.
Internally, however, PHP has historically handled certain memory allocation failures using a C library mechanism called longjmp().
Unlike a conventional function return, longjmp() transfers execution back to an earlier point in the program, bypassing the normal sequence of function returns. This becomes dangerous when PHP encounters an allocation failure while internal data structures are only partially initialised.
Under these conditions, PHP can abandon an operation without completing the initialisation or cleanup necessary to leave its internal memory in a consistent state.
When request shutdown subsequently runs, PHP may attempt to interpret this invalid memory as legitimate internal data. Attackers able to influence the layout and contents of the process memory can potentially turn this corruption into arbitrary code execution.
How attackers can trigger the vulnerability
Attackers may deliberately exhaust PHP's memory using malicious HTTP requests. Of particular concern here is the handling of requests containing multipart/form-data, normally used when submitting forms and uploading files.
PHP automatically parses this data, and several characteristics of its multipart parser can cause significantly more memory to be allocated than the size of the original HTTP request might suggest.
For example:
Requests without a usable declared content length can bypass the initial
post_max_sizecheck while continuing to supply request-body dataMultipart sections can contain large numbers of headers, whose internal representation consumes substantially more memory than their original encoded form
Empty file-upload controls can escape the normal
max_file_uploadscounter while still causing PHP to allocate metadata arraysDeeply nested form-field names can multiply the memory and processing required to construct PHP's internal arrays
In Apache deployments using mod_php, the situation is particularly serious. PHP's request shutdown procedure runs even when request initialisation fails, allowing the interpreter to encounter corrupted internal state created during the failed startup process.
This makes CVE-2026-109618 exploitable independently of application-level functionality in the demonstrated Apache scenario.
PHP-FPM behaves differently, terminating its worker when request startup fails. Although this prevents the same startup-stage exploit sequence, the advisory does identify other potential paths to exploitation involving memory exhaustion after initialisation has completed - though the advisory itself does not confirm any successful exploit attempt for this CVE against PHP-FPM.
CVE-2026-109619: UAF caused by stale internal state surviving between requests
The second vulnerability, CVE-2026-109619, is a Use-After-Free (UAF) issue involving PHP's internal global state.
Web servers commonly reuse the same PHP worker process to handle multiple HTTP requests. Although memory belonging to an individual request is released when that request finishes, certain internal variables and references remain associated with the longer-lived worker.
PHP must therefore ensure that references to request-specific memory are cleared before that memory is released.
This vulnerability arises when this cleanup does not occur correctly.
An operation can leave a reference to request-owned memory in a global variable, even after the request ends and its memory is freed. When a subsequent request reaches an operation that accesses this reference, PHP may treat the already-freed memory as though it still contains valid data.
How an attacker exploits stale state
The advisory describes exploitation as involving two distinct operations: a producer and a consumer.
The producer is an operation that leaves request-specific state accessible after its memory has been released. This can occur when an unexpected fatal error interrupts an operation before its cleanup finishes, or when a warning or other diagnostic repopulates a state that has already been cleared.
The consumer is an operation in a later request that accesses the stale reference before PHP has completed its normal request initialisation.
An attack therefore follows a general sequence:
An attacker triggers a PHP operation that stores request-owned information in internal global state
A fatal error, memory exhaustion or another abnormal execution path prevents the state from being cleared correctly
The request ends, and PHP frees its associated memory while the worker retains a dangling reference
The attacker sends another request that reaches the same PHP worker
An early initialisation or session-handling operation accesses the stale reference, potentially enabling controlled memory corruption and RCE
Successful exploitation requires the attacker to influence the relevant memory layout and ensure the producing and consuming operations occur within the same persistent worker process.
Session upload progress creates an exploitation opportunity
One particularly important attack surface identified here is PHP's session upload progress functionality.
This feature allows PHP to track file uploads and report progress through session information. Some of its internal operations occur during request-body processing, before normal module and request initialisation has completed. This creates an opportunity for an attacker to trigger session-related operations while stale information from a previous request remains accessible.
The advisory confirms that session upload progress can function as both a producer and consumer of a vulnerable state.
Notably, the feature is enabled by default, and exploitation does not necessarily require the application to explicitly call session_start().
For PHP-FPM, there is a valid path to exploitation involving state produced during application execution, followed by a fatal error and a subsequent request that consumes the stale state through session upload progress.
An additional attack surface in PHP 8.5
An exploitation case involving PHP 8.5's fatal_error_backtraces feature is also mentioned in the advisory. When enabled, this functionality can preserve information about a fatal error in request-owned memory without properly clearing the corresponding global reference during shutdown.
A subsequent request that generates an early configuration diagnostic can access that stale reference before normal initialisation resets it. This has been identified by the PHP maintainers as the basis for confirmed RCE exploitation against Apache mod_php.
Importantly, the diagnostic does not need to appear in an error log or be displayed to the client. Simply suppressing PHP warnings or disabling their output does not eliminate the vulnerability.
Detection and DFIR: What Should Defenders Look For?
Detecting exploitation of these vulnerabilities presents a challenge because the initial attack can occur entirely within PHP's internal request-processing machinery.
Rather than relying on obvious malicious parameters or suspicious PHP scripts, defenders should look for combinations of unusual HTTP activity, PHP execution failures and unexpected behaviour originating from web-server processes. A Sigma rule which helps to identify common processes spawned by attackers after successful exploitation is included in Appendix 1.
However, these indicators are not guaranteed to be present. Standard web-server access logs rarely capture the multipart structures needed to identify malicious requests, while some vulnerable execution paths may generate no visible PHP errors. Successful exploitation could also occur entirely within the PHP worker process, without spawning a shell or writing a malicious file to disk.
Strand’s autonomous investigation system is designed to help organisations and DFIR firms responding to related incidents. Strand works in a reactive manner, without relying on tooling that was in place at the time of the compromise, and can identify attacker activity without relying on known Indicators of Compromise. Contact us at support@strandintelligence.com for more information. This blog will be updated as we develop a deeper understanding of how defenders can investigate and respond to incidents originating from these vulnerabilities.
A Reflection on the AI Threat Actor Landscape
Some reporting and speculation has framed these disclosures as a doomsday event for a significant portion of the internet built on PHP. These are critical vulnerabilities, but the practical risk depends on the PHP build, configuration and application paths available to an attacker.
The disclosures also offer a useful insight into the capabilities and constraints of AI-driven threat actors.
Threat actors who have adopted AI into their workflows can automate exploitation of straightforward vulnerabilities, especially where a public proof of concept is available, and begin scanning rapidly after disclosure.
What these disclosures highlight is the constraints of this workflow. The vulnerabilities discussed in this article are memory-corruption vulnerabilities. Weaponising these can be much more difficult, requiring comprehensive knowledge of the internals of the target platform in order to exploit, with the success rate varying considerably between target instances using different configurations, and some being completely unexploitable.
As a result, we can expect to see far less automated exploitation of these vulnerabilities since the barrier-to-entry is so high; the requirement to re-configure the exploit between targets to account for different architectures and configurations causes significant problems for those seeking to conduct attacks at scale. That is not a reason to delay patching, and it does not rule out targeted attacks or increasing automation as exploit techniques develop.
What Have We Observed So Far?
Since the disclosure of these vulnerabilities, several public proof-of-concept (PoC) exploits have surfaced. However, much of this early code appears to be low-quality, potentially AI-generated material, with poor reliability and limited proof of successful exploitation. This reinforces the challenges we raised earlier: working exploits for memory-corruption vulnerabilities are much more difficult to develop than exploits for more trivial vulnerabilities.
Nevertheless, evidence of some exploitation activity is emerging. Researchers at watchTowr have reported active exploitation attempts targeting both vulnerabilities across their honeypot infrastructure.
Amazon Threat Intelligence identified exploitation attempts against its MadPot honeypot network starting on 17 October 2026, four days before public disclosure. The attempts originated from anonymised, ephemeral infrastructure which raises questions about how the actor obtained knowledge of the vulnerabilities before their official disclosure.
AWS have subsequently observed additional attempts from multiple sources on 21 October, including activity using publicly available PoCs. AWS noted that differences in payloads and infrastructure suggest the involvement of multiple threat actors, and that it remains unclear whether these early attempts would have succeeded against real-world systems.
The following IP addresses are associated with this activity:
103.216.220.92- 17 October 202631.223.184.166- 21 October 202637.19.200.5- 21 October 2026134.209.159.64- 21 October 2026103.114.163.188- 21 October 202695.217.98.37- 21 October 2026
These IP addresses alone are not an indicator of compromise since they belong to anonymous hosting infrastructure, yet they should be treated as leads if they appear in your investigations.
To summarise, with no comprehensive set of IoCs being released, our earlier assessment regarding detection and incident response remains valid; detecting suspicious behaviour originating from PHP worker processes should be the focus. As exploitation techniques mature, we expect both their reliability and the variety of environments they can target to increase. Defenders should consequently treat these vulnerabilities as an evolving threat, even if early attempts prove inconsistent or unsuccessful.
We will continue to monitor this matter and ensure our post is kept up-to-date as our research turns over more information.
Reference Material
Appendix 1 - Sigma Rule
A Sigma rule is provided to help check for exploitation. This rule can be triggered by false positives: it is not intended to provide a consolidated answer as to whether the instance has been compromised by these attacks, but rather to narrow down your search to suspicious processes which could be evidence of attacker activity. It highlights processes often utilised by attackers once they gain initial RCE.
title: Suspicious Child Process Spawned by PHP Web Server
id: 39874b3c-c4d9-4f73-a4ab-741819c647e0
status: experimental
description: >
Detects suspicious command execution utilities spawned by
PHP and web server processes. Such activity may indicate
successful exploitation of a remote code execution (RCE)
vulnerability, including CVE-2026-109618 and CVE-2026-109619.
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
author: Jordan Newman
date: 2026-10-21
tags:
- attack.execution
- attack.t1059
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/php-fpm'
- '/php-fpm8.2'
- '/php-fpm8.3'
- '/php-fpm8.4'
- '/php-fpm8.5'
- '/apache2'
- '/httpd'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/curl'
- '/wget'
- '/python'
- '/python3'
- '/perl'
condition: all of selection_*
falsepositives:
- Legitimate PHP applications that execute shell commands or external utilities.
- Administrative scripts invoked through PHP or web server processes.
level: high