Executive Summary
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). The release fixes two critical vulnerabilities in PHP core, tracked as CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2. The advance 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.
Both issues are reported as remote code execution. Independent researchers say they are real and reproducible, and the defensive window is 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 share 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 the flaws reach PHP 5, 6, 7, and 8 (unconfirmed). Official fixes are expected only for supported PHP 8 branches.
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, record the major version and the SAPI (PHP-FPM, mod_php, php-cgi), and be ready to apply the supported PHP 8 patch the moment it lands. Plan migration or isolation for any PHP 5 or PHP 7 host, which will not get a fix.
Vulnerability Overview
| Field | Value |
|---|---|
| Vendor | The PHP Group / PHP Foundation |
| Product | PHP (core interpreter) |
| Vulnerability Type | Remote Code Execution (reported) |
| CWE | Not disclosed (reserved) |
| CVSS Score | CVSS v4.0 9.2 (official); 10.0 cited in leaked reports |
| CVE | CVE-2026-109618, CVE-2026-109619 |
| Patch Available | No. Scheduled October 21, 2026, 14:00 UTC |
| Active Exploitation | Not confirmed in the wild at time of writing |
Technical Anatomy
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.
What is corroborated
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. At least one additional researcher, Previdian, is reported to have reproduced the issues (VERIFY: single-source, attributed by the originating report).
What is inferred or unconfirmed
Leaked reports describe the affected range as PHP 5 through 8. That range is unconfirmed, and the official notice lists no affected versions. The CVSS 10.0 figure circulating on social platforms is higher than the official 9.2 and should be treated as unverified. A now-removed Hacker News post initially cited an October 22 disclosure date, which the PHP team’s own notice supersedes with October 21.
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 Embargo Leak
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).
Affected Versions
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.
| Package | Vulnerable Versions | Fixed Version | Notes |
|---|---|---|---|
| PHP core | PHP 5, 6, 7, 8 (leaked, unconfirmed) | Supported PHP 8 branches (expected) | Official list pending; PHP 5 and 7 are end-of-life |
| PHP 8.2–8.5 | Pending official confirmation | 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (VERIFY: single-source, pre-release) | Fixed-version numbers rumored, not confirmed by PHP |
| PHP 8.0–8.1 | Pending | None expected | Out of active security support; upgrade required |
| PHP 5.x / 7.x | Reported affected | None | End-of-life; no official fix. Migrate or isolate |
Exposure Analysis
| Environment | Risk Level | Reason |
|---|---|---|
| Internet-exposed web services | Critical | Core RCE reachable from request paths; largest attack surface |
| Shared and managed hosting | Critical | Old bundled PHP, slow patch cadence, many sites per host |
| CI/CD pipelines | High | PHP build and test runners can execute attacker-influenced code paths |
| Cloud workloads / containers | High | Base images pin old PHP; rebuild and redeploy needed, not just a package update |
| Developer environments | Medium | Local interpreters lag behind; lower exposure but still a pivot |
Public internet telemetry underlines the scale of the end-of-life problem. One Shodan-based assessment counted roughly 2.23 million hosts advertising an X-Powered-By: PHP banner, about 1.5 million of which disclose a version. Of the versioned hosts, 883,717 (about 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.
Real-World Impact
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.
Detection Guidance
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.
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.
Verification steps for teams
- Enumerate every PHP interpreter in the estate: OS packages, container base images, custom builds, and shared or managed hosting. Record major version and SAPI (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.
Remediation Guidance
Immediate actions
On supported branches (reported as PHP 8.2 and later), 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 (VERIFY: single-source, confirm against the official release notes before acting). 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, 6, 7, and the end-of-life 8.0/8.1), no 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
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 about appliances and managed stacks that bundle old PHP outside your direct control.
Phoenix Security Recommendations
Attached: the campaign. Phoenix identifies technology stack to help narrow down those issues before they become impactful.
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.
- 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.
- 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.
- NVD/MITRE: CVE-2026-109618, CVE-2026-109619 (reserved; descriptions pending).
