PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Patch the PHP Runtime, Harden What You Can’t

What changed

PHP released fixes on 21 October at around 13:30 UTC (19:00 IST), ahead of the scheduled 14:00 UTC. The emergency releases (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35) fix two critical vulnerabilities in the PHP engine. The researchers who found them call the pair “PHP2Shell”. PHP rates both 9.2 on CVSS v4.0 and says both “can allow unauthenticated remote code execution”.

The release was brought forward by a day. On 20 October, a post on Hacker News leaked the existence of the flaws ahead of a planned 22 October disclosure. PHP then published an advance notice and moved the release to 21 October. Early coverage, including The Hacker News’ first report, was written while the flaws were still unpatched. That has now changed for supported branches. It has not changed for PHP 8.1 and older, which the PHP project no longer supports.

The flaws were found by Wiz Research, Calif and OpenAI’s security researchers. Wiz says it reported them to the PHP security team on 24 August 2026.

Both issues are in PHP itself, not in WordPress, Drupal or any other application. A well-written site on a vulnerable PHP runtime is still exposed. At a high level:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) is memory corruption in PHP’s out-of-memory error handling. A request interrupted at the wrong moment can leave internal data half-initialised, and cleanup then treats it as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) is a use-after-free. Request-owned state can outlive the memory behind it, and a later request on the same worker can touch that stale state. PHP lists the impact as unauthenticated use-after-free, memory disclosure and remote code execution with the web worker’s privileges.

Note: Wiz’s write-up assigns the two CVE numbers the other way round; this post follows PHP’s own advisories.

Wiz also describes the ability to read memory from the PHP worker process. That memory can hold passwords, session tokens, API keys and certificates belonging to other requests.

Who is affected

According to PHP, every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates Apache mod_php setups as highest risk, as an unauthenticated request can be enough. For PHP-FPM, PHP’s advisories say source analysis supports susceptibility to CVE-2026-109618, though no complete FPM exploit has been shown for that flaw. For CVE-2026-109619, an exploit was validated against FPM, but that path depends on an application operation.

Wiz and Google Cloud put the affected range at PHP 5.4 through 8.5.11, with every PHP release of the last decade affected by at least one of the issues. Wiz demonstrated pre-authentication code execution against default deployments of WordPress, Drupal and Joomla. It stresses that these were sample targets, not prerequisites.

Do not limit the inventory to your own web servers. PHP is often hidden inside:

• vendor appliances and management consoles that bundle a PHP runtime
• hosting control panels such as cPanel and Plesk
• container images built months ago and never rebuilt
• Windows software that ships its own php.exe or php-cgi.exe

Updating WordPress or another application does not update the PHP runtime beneath it.

Vendors are now naming affected products, and their lists are still changing. Palo Alto Networks lists PAN-OS on PA-Series and VM-Series firewalls and on Panorama. The flaw affects the management web interface (web UI and XML API), not GlobalProtect or the captive portal, and Palo Alto is releasing hotfixes on a rolling schedule, with some estimated for 29 and 30 October. Cisco lists Expressway and Expressway Select, Ultra-Reliable Wireless Backhaul (where an attacker must be authenticated as an administrator) and Duo Access Gateway (fixed in 3.2.0), and documents workarounds for Expressway and Ultra-Reliable Wireless Backhaul. Palo Alto Networks says it has observed very limited exploitation targeting its management interface and now rates the issue critical with the highest urgency. Cisco’s advisory says its security team is not aware of malicious use against its products. Restrict management interfaces to trusted networks and follow the vendors’ advisories.

Affected and fixed versions

Linux distributions and LTS vendors received the patches in advance. A distribution package may carry the fix under an older-looking version string, so check the package changelog for the CVE IDs rather than trusting php -v alone.

What’s known about exploitation

The status as of 27 October 2026 (IST):

• Successful code execution confirmed, on honeypots. A Perplexity researcher reported that on 24 October their honeypots (PHP 8.4.26 under Apache mod_php, a single worker) recorded 35 shells launched across three sensors from two IP addresses, in traffic that closely matched a public proof of concept. No second-stage download was seen. They cautioned that this setup was deliberately favourable and says nothing about reliability on other configurations. A threat researcher at Expel called it “by far the highest quality confirmation of in-the-wild PHP2Shell exploitation” they had seen so far (SecurityWeek and BleepingComputer, 26 October).
• Attempts started before disclosure. Amazon Threat Intelligence says its MadPot honeypots recorded a PHP2Shell exploitation attempt on 17 October 2026, from a commercial anonymisation network, four days before the fixes were published. On 21 October it saw further attempts from multiple actors, both before and after the release, and it now describes PHP2Shell as “broadly exploited in the wild”. Amazon says it is unclear whether any of these attempts would have succeeded against real systems.
• Exploitation attempts are reported. Before the patches shipped, Cloudflare’s CTO said the company was “seeing early attacks emerging” and had deployed WAF rules as a stopgap. watchTowr’s FAQ, updated on 21 October, lists both CVEs as exploited in the wild based on its honeypot network. Earlier that day, as of 11:26 UTC, watchTowr had reported no exploitation.
• Other telemetry. Hadrian reported exploitation “at scale” a few hours before the patches landed (via SecurityWeek). watchTowr said attempts hit its sensors as the fixes shipped, but none had succeeded. VulnCheck (via Tanium) reproduced both flaws and found that reliable code execution depends on the platform and how the system is hardened, and that most public proof-of-concept code did not work when it tested it.
• Scale of attempts. Check Point Research reports that attack traffic rose from thousands to millions of attempts after disclosure, and that about 97.5% of publicly visible PHP instances did not show a patched version as of 23 October.
• No compromise of a real organisation has been confirmed in the reporting we checked. We have not found a public report from a vendor, CERT or incident responder naming a victim. Palo Alto Networks says it has observed very limited exploitation targeting its management interface, without giving details. Huntress said it had not seen exploitation across its customer base as of 10:00 ET on 21 October. Several organisations, including BambooHR and a number of Dutch government services, went offline as a precaution, not because of a known breach.
• Now in CISA KEV. CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalogue on 26 October 2026 (catalogue version 2026.10.26), with a federal remediation due date of 29 October. Both entries are flagged for forensic triage under BOD 26-04, which means US federal agencies must check whether systems were compromised before they were patched, not only patch them. Ransomware use is listed as unknown. CISA’s 21 October alert, updated on 26 October, still urges immediate patching.
• Proof of concept. The researchers built and demonstrated a working exploit. Public proof-of-concept code began circulating around the release. VulnCheck found that most of it did not work, but the traffic recorded on honeypots on 24 October closely matched a public proof of concept, so assume working exploit code is available to attackers. Tenable notes that some code claiming to exploit the flaws is unverified and may contain malware.

There is no attribution to any threat actor. We will update this post if intrusions at real organisations are confirmed.

Defensive steps, in order

1. Patch the runtime, then restart. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor’s backported package. Restart Apache, PHP-FPM and any long-running PHP workers, because a running worker keeps the old code until it is restarted. Rebuild and redeploy container images rather than patching running containers. Start with internet-facing systems, and with Apache mod_php setups, which PHP rates highest risk. Patching does not undo an earlier compromise, so check the host as well (step 4).

2. Deal with end-of-life PHP. For PHP 8.1 and older, upgrade to a supported branch or use a vendor backport. If you can do neither quickly, CERT-EU advises isolating affected servers and the UK NCSC says to consider taking them offline; Huntress suggests placing them behind a VPN as an alternative. CISA says systems that cannot be updated immediately, or that still run PHP 8.1 or earlier, should be taken offline until they are patched or updated, and that a web application firewall may give some protection in the meantime.

3. If you can’t patch today, apply PHP’s interim settings. PHP is clear that these reduce exposure to specific paths and do not make a server safe:

• For CVE-2026-109618, set memory_limit=-1 administratively (for example with php_admin_value) so applications can’t override it, and keep post_max_size low (8M without uploads, 32M with). Enforce request-size limits at the web server or reverse proxy. Use a container or cgroup limit as an availability boundary. Do not substitute RLIMIT_AS or RLIMIT_DATA.
• For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, not with ini_set() or .user.ini, and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0. Remove invalid or deprecated per-request INI settings. Hiding diagnostics with error_reporting or display_errors does not help.
• Put internet-facing PHP behind a WAF with the vendor’s PHP2Shell rules, but treat that only as a stopgap.

4. Hunt from the defender’s side. These flaws sit below the application, so application logs may say little. Start from 17 October, not the disclosure date: Amazon recommends scoping investigations from at least that day. Look for PHP worker crashes, segmentation faults, spikes in memory-limit errors and unusually large multipart requests. Also look for signs of compromise:

• PHP worker processes (php-fpm, php-cgi, httpd, apache2) starting shells, script interpreters or download tools (CISA flags this too, and its alert links a Sigma detection rule)
• unexplained PHP worker churn or restarts
• new files in the web root, web shells, new cron jobs, scheduled tasks or accounts

If you find something, isolate the host and preserve web server, PHP and proxy logs before you rebuild.

5. Rotate what the worker could see. Because memory disclosure is possible without code execution, treat anything held in PHP worker memory on an exposed, unpatched server as potentially exposed. That includes database credentials in application config, API keys, signing secrets and active sessions. Prioritise rotation where you see the signals above.

6. After patching, check memory settings. The fix adds a hard memory threshold that ends the process without running shutdown handlers. Review memory_limit and post_max_size against what your applications actually need. PHP also suggests leaving session upload progress off if you don’t use it.

How a penetration test helps

PHP2Shell is a runtime problem, so the usual “is our CMS up to date?” check misses it. An authorised external and internal assessment from PoCForge can find PHP runtimes you didn’t know you had, including in appliances, control panels, old containers and shadow IT. It can confirm patch levels from the outside, check that interim hardening and WAF rules are in place, and test whether a compromised web worker could reach databases, secrets or the internal network. That last point shows how much damage the next runtime-level flaw could do. We do not run exploit code against production systems for this; findings are based on version, configuration and exposure checks agreed in scope.

Sources

• PHP security advisory and releases, 21 Oct 2026
• PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• PHP fix commit
• Wiz Research, “PHP2Shell”
• Google Cloud guidance
• UK NCSC alert
• CERT-EU security advisory 2026-018
• NCSC-NL operational repository
• CERT-FR alert CERTFR-2026-ALE-014
• watchTowr FAQ
• Huntress rapid response
• Tenable FAQ
• The Hacker News (pre-release report)
• The Hacker News (post-release report)
• BleepingComputer
• Amazon Threat Intelligence (AWS Security Blog), 21 Oct 2026
• CISA alert, 21 Oct 2026 (updated 26 Oct)
• SecurityWeek, 21 Oct 2026
• Tanium, PHP2Shell response (VulnCheck findings)
• CISA, Known Exploited Vulnerabilities additions, 26 Oct 2026
• SecurityWeek, 26 Oct 2026 (honeypot report)
• BleepingComputer, 26 Oct 2026 (honeypot report)
• Check Point Research, threat intelligence report, 26 Oct 2026
• Palo Alto Networks security advisory (PHP2Shell and Palo Alto Networks products)
• Cisco Security Advisory, Vulnerabilities in PHP Affecting Cisco Products
• CISA KEV catalogue (checked 27 Oct 2026, version 2026.10.26)

PoCForge publishes offensive-security research to explain attack paths and defensive controls. This article summarises public advisories and reporting only; it is not an exploit guide and does not describe a named client engagement.