CVE-2026-109619: PHP RCE Vulnerability and Fix
Active exploitation confirmed in CISA KEV.
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-10-26. Federal agencies must patch by 2026-10-29.
TL;DR - CVE-2026-109619 is a critical PHP use-after-free flaw that can enable unauthenticated remote code execution. - PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, and 8.5 before 8.5.12 are affected. - CISA lists the vulnerability in KEV; patch internet-facing PHP immediately and investigate exposed workers.
CVE-2026-109619 is an actively exploited PHP remote code execution vulnerability caused by stale internal request state. The flaw can affect Apache mod_php and PHP-FPM deployments, particularly where persistent workers process multiple requests. Administrators should upgrade affected PHP branches, restart the relevant services, verify the runtime serving requests, and investigate systems exposed before patching.
For background on endpoint detection and response, see our EDR glossary. Teams should also review their identity and access management controls during post-exploitation investigations.
Summary
CVE-2026-109619 affects PHP’s handling of internal request state. Under specific request-processing conditions, PHP global state can retain pointers to memory associated with a request after that memory has been freed. A later request handled by the same worker may access the stale state before normal initialization replaces it, creating a use-after-free condition that can lead to remote code execution.
The PHP security team reported that unauthenticated exploitation was demonstrated against both Apache mod_php and PHP-FPM. Exploitability still depends on worker reuse, server configuration, and application behavior; the issue is not necessarily exploitable in every deployment. The vulnerability still warrants emergency treatment because CISA added it to the Known Exploited Vulnerabilities catalog on October 26, 2026.
| Field | Assessment |
|---|---|
| CVE | CVE-2026-109619 |
| CVSS | NVD: 8.1; PHP advisory: CVSS v4.0 9.2 |
| Attack vector | Network-based remote exploitation is indicated; the NVD vector string was not available in the supplied record |
| Authentication | Unauthenticated exploitation was demonstrated in PHP advisory material |
| Privileges required | Not published in the supplied NVD vector data; defenders should assume no application account is required |
| Vulnerability class | Stale internal request state / use-after-free leading to RCE |
| Patch status | Yes |
| CISA KEV | Yes; added 2026-10-26, remediation deadline 2026-10-29 |
| Ransomware use | Unknown |
The different severity values are not necessarily contradictory. NVD reports a CVSS base score of 8.1, while the PHP security announcement reports CVSS v4.0 9.2. The scoring systems and assessment inputs may differ. For response planning, the KEV listing and demonstrated unauthenticated RCE matter more than reconciling the scores.
Analyst’s Take: Patch internet-facing PHP workers first, then verify that the updated runtime is the one serving requests. KEV inclusion and demonstrated unauthenticated exploitation justify incident review for systems exposed before patching, even though the exact public exploit chain has not been established.
Root Cause
PHP maintains global state that can temporarily point into memory allocated for an individual request. The reported flaw occurs when that state is not completely reset, or when it is repopulated after reset, leaving a pointer or related state reference aimed at memory that has already been released.
A subsequent request processed by the same persistent worker can read or branch on stale state before the request has been fully initialized. This is a classic lifetime-management failure: the memory is no longer valid, but code continues to treat the associated reference as usable. Depending on the resulting memory layout and execution path, an attacker may influence behavior sufficiently to obtain code execution.
The issue is especially relevant to persistent execution models. Apache workers using mod_php and PHP-FPM pools can process multiple requests over the lifetime of a process. That reuse creates the conditions under which state left by one request may affect a later request. The PHP advisory indicates that multiple strategies can trigger the condition, so blocking one known request pattern does not eliminate the risk.
Technical Notes
The supplied NVD description characterizes the vulnerable behavior as follows:
PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed.
This is a PHP engine vulnerability rather than an application-level input-validation defect. Changing application code, adding a generic WAF rule, or restricting one endpoint is not a complete remediation. Those controls may reduce exposure in a particular application, but they do not correct the unsafe state handling inside the PHP runtime.
Who’s Exposed
The PHP security-team advisory identifies these affected supported branches:
| PHP branch | Affected versions | Fixed version |
|---|---|---|
| PHP 8.2 | Before 8.2.35 | 8.2.35 |
| PHP 8.3 | Before 8.3.36 | 8.3.36 |
| PHP 8.4 | Before 8.4.27 | 8.4.27 |
| PHP 8.5 | Before 8.5.12 | 8.5.12 |
Upgrade to the listed version or a later release in the same supported branch. The affected component may not appear as a standalone PHP installation. It can be embedded in an Apache server, PHP-FPM service, container image, hosting control panel, CMS stack, vendor appliance, or managed platform.
Third-party research has described the underlying issue as potentially affecting older PHP installations dating back to PHP 5.4. That broader range is not established by the primary PHP security announcement supplied for this assessment. Unsupported PHP 5.x, 7.x, and earlier 8.x installations should nevertheless be treated as exposed unless the operating-system distributor or product vendor confirms a backported fix.
Technical Notes
Inventory both packages and runtime processes. Useful checks include:
php -v
php-fpm8.2 -v 2>/dev/null || true
ps -eo pid,ppid,user,args | grep -E '[p]hp(-fpm|:)?|[a]pache2|[h]ttpd'
apachectl -M 2>/dev/null | grep -i php || true
For containerized environments, inspect image manifests and running containers rather than relying only on the host:
docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}'
docker image ls
docker exec <container> php -v
Package names vary by distribution. Confirm the actual runtime version used by the web server. A patched command-line PHP binary does not prove that an older PHP-FPM pool or Apache module has been restarted and updated.
Severity Breakdown
CVE-2026-109619 has an NVD CVSS base score of 8.1. The supplied NVD record does not expose the complete vector string, so the individual NVD metric values cannot be stated reliably. Defenders should not infer exact values for attack complexity, privileges required, user interaction, scope, confidentiality, integrity, or availability from the score alone.
The PHP security-team announcement cited in the Openwall advisory reports CVSS v4.0 9.2 and classifies the issue as critical. The operational impact is consistent with a high-severity server-side vulnerability: an attacker may send requests to a reachable PHP service, trigger unsafe state reuse, and potentially execute code in the context of the PHP worker or associated web-service account.
The practical severity is increased by several factors:
- Exploitation can be unauthenticated according to the advisory material.
- The affected software is commonly exposed through public web services.
- PHP-FPM and persistent Apache workers may process many requests without restarting.
- CISA KEV inclusion confirms known exploitation in the wild.
- The vulnerable behavior occurs in the runtime, before normal application defenses can necessarily intervene.
The KEV catalog marks ransomware use as Unknown. This does not confirm ransomware deployment, but it also does not rule it out.
Exploitation Status
In-the-wild exploitation is confirmed at the catalog level. CISA added CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on October 26, 2026, with a remediation deadline of October 29, 2026. Organizations subject to applicable CISA requirements should follow the catalog entry, BOD 26-04 guidance, and relevant forensic triage requirements.
Secondary reporting identified claims that multiple proof-of-concept exploits were deployed from VPN IP addresses shortly after disclosure and that researchers demonstrated exploitation paths. Those reports provide useful context but are not a substitute for primary advisory material or validated incident evidence. The supplied primary references do not establish a specific public exploit repository.
Accordingly, the defensible status is:
| Question | Status |
|---|---|
| Exploited in the wild? | Yes, based on CISA KEV inclusion |
| Public PoC repository confirmed? | Not established from the supplied primary references |
| Unauthenticated exploitation demonstrated? | Yes, according to PHP advisory material |
| Ransomware use confirmed? | No; CISA records it as Unknown |
Security teams should not wait for a reproducible public exploit to begin response. KEV inclusion means internet-facing unpatched systems require immediate prioritization, even if the exact exploit chain used by attackers is not publicly documented.
Sources
-
PHP GitHub security advisory:
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp -
Openwall
oss-securityadvisory discussion:
http://www.openwall.com/lists/oss-security/2026/10/21/16 -
Additional Openwall references:
http://www.openwall.com/lists/oss-security/2026/10/21/17
http://www.openwall.com/lists/oss-security/2026/10/21/23
http://www.openwall.com/lists/oss-security/2026/10/21/7 -
PHP 2026 news archive and security releases:
https://www.php.net/archive/2026.php -
CISA Known Exploited Vulnerabilities catalog:
Consult the current CISA KEV entry for CVE-2026-109619, remediation requirements, and any subsequent updates.
CVE-2026-109619 should remain an active incident-priority item until every exposed PHP runtime is upgraded, restarted, verified, and reviewed for post-exploitation activity. Start with internet-facing workers, confirm the service context is patched, and then investigate those exposed before the fix was deployed.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Detection should combine version discovery, web-server telemetry, process monitoring, and outbound network analysis. No single HTTP signature should be considered authoritative because the vulnerable condition depends on internal state, worker reuse, and application behavior. A request that appears ordinary at the web layer may still participate in an exploit sequence.
Prioritize systems that were internet-facing between the October 21 disclosure and patch deployment. Review PHP-FPM pools and persistent Apache workers for unexpected child processes, shell execution, downloaded files, new scheduled tasks, credential access, and outbound connections from service accounts. Preserve logs before restarting compromised workers when feasible, because restarting can destroy volatile evidence.
Technical Notes
A useful Linux audit query for suspicious process creation by common web-service accounts is:
ausearch -m EXECVE \\
-ts 2026-10-21 \\
-ua www-data \\
| grep -Ei '(/bin/sh|/bin/bash|curl|wget|nc|ncat|python|perl|php|chmod|chown)'
Adapt the account and time range to the environment. On systems using httpd, apache, or a vendor-specific account, query those identities as well.
Example process-monitoring logic for EDR or SIEM correlation:
process.parent.name IN ("php-fpm", "apache2", "httpd")
AND process.name IN ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python", "perl")
Also investigate web-server records around suspicious process events. A generic Apache or NGINX access-log pattern worth correlating is:
<timestamp> <client-ip> "<method> <uri> <protocol>" <status> <bytes>
Look for requests immediately preceding PHP worker anomalies, particularly unusual POST bodies, repeated requests from the same source, unexpected methods, encoded parameters, and sequences followed by 5xx responses or worker restarts. This pattern is a triage heuristic, not a confirmed exploit signature.
For network monitoring, alert when a PHP-FPM, Apache, or HTTP service process initiates unexpected outbound connections. Example Sigma-like logic:
selection:
ParentImage|endswith:
- '/php-fpm'
- '/apache2'
- '/httpd'
Image|endswith:
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
condition: selection
Validate executable paths and process ancestry for the operating system. False positives are possible where applications legitimately invoke command-line tools, but such activity should be rare and attributable.
Remediation Steps
Upgrade supported PHP installations immediately:
- PHP 8.2 to 8.2.35 or later
- PHP 8.3 to 8.3.36 or later
- PHP 8.4 to 8.4.27 or later
- PHP 8.5 to 8.5.12 or later
After upgrading, restart the service that actually executes PHP and verify the runtime version from that service context. A package update without a worker restart may leave vulnerable processes running.
Technical Notes
For Debian or Ubuntu systems using distribution packages, first determine the package source and available version:
apt-cache policy php8.2-fpm php8.3-fpm php8.4-fpm php8.5-fpm
sudo apt update
sudo apt install --only-upgrade php8.2-fpm
sudo systemctl restart php8.2-fpm
Use the branch and package names provided by the operating-system repository. Do not substitute a package version that the repository has not verified as containing the fix.
For RPM-based systems:
dnf check-update 'php*'
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
Confirm the installed version and service state:
php -v
systemctl --no-pager --full status php-fpm
systemctl --no-pager --full status php8.2-fpm 2>/dev/null || true
For containers, rebuild from a base image containing a fixed PHP release and redeploy rather than modifying only the running container:
docker build --pull -t example-app:php-fixed .
docker run --rm example-app:php-fixed php -v
If the application uses a vendor appliance, hosting platform, or managed PHP service, obtain the provider’s specific fixed build and verify its underlying PHP version. Unsupported branches require a vendor backport or migration to a supported branch. If neither is available, remove the service from the internet or discontinue its use where required by applicable policy and CISA guidance.
The PHP project states that there are no complete mitigations and that updating is the safe remediation. Worker recycling, reducing exposure, disabling selected endpoints, or placing a WAF in front of the service may reduce risk temporarily, but these measures do not repair the vulnerable runtime. Treat systems that were exposed before patching as potentially compromised and perform incident response, not just version remediation.