Phoenix Security's analysis

The PHP security team confirmed on October 20, 2026 that it will ship an out-of-band security release on Wednesday, October 21, 2026 at 14:00 UTC (10:00 AM EDT, 3:00 PM BST). The vendor notice confirms two critical vulnerabilities in PHP core, each rated CVSS v4.0 9.2. The remote code execution classification and the identifiers CVE-2026-109618 and CVE-2026-109619 come from researchers and reporting, not from PHP’s published advisory, which so far names neither the CVEs nor a vulnerable function. The notice went out after an embargo break: an anonymous post and follow-on reporting put partial details into the open before the coordinated date, which forced the schedule forward.

watchTowr says both issues are real and that it reproduced one of them in a lab, and it has not observed exploitation in the wild. Lab reproduction is validation, not evidence of active compromise, but the defensive window is still short. Security teams should treat October 21 as a patch-day event and begin host inventory now, before any technical detail or proof-of-concept becomes public.

PHP sits under a large of the internet. Wikipedia, the WordPress and WooCommerce ecosystems, Drupal, and Adobe Commerce storefronts all run on it. A core RCE affecting multiple major branches turns a routine dependency into a direct attack surface across content management, e-commerce, and custom web services at the same time. The exposure problem is made worse by version age: a large population of internet-facing hosts runs end-of-life PHP 5 and PHP 7, and those branches are not expected to receive a fix.

TL;DR for Engineering Teams

What broke: Two critical remote code execution vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2 by the PHP security team. Leaked community reports circulated a higher CVSS 10.0 figure; the official rating is 9.2.

Where it bites: PHP core itself. Leaked reports claim impact back to PHP 5 (unconfirmed); PHP 6 never shipped as a production release, so disregard it in any version list. Upstream fixes will land only on the supported stable branches: 8.2, 8.3, 8.4, and 8.5. PHP 8.0 (end of life November 2023) and 8.1 (end of life December 2025) are not supported upstream and should not be assumed to get a fix.

Why it matters: PHP runs a large fraction of public web applications. Public PoC is not available yet, but researchers have reproduced at least one of the two bugs, and commentators expect exploitation attempts soon after details drop.

Patch status: Not yet released. Scheduled for October 21, 2026 at 14:00 UTC. The team reserves the right to release earlier if details leak further or exploitation is observed.

Immediate action: Inventory every PHP host now, recording the version that actually serves web requests (not just the CLI binary; php_sapi_name() and the PHP_SAPI constant confirm which SAPI handles traffic) and the SAPI type (PHP-FPM, mod_php, php-cgi). Be ready to apply the fixed build the moment it lands, and confirm with your distribution or hosting provider whether their backported package covers both CVEs. Plan migration or isolation for any PHP 5, 7, 8.0, or 8.1 host, which will not get an upstream fix.

Vulnerability Overview

No technical detail has been published. Both CVEs are in reserved status, there is no official advisory text beyond the release notice, and no public proof-of-concept or write-up exists. The root cause, attack vector, and preconditions will arrive with the October 21 release. What follows separates what is corroborated from what is inferred, in keeping with an evidence-first stance.

The PHP security team has confirmed two distinct critical vulnerabilities and a single coordinated release date. The CVE identifiers, CVE-2026-109618 and CVE-2026-109619, trace to watchTowr and the leaked material rather than to the PHP advisory itself, which does not name them. watchTowr states that both are remote code execution flaws and that it reproduced CVE-2026-109618, but it is withholding technical specifics until patches are available. The firm also noted it did not discover the bugs, so credit belongs to the original researchers. A separate reproduction claim attributed to Previdian circulated on social channels but is not corroborated in the primary reporting, which attributes reproduction only to watchTowr (VERIFY: single-source social claim).

What is inferred or unconfirmed

Leaked reports describe the affected range as reaching back to PHP 5. That range is unconfirmed, the official notice lists no affected versions, and PHP 6 should not appear in any version list because it was never released as a production branch. The CVSS 10.0 figure circulating on social platforms is higher than the official 9.2 and should be treated as unverified; the available reporting does not explain why the two figures differ, so the gap is not a formal reassessment or downgrade. A now-removed Hacker News post initially cited an October 22 disclosure date, which the PHP team’s own notice supersedes with October 21.

more information under #php2shell

Circulating exploit claims (unverified)

A purported proof-of-concept bundle is circulating that attributes the flaw to two heap use-after-free primitives in PHP’s session.upload_progress handler (php_session_rfc1867_callback in ext/session/session.c), reachable under default configuration through a multipart upload. The author’s own analysis holds that one path runs through the upload-progress handler and a second sits in the multipart parser itself, which executes for any multipart/form-data POST whether or not upload progress is enabled. Treat the claim as unverified, and treat the bundle itself as potentially hostile rather than as research tooling. The path from the use-after-free to code execution is asserted, not demonstrated: the memory grooming, chunk reclamation, and address-layout defeat that a real heap-UAF-to-RCE chain requires are not shown, the CVE mapping cannot be confirmed because PHP has published no technical detail for either identifier, and no vendor has corroborated the root cause. The material ships as a downloadable archive from a third-party host with a published hash and contributor handles; do not fetch or run it outside an isolated, disposable environment, and treat the host and hash as indicators rather than trusted tools.

None of this changes the defensive posture. Two precautions are safe, reversible, and worth applying now regardless of whether the claim holds. Disable the upload-progress handler by setting session.upload_progress.enabled = Off in php.ini, .user.ini, or .htaccess and reloading PHP-FPM; by the author’s own account this closes only one of the two suspected paths. Close the other at the edge: rate-limit or inspect multipart/form-data POSTs at the WAF or reverse proxy for endpoints that do not accept uploads, since the second suspected path lives in the multipart parser and runs for any multipart POST regardless of the upload-progress setting. Both shrink a plausible attack surface without waiting on the official fix.

Why exploit mechanics matter here

A core-interpreter RCE differs from a single-package supply chain compromise in one important way: the vulnerable code is the runtime, not a dependency you chose. Any request path that reaches the interpreter under the wrong conditions becomes a candidate trigger. Until the patch and diff are public, teams cannot build a precise detection signature, which is why exposure reduction and rapid patch readiness are the only reliable controls in the pre-disclosure window.

The coordinated disclosure was scheduled to hold until later in the week; watchTowr expected the embargo to run to Thursday at 11:00 AM ET. On October 20 an anonymous post citing a reliable source surfaced on Hacker News and spread through screenshots on X and Mastodon. Security researcher Florian Roth amplified the story with a post describing an RCE in PHP core at CVSS 10.0, saying details were due October 20 and that only PHP 8 would be patched; that post drew roughly 53,000 views (VERIFY: view count from originating social post).

watchTowr CEO Benjamin Harris said the information leaked within the hour and confirmed the vulnerabilities are real, while noting no in-the-wild exploitation had been observed. The PHP security team responded with its advance notice and pulled the release forward to October 21 at 14:00 UTC, reserving the right to move earlier still. Two reporting errors spread alongside the real details and are worth flagging to avoid mis-citation: watchTowr’s initial post misprinted the CVE year as “CVE-2926,” later corrected, and several posts quoted 9:00 AM EDT rather than the correct 10:00 AM EDT for the 14:00 UTC release. Researcher Nicolas Krassas has said he plans to publish a lab on the bugs once the embargo lifts (VERIFY: single-source).

Official affected and fixed versions will publish with the release. The table below records what has been reported, with confidence marked. Nothing here should be treated as an official version list until October 21.

The installation base is large. One Shodan-based assessment counted roughly 2.23 million hosts advertising an X-Powered-By: PHP banner, 1.5 million of which disclose a version. Of the versioned hosts, 883,717 ( 59 percent, rounded to ~884,000) run a branch that will receive no fix, and PHP 5.x and 7.x alone account for 697,928 hosts. Around 740,000 additional hosts hide their version, so the true unpatched population is almost certainly higher. These figures are single-sourced and should be treated as directional (VERIFY: single external source). A low disclosed-version count does not imply low risk; it often means the opposite.

Provider and country concentration matters for triage. The same assessment put the largest unpatched host counts in the United States (228,770), China, Japan (55,460), and Germany (45,835), with Amazon, Hostinger, and Alibaba Cloud hosting the largest total PHP populations. Shared hosting means the count of affected websites runs well above the count of affected hosts.

PHP’s install base is the story. A working core RCE against supported branches would expose content management systems, e-commerce storefronts, and bespoke web applications through the same bug class at once. The practical attack scenarios follow from that: account takeover on CMS and commerce platforms, theft of application and cloud credentials from compromised hosts, pivoting from a web host into internal networks, and web-shell persistence in writable web roots.

The pre-disclosure timing raises the stakes. Researchers have reproduced at least one of the two bugs, the diff will be public the moment the patch ships, and historically attackers reverse-engineer security patches within hours. The end-of-life population is the hardest part of the exposure: nearly 700,000 internet-facing hosts on PHP 5 and 7 cannot be patched and will remain exploitable indefinitely unless they are upgraded or taken offline.

Precise signatures are not possible before the patch diff is public. Until then, detection should focus on post-exploitation behavior rather than the trigger.

Behavioral indicators

Watch for unexpected child processes spawned by the web server or PHP-FPM worker (for example, a shell, curl, wget, or a package manager launched from an php-fpm or apache2 parent). Watch for new or modified files appearing in web roots, especially single-file PHP scripts with obfuscated content. Watch for outbound connections from web hosts to previously unseen destinations immediately after an inbound request burst. A memory-corruption exploit usually crashes before it works, so a rise in PHP-FPM worker segfaults or restarts correlated with multipart/form-data POSTs is an early signal worth alerting on.

Scanner and inventory references

Use Phoenix Security scanners and SCA/SBOM analysis to enumerate PHP runtime versions across repositories, build images, and running workloads, not just application dependencies. Pull external attack surface data to find internet-facing hosts advertising PHP, including those on managed and shared hosting that your internal inventory may miss. GitHub dependency and container scanning can surface pinned PHP base images in Dockerfiles and CI definitions.

Download the Phoenix Security campaign configuration

Verification steps for teams

Enumerate every PHP interpreter in the estate: OS packages, container base images, custom builds, and shared or managed hosting. Record the version that actually serves web requests, not just the CLI binary, since the two can differ on the same host; php_sapi_name() and the PHP_SAPI constant confirm which SAPI is handling traffic. Record major version and SAPI type (PHP-FPM, mod_php, php-cgi).

Cross-reference that inventory against internet exposure using attack surface management, so the patch order follows real reachability.

Flag all PHP 5, 7, 8.0, and 8.1 hosts as no-fix and route them to a migration or isolation track.

Confirm you can apply and restart the supported PHP 8 patch on October 21 within hours, not days, on the internet-facing tier.

On supported branches (8.2, 8.3, 8.4, 8.5), patch at the October 21, 14:00 UTC release and restart PHP-FPM or the web server so the new interpreter is loaded. Rumored fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, each the point release above the current stable builds (8.5.11, 8.4.26, 8.3.35, 8.2.34); all of these are single-source and unconfirmed (VERIFY: confirm against the official release notes before acting). If PHP is installed from a Linux distribution or a managed host, the fix may arrive as a backported package revision rather than a new upstream version, so confirm the provider’s CVE advisory and fixed package and do not judge exposure by the major-version label alone. Prioritize internet-facing hosts first, then CI runners and cloud workloads. Be ready for an earlier-than-scheduled release, since the team has reserved that option.

On unsupported branches (PHP 5 and 7, and the end-of-life 8.0 and 8.1), no upstream fix is coming. Upgrade to a supported PHP 8 branch, or if an immediate upgrade is not possible, restrict access with a VPN or IP allowlist, place the host behind a hardened reverse proxy, or take it offline. Note that PHP 8.2 itself reaches end of security support on December 31, 2026, so treat a jump to 8.2 as a stopgap rather than a destination.

Temporary mitigations if patching is delayed

Two precautions are safe to apply now, independent of the unverified PoC above. Set session.upload_progress.enabled = Off in php.ini, .user.ini, or .htaccess and reload PHP-FPM; this addresses only one of the two suspected paths. Separately, rate-limit or inspect multipart/form-data POSTs at the WAF or proxy for endpoints that do not accept uploads, which covers the second suspected path in the multipart parser that runs for any multipart POST regardless of that setting. Beyond that, have WAF rules staged and ready to deploy the moment indicators are known; generic request-anomaly rules add little before the mechanism is public. Reduce the reachable surface by disabling unused PHP endpoints and SAPIs. For php-cgi deployments specifically (not PHP-FPM), one unmerged php-src change (PR #23411) has been compared to CVE-2019-11043, though it is unconfirmed and not yet linked to these two CVEs; if you run php-cgi, test and set cgi.fix_pathinfo=0, add try_files $fastcgi_script_name =404; on nginx, or move to PHP-FPM (VERIFY: single-source, speculative association). Query vendors and hosting providers appliances and managed stacks that bundle old PHP outside your direct control.

Phoenix Security Recommendations

Download the Phoenix Security campaign configuration

A core-runtime vulnerability with no public signature is exactly the case where exposure context beats raw CVE counts. Phoenix Security correlates PHP runtime findings across scanners into a single deduplicated backlog, so a host that shows up in SCA, container scanning, and external attack surface data becomes one prioritized item rather than three disconnected alerts.

Reachability analysis identifies which PHP interpreters are actually internet-facing and in the live request path, so remediation follows real exposure instead of a flat version sweep. Attack surface management finds the external hosts advertising PHP, including the shared and managed hosting that internal inventories routinely miss, which is where the end-of-life population concentrates. From there, a remediation campaign turns the response into owned, trackable work: create the campaign, assign owners by service, track patch status against the October 21 release, and verify runtime exposure once hosts are updated. Vulnerability ownership attribution maps each PHP host to the responsible team automatically, which matters when the fix window is measured in hours.

The companion PHP Exposure campaign described alongside this article is built for that first step: it surfaces every asset where a PHP library is detected, targeting the resource list rather than specific CVEs, so teams get an exposure inventory ready before the signatures exist.

Protect yourself with the latest threat intelligence, get free access to Phoenix Blue Today

PHP Foundation, “Upcoming Critical PHP Security Release,” php.net / PHP Foundation Discourse, October 20, 2026.

BleepingComputer, “PHP warns admins of two critical flaws, emergency patches coming tomorrow,” October 20, 2026.

watchTowr, “PHP Remote Code Execution FAQ: CVE-2026-109618 and CVE-2026-109619,” October 2026.

Threat Landscape Blog, “PHP Core RCEs CVE-2026-109618 and CVE-2026-109619 Leak Early,” October 2026.

Cyber Kendra, “PHP RCE Zero-Days CVE-2026-109618, CVE-2026-109619 Leak Early,” October 2026.

Mallory.ai, “PHP Remote Code Execution (RCE): 884K Hosts Get No Fix,” October 2026 (exposure telemetry, single-source).

PHP, “Supported Versions,” php.net/supported-versions.php (8.2 through 8.5 supported).

PHP, “Unsupported Branches,” php.net/eol.php (8.0 EOL Nov 2023, 8.1 EOL Dec 2025).

PHP, “History of PHP and Related Projects,” php.net/manual/en/history.php (PHP 6 never released).

PHP, “Command line usage,” php.net/manual/en/features.commandline.php (CLI vs web SAPI; php_sapi_name / PHP_SAPI).

Ubuntu, “Security updates” (fixes delivered as backported patches).

WordPress and Adobe Commerce platform requirements (both depend on the PHP runtime).

NVD/MITRE: CVE-2026-109618, CVE-2026-109619 (reserved; descriptions pending).