Update, October 21, 14:35 UTC: patch now available
PHP has now released the fixed versions and we have updated our recommendations. Exploitation attempts are still happening at scale, so patching is the priority today.
Update, October 21, 11:35 UTC: active exploitation attempts at scale
We are now seeing php2shell exploitation attempts in the wild. Most of the attacks we observe abuse PHP's session upload-progress path, and we expect more exploit paths to appear before and after the fix ships.
Our recommendation: if you run internet-facing PHP and cannot mitigate it right now, take those systems offline until the patch lands at 14:00 UTC and you have installed it. Shutting down a service for a few hours costs far less than a compromised server.
If a system must stay online:
- Set
session.upload_progress.enabled = 0and reload PHP-FPM or Apache. This blocks the path we see abused most, but it is not a complete fix. - If you are behind Cloudflare, keep the Generic Rules - Anomalous Execution rules on, keep the hostname proxied, and close the origin to direct traffic on its public IP.
- Watch for PHP worker processes (php-fpm, php-cgi, httpd, apache2) starting shells or download tools. Treat any hit as a compromise: isolate the host, keep the logs, and check for web shells, new cron jobs and new accounts.
Once fixed packages are out, patch, restart the PHP workers, and verify the running version before bringing systems back online.
Update, October 21, 09:50 UTC: before the patch lands
Our own testing points to a few stopgaps you can put in place while the 14:00 UTC release is still hours away.
- Set
session.upload_progress.enabled = 0and reload PHP-FPM or Apache if you do not use PHP's native upload-progress bars. In our lab that setting stopped part of what is likely the vulnerability. It is still not a complete fix for both bugs under discussion, and PHP has not confirmed any configuration workaround. - If you sit behind Cloudflare, leave the new Generic Rules - Anomalous Execution rules on. They landed today in both the Managed and Free rulesets. Cloudflare's CTO has already said they are seeing early attacks and updating mitigations as new vectors show up. Keep the hostname proxied, and do not leave the origin open on its public IP.
- Find the forgotten PHP hosts now (EOL 8.1 and older, CMS stacks, appliances), name owners, and book the change window. Take unused services offline and put admin UIs behind a VPN or allowlist until the fixed packages are in and the workers have been restarted.
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 or patch is available yet, and php2shell exploitation attempts are now happening in the wild at scale (see the updates above). 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 | Exploitation attempts in the wild at scale, mostly through PHP's session upload-progress path. 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
Following our earlier advisory about php2shell (CVE-2026-109618, CVE-2026-109619): PHP has now released the fixed versions. Exploitation attempts are still happening at scale, so patching is the priority today.
- Update PHP. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. After updating, restart PHP-FPM, Apache or whichever service runs your PHP workers. Old workers keep running the vulnerable code until they are restarted.
- Start with the riskiest hosts. All PHP installations that serve web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk, because an unauthenticated request can trigger the exploit before any application code runs.
- PHP 8.1 and older no longer get official updates. Check whether your distribution or LTS vendor has a backported fix, or upgrade to a supported version. PHP has also published minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source.
- If you use rpms.remirepo.net, note that it will not have updates today. PHP recommends switching to distribution packages or building from source so you can patch immediately.
If you can't patch an environment right away, keep the measures from our previous advisory in place: session.upload_progress.enabled = 0 (set in php.ini or the FPM pool, not via ini_set() or .user.ini) with every worker restarted, the Cloudflare Anomalous Execution rules enabled, and origins not reachable on their public IPs.
PHP has published additional mitigations in its advisory, but is clear that none of them are a complete fix. Updating is the only safe option, so if an internet-facing environment can't be patched, please still consider taking it offline until it is.
