PHP is in the middle of a real worldwide security scramble today. On October 20, 2026, the PHP security team announced an emergency release for two critical vulnerabilities in PHP itself, each rated 9.2 out of 10, after word of them leaked before the embargo ended. Researchers are calling the pair “PHP2Shell,” and the fix was scheduled for 14:00 UTC on October 21.
Status when written (October 21, 2026): the patch was scheduled for 14:00 UTC, and official confirmation that it had shipped was not yet available. The fixed versions are widely reported as 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Confirm on php.net before you act, and treat everything below about exploitation as a snapshot that can change within hours.
What happened, hour by hour
When (UTC) | What happened |
|---|---|
Oct 20, 15:20 | A Hacker News post claims two critical PHP remote-code-execution flaws will be disclosed on Thursday, October 22. |
Oct 20, evening | PHP’s security team publishes an advance notice of two critical flaws, both CVSS v4.0 9.2, and moves the release up to Wednesday. Security firm watchTowr says the leak is real. |
Oct 21, 02:13 | A PHP core developer says the only mitigation is patching or upgrading PHP. |
Oct 21, 07:43 | Cloudflare’s CTO says it is seeing early attacks and has deployed initial firewall rules. |
Oct 21, 08:48 | The PHP Foundation warns that Remi’s widely used Linux package repository will not have updates today. |
Oct 21, 14:00 | Scheduled release of the fixed PHP versions. |
What is confirmed, and what is not
Confirmed by the PHP project: two critical vulnerabilities, each rated CVSS v4.0 9.2; a coordinated release at 14:00 UTC on October 21; and a promise to ship earlier if details became public or exploitation appeared. Full details, affected versions and fixed versions were to be published with the release.
Reported by researchers, not by PHP: the identifiers CVE-2026-109618 and CVE-2026-109619, the description “remote code execution,” and the claim that every version from PHP 5 onward is affected (Sansec says PHP 5.4 or later). watchTowr says it reproduced one of the flaws, but its own FAQ says the version scope has not been confirmed by a vendor advisory. The leaked post said CVSS 10.0; PHP’s official score is 9.2.
Still unknown: the root cause, the exact affected versions, and whether an attack needs a particular configuration, setup or login.
Is anyone being attacked? Reports conflict. Patchstack says hosting partners have reported active exploitation, and Cloudflare says it is seeing early attacks. Against that, watchTowr’s FAQ listed no reported exploitation as of October 21, the flaws were not in CISA’s Known Exploited Vulnerabilities (KEV) catalog, Huntress had not seen exploitation in its partners’ environments as of October 20, and Australia’s cyber agency said it was not aware of any. Plan as if attacks have begun.
Why the scale is so large
PHP runs about 70.5% of the websites whose server-side language is known, according to W3Techs in August 2026. Because the flaws sit in the interpreter rather than in one app, WordPress, Drupal, Magento, Joomla and Laravel sites all inherit the risk if the PHP underneath is vulnerable.
The harder problem is who will not get a fix. PHP patches only its four supported branches, 8.2 through 8.5. Security company Mallory counted about 884,000 internet-facing hosts reporting PHP 8.1 or older to Shodan on October 20, which is 59% of the roughly 1.5 million hosts that reported any version. Another 740,000 reported PHP without a version. Banners are not proof that a host is vulnerable, but those servers have no upstream patch coming.
Speed matters too. Sansec expected mass attacks to begin within 15 minutes of the announcement. For comparison, when the Windows PHP-CGI flaw CVE-2024-4577 went public in 2024, Akamai saw exploit attempts against its honeypots within 24 hours.
It has been a rough year for PHP
PHP2Shell lands after a run of serious 2026 bugs, in the engine and in software built on it.
Date | Event |
|---|---|
Sep 25 | Releases 8.5.11, 8.4.26, 8.3.35 and 8.2.34 fix ten CVEs, led by a High-severity SOAP crash bug (CVE-2026-91765) that any unauthenticated request to a SoapServer endpoint could trigger. |
Jul 30 | Releases 8.5.9, 8.4.24, 8.3.33 and 8.2.33 fix a High-severity SQL injection in the PostgreSQL extension (CVE-2026-17543). |
Jul 10 | CISA adds two exploited Joomla extension flaws to KEV; one lets unauthenticated attackers upload and run PHP files. |
Jun 3 | CISA adds a Magento flaw (CVE-2026-45247, CVSS 9.8) to KEV after active exploitation; the Mirasvit Cache Warmer extension let attackers run arbitrary PHP code. |
May 7 | Releases 8.5.6, 8.4.21, 8.3.31 and 8.2.31 fix CVE-2026-6722, a SOAP use-after-free rated 9.8 under CVSS 3.1, where an attacker controlling a SOAP request body could achieve remote code execution. |
Apr 14 | Two high-severity flaws in Composer, PHP’s package manager, could allow arbitrary command execution; patches shipped. |
Old bugs stay useful to attackers, too: CVE-2024-4577, a Windows PHP-CGI flaw, has been in KEV since June 2024 and is flagged for known ransomware use.
What to do now
If you run your own servers. Once the fix is available, update the PHP runtime serving web requests (PHP-FPM, mod_php or CGI), prioritise internet-facing systems, and restart the service. Updating WordPress, Laravel or another app does not update PHP. Since Linux distributions may backport fixes without changing version numbers, check your distribution’s advisory. Also check PHP bundled with cPanel, Plesk, vendor appliances and Windows software.
If you use shared or managed hosting. Ask your provider when the fixed build will land. Providers package PHP only after the upstream release; CloudLinux, for one, says its updates depend on it.
If you run PHP 8.1 or older. No official fix is expected. Upgrade to a supported branch, put the site behind a VPN or firewall, or take it offline. Aim for 8.3 or newer, since 8.2 loses security support on December 31, 2026.
If you cannot patch yet. CERT-EU advises isolating internet-facing applications until a fix is applied. PHP core developer Gina Peter Banyard said shutting down the server for a day may be safest, though impractical for many. Otherwise, restrict access using a VPN, allowlisted clients or edge authentication, and block direct access to the origin. To limit damage from a takeover, GMO Flatt Security recommends storing less data, running with fewer privileges, removing stored credentials (including cloud roles), and keeping logs secure.
After you patch, look back. Alert on php-fpm, php-cgi, httpd or apache2 launching shells, interpreters or download tools. Check for web shells, new files in the web root, new cron jobs and unfamiliar accounts, and keep your logs.
Three things not to rely on
A configuration tweak. Advice is spreading to set
session.upload_progress.enabled=0. GMO Flatt Security floated it, then said it is not a complete fix and that bypasses are expected. PHP core developers say patching is the only mitigation, and PHP 8.6 release manager Joe Ferguson said the setting will not save you. Turning it off is harmless if you do not use upload progress bars, but PHP has not confirmed where the flaw lives, so do not count it as protection.A firewall. Cloudflare shipped emergency rules, but its changelog names neither PHP nor these flaws, and such rules only see traffic that passes through the provider. A web application firewall is a stopgap, not a fix.
A random “exploit.” Repositories claiming to hold a PHP2Shell proof of concept have already appeared. An anonymous audit says the circulating code does not work, and a fake exploit for a hot bug is an easy way to deliver malware. Do not run any of it on a machine you care about.
Support calendar for the branches that get a fix
Branch | Reported fixed version | Security support ends |
|---|---|---|
8.5 | 8.5.12 | Dec 31, 2029 |
8.4 | 8.4.27 | Dec 31, 2028 |
8.3 | 8.3.36 | Dec 31, 2027 |
8.2 | 8.2.35 | Dec 31, 2026 |
8.1 and older | None expected | Already ended |
What this episode teaches
Your app is not your runtime. Patching the CMS never patches PHP, and many teams do not know which PHP version actually serves their traffic.
End-of-life is where the damage concentrates. Hundreds of thousands of servers sit on branches with no patch coming.
Embargoes leak, so build an emergency lane. PHP pulled its release forward a day after the leak, and attackers move in minutes or hours. Teams that can patch within hours are the ones that stay ahead.
Bottom line
Do not wait for certainty. Inventory every PHP install, patch the supported ones as soon as the build for your branch is available, isolate or retire the unsupported ones, and check php.net for the official advisory with the full list of affected versions.
Comments(0)
Join the discussion by logging into your account.
No comments yet. Be the first to comment!