Details of two remote code execution flaws in PHP core, tracked as CVE-2026-109618 and CVE-2026-109619, leaked on October 20, 2026, before the PHP project had released a fix. The PHP security team has since confirmed two critical vulnerabilities, each rated CVSS v4.0 9.2, and scheduled a security release for Wednesday, October 21, 2026 at 14:00 UTC. Researchers have confirmed that the flaws are real, and one team reports reproducing CVE-2026-109618.
No technical write-up, patch, or public proof of concept is available yet, and there is no known exploitation in the wild. Security teams should find every internet-facing PHP deployment they own and identify the versions. While unconfirmed, organizations still running PHP 5.x, 7.x, or older PHP 8 branches should expect to upgrade to a supported release to get a fix.
Technical overview
Both CVE records are reserved at MITRE but unpublished, and PHP's advance notice does not list affected versions, so several fields below rely on researcher reports until the full advisory lands.
| Field | Detail |
|---|---|
| CVE IDs | CVE-2026-109618, CVE-2026-109619 (reserved, no description yet). The IDs come from the leak and researcher reports; PHP's advance notice does not name them. |
| Component | PHP core |
| Type | Remote code execution |
| Severity | 9.2 critical (CVSS v4.0) for both, per the PHP security team. The leak and Florian Roth cited 10.0 |
| Affected versions | Unconfirmed. Researcher reports claim PHP 5 through 8 are affected; a leaked exploit banner claims every release since 5.4.0 |
| Fixed versions | To be announced with the October 21 release. PHP currently supports only the 8.2, 8.3, 8.4, and 8.5 branches (latest 8.2.34, 8.3.35, 8.4.26, 8.5.11) |
| Exploitation | No known exploitation; no public proof of concept. A screenshot of an exploit tool called PHP2Shell has circulated |
| Timeline | October 20, about 15:20 UTC: a since-deleted Hacker News post reveals the upcoming disclosure. About 16:40 UTC: Kevin Beaumont reports the leak. Same day: PHP publishes an advance notice. October 21, 14:00 UTC: scheduled PHP security release |
What is confirmed and what is still rumor
Confirmed in PHP's advance notice: two critical vulnerabilities exist, both are rated CVSS v4.0 9.2, and fixes ship on Wednesday, October 21 at 14:00 UTC. PHP has said it may release earlier if details become public or exploitation appears. The disclosure was originally under embargo until Thursday, October 22; the leak, first flagged publicly by Kevin Beaumont, moved it forward by a day.
Not yet confirmed by PHP: the CVE IDs, the affected versions, and the code paths involved. The CVSS 10.0 score, also reported by Florian Roth, and the claim that every release since PHP 5 is affected come from the leak and researcher reports. The name "php2shell", which most coverage now uses, comes from the leaked exploit tool.
Same PHP version, different risk. Severity for interpreter bugs usually depends on whether attacker-controlled input can reach the affected code. Two sites on the same PHP version can therefore face very different real-world risk, depending on the functions, extensions, and SAPIs their applications use. The advisory should settle most of this, and we will update this post when it does.
Why end-of-life PHP matters here
PHP only ships fixes for supported branches, so PHP 8.1 and older are unlikely to receive an official patch. That makes older PHP the part of the estate this disclosure leaves exposed. Those versions tend to sit on long-lived, internet-facing assets that nobody actively owns: legacy campaign sites, acquired subsidiaries, and vendor appliances that are never upgraded on their own schedule. For those, the options are an upgrade, a backported fix from a Linux distribution or hosting provider, or taking the service offline.
That exposed part is large. According to W3Techs, PHP runs on 69.3% of websites whose server-side language is known, and almost half of those sites run a PHP version that is unlikely to receive an official fix.
| PHP version | Share of PHP sites | Official fix expected |
|---|---|---|
| PHP 4 | 0.1% | No |
| PHP 5 | 7.7% | No |
| PHP 7 | 27.0% | No |
| PHP 8.0 | ~3.8% | No |
| PHP 8.1 | ~9.9% | No |
| Total without an official fix | ~48.5% | |
| PHP 8.2 | ~18.1% | Yes |
| PHP 8.3 | ~22.7% | Yes |
| PHP 8.4 | ~7.9% | Yes |
| PHP 8.5 | ~2.9% | Yes |
Taken together, that is roughly a third of all websites with a detectable server-side language. The real share of old versions may be somewhat lower: well-maintained sites often hide their version, and some Linux distributions backport fixes to the PHP packages they ship. W3Techs data as of October 21, 2026; shares for PHP 8.x minor versions are derived from W3Techs' PHP 8 breakdown.
Verification and detection
Hadrian Atlas customers can start the inventory today. Atlas continuously maps your external attack surface, including subsidiaries and forgotten hosts, and identifies the technologies running on each asset, so PHP deployments and end-of-life versions can be listed now.
When the advisory is published, Hadrian's offensive security team will review the affected code paths and add checks for these exposures. Atlas, Hadrian's external exposure management solution, can then test whether a flagged asset is actually exploitable, which separates assets that need an emergency upgrade from those that can wait for the next change window.
We will update this post with affected versions, fixed releases, and detection coverage after disclosure.
Recommendations
Most of the preparation can happen now, before the patch or any technical detail is public.
- Inventory internet-facing PHP. Start with the Technology tab in Hadrian Atlas, which lists PHP across your external attack surface, including subsidiaries and forgotten hosts. Then cross-check with an internal survey of your CMDB and hosting records. Include the places PHP runs indirectly, such as WordPress, Drupal, and Magento sites, Laravel and Symfony applications, admin panels, and vendor appliances that bundle a PHP runtime. Response headers like X-Powered-By help, but many deployments strip them.
- Flag end-of-life versions. PHP 5.x, 7.x, 8.0, and 8.1 no longer receive upstream fixes. PHP 8.1 reached end of life on December 31, 2025, and the supported branches today are 8.2, 8.3, 8.4, and 8.5. These assets will need an upgrade path or a backported fix.
- Prepare the version check. Agree owners, staging targets, and an emergency change window now, so patching can start within hours of the release at 14:00 UTC on Wednesday, October 21. If your hosting provider manages PHP, ask them to stand by to apply it.
- Reduce exposure where you can. Until the advisory names the affected code paths, signature-based WAF rules cannot be written with confidence. Restricting access to admin interfaces and taking unused PHP services offline lowers risk regardless of the details.
- Watch for signs of compromise. Alert when PHP worker processes such as php-fpm, php-cgi, httpd, or apache2 start a shell, a scripting interpreter, or a download tool, and when command lines contain patterns like /dev/tcp/, fsockopen, or mkfifo. This works before any technical details are public.
- Act only on official sources. Watch php.net, the php-src GitHub security advisories, or Hadrian. Treat any proof of concept that appears before the official release with caution until a trusted researcher has validated it.
