PHP2Shell: what we know about the two critical PHP flaws (fix out)

Эта статья на английском языке.

Updated 23 October, 22:00 UTC

23 Oct 22:00 UTC The attacks started earlier than thought: Amazon saw a first attempt on 17 October, four days before disclosure. Cloudflare counts millions of attempts, but most exploits going round don't work (watchTowr) and no break-in has been confirmed publicly. How many servers are still unpatched (Censys, VulnCheck), the Chainguard dispute, and where to start looking in your logs. CISA still hasn't listed the flaws.
22 Oct 11:15 UTC More on attacks: Fastly sees reconnaissance across PHP applications, Huntress has not confirmed a successful attack. CISA still hasn't listed the flaws as exploited.
22 Oct 02:15 UTC New section on the websites that switched themselves off (governments in six European countries, Wikimedia, 4chan, services in Japan). Mixed reports on attacks: Hadrian sees exploitation at scale, CISA and several national agencies had not seen any. The out-of-memory flaw can reportedly also leak memory, so consider changing secrets. Two more log lines to look for.
21 Oct 19:50 UTC Fact check against PHP's official advisories. Corrected: which flaw is which (early reports had them the other way round): the out-of-memory flaw (CVE-2026-109618) is reached through form-upload parsing, the session upload-progress and error-backtrace paths belong to CVE-2026-109619. PHP confirms code execution on mod_php, and on PHP-FPM through the session path. Refined: PHP lists partial workarounds, none complete. New: watchTowr has seen exploitation in the wild.
21 Oct 15:00 UTC Details are public: how the attack works, who found it (Calif with OpenAI, Wiz), the applications it was shown against, source patches for PHP 7.4 to 8.1, signs of an attack, and sites that went offline as a precaution. Corrected: older versions are not entirely without a fix, and the start of the affected code is now known (PHP 5.4).
21 Oct 14:45 UTC The fix is out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (the versions reported in advance). PHP describes it as "Avoid state corruption via bailout" and lists it under two GitHub advisory ids. Debian shipped its update (8.4.27-1~deb13u1) shortly before 14:00 UTC. Update now.
21 Oct 13:25 UTC Cloudflare reports early attacks; PHP developers say settings like session.upload_progress do not protect (our first version suggested it as a precaution, now corrected); expected fixed versions; the suspected component; Node.js security releases and the eMudhra key compromise on the same day.
21 Oct 11:45 UTC First version, before the PHP release. The patch status at the top updates by itself once PHP publishes the fix.

On 20 October, the PHP security team warned of an emergency release for two critical flaws in PHP itself. Details had leaked online before a fix was ready. PHP runs most of the web, so this one is worth understanding even if you have never written a line of it.

Status, checked automatically every 15 minutes

Attacks confirmed. CISA lists CVE-2026-109618 and CVE-2026-109619 as exploited in the wild (added 26 October). If you run PHP and have not updated, assume you are being targeted.

The fix is out. PHP's changelog lists the fix in 8.5.12, 8.4.27, 8.3.36, 8.2.35. Update now. Linux distributions and hosting companies ship their own builds: check their advisories, their version number may differ.

Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout). (PHP changelog)

What happened

August The security firm Calif, working with OpenAI, found several ways to run code through PHP and reported the first bug to PHP on 11 August. Wiz Research reported the flaws on 24 August (Sansec's timeline).
17 Oct Amazon's honeypots record a first attempt to exploit PHP2Shell, four days before anything was public, from an anonymising network. Amazon says "it remains unclear how the actor acquired exploit information prior to disclosure" (The Register).
20 Oct, about 15:20 UTC A post on Hacker News described two upcoming remote-code-execution flaws in PHP. It was later taken down (reported by Sansec and Huntress).
20 Oct The PHP security team gave advance notice of a security release fixing "two critical vulnerabilities, both rated CVSS v4.0 9.2", and said it may release earlier "should details of either vulnerability become public, or should evidence of active exploitation appear".
20 Oct CERT-EU, the cybersecurity service of the EU institutions, published advisory 2026-018 with two identifiers: CVE-2026-109618 and CVE-2026-109619.
20–21 Oct The security firm watchTowr said it believes it reproduced one of them and confirmed "these vulnerabilities are indeed real". It is holding back details until the fix is out. The name "PHP2Shell" comes from an exploit tool seen in a leaked screenshot (Sansec) and a demo video shared by researcher Kirill Firsov, who credited the researchers LCFR and Calif.io (Tenable).
21 Oct, from 02:00 UTC Working proof-of-concept exploits start to circulate, about twelve hours before the planned release, and are tried against Amazon's honeypots almost at once, by several different attackers (Amazon).
21 Oct, 07:43 UTC Cloudflare's CTO said the company was "seeing early attacks emerging" and was updating its firewall rules, which it turned on for all customers, free plans included. Cloudflare calls these rules a stopgap (Tenable).
21 Oct PHP developers said configuration changes do not protect: "the only mitigation is patching / upgrading PHP" (Gina Peter Banyard) and "ini settings won't save you" (Joe Ferguson, release manager of PHP 8.6), as quoted by Tenable.
21 Oct GMO Flatt Security said the demo video shows a memory-corruption bug and that it reproduced it with mod_php and PHP-FPM, on WordPress, Laravel and Symfony set-ups. It points to the session upload-progress feature, which is on by default (as summarised by CybelAngel).
21 Oct, 14:00 UTC The planned release. Before it, the security researcher Kevin Beaumont reported the expected fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Tenable). PHP released exactly these versions; its changelog describes the fix as "Avoid state corruption via bailout". Debian's security update for PHP 8.4 (8.4.27-1~deb13u1) went out shortly before 14:00 UTC.
21 Oct, after 14:00 UTC Calif, Wiz, OpenAI and PHP published the details. PHP also released minimal source patches for PHP 7.4, 8.0 and 8.1, for people who build PHP themselves. Several Dutch sites, including Tweakers, the Dutch parliament (Tweede Kamer), the national cybersecurity centre NCSC and Security.NL, went offline as a precaution (Sansec). Code that claims to exploit the flaws is now public.
21 Oct PHP published its two official advisories on GitHub, with the technical details, the credits and partial workarounds (see below).
21 Oct watchTowr reported that "exploitation has been observed in the wild" in its network of honeypots, the first public confirmation of attacks after Cloudflare's early warning. The security firm Hadrian went further: "We are now seeing php2shell exploited in the wild at scale", mostly through PHP's session upload-progress path (SecurityWeek). Datadog spoke of "multiple reports of active exploitation" and "broad untargeted scanning".
21 Oct Others had not seen attacks themselves. CISA's advisory said it had "not observed exploitation of these vulnerabilities as of the time of publication" (NBC News); Belgium's cyber centre and Finland's state IT centre Valtori reported no attacks on their sites (The Next Web). Fastly saw attackers "actively probing and performing reconnaissance across PHP applications"; Huntress had "not observed, or independently confirmed, successful in-the-wild exploitation" (CyberScoop).
21 Oct Across Europe, the US and Japan, governments and large sites took PHP systems offline as a precaution (see below).
22 Oct Cloudflare's CEO Matthew Prince gives numbers: thousands of exploit attempts in the ten hours before the announcement, tens of thousands within 45 minutes after it, hundreds of thousands within two hours, and millions since. Attackers keep changing their requests to get past Cloudflare's firewall rules (The Register). Amazon now calls PHP2Shell "broadly exploited in the wild" (SecurityWeek).
22 Oct Not every attempt works: watchTowr says most of the exploits going round do not get code execution, but "test for timing-based differences, or crash the target". VulnCheck saw one attempt to plant a web shell fail (SecurityWeek). No confirmed break-in had been reported publicly by 23 October.
22 Oct The PHP Foundation accused the software company Chainguard of publishing patched PHP builds before the agreed release time (The Register).

How the attack works, in plain words

Both flaws are memory-safety bugs in how PHP cleans up when a request fails badly, typically when it runs out of the memory it is allowed to use. The clean-up frees memory that something else still points to, and the next request handled by the same PHP worker uses it. An attacker can steer that to run their own code on the server (Sansec, Help Net Security).

No login needed, before any website code runs. Every known trigger is an ordinary form-upload request (multipart/form-data), and the bugs are reachable with PHP's default settings. A site is exposed even if its own code is perfect (Sansec).
Two flaws, as PHP's own advisories describe them: CVE-2026-109618, "RCE via OOM corruption": when a request runs out of memory, PHP jumps out of what it was doing and leaves request memory in a broken state. Tricks in how form uploads are parsed (no usable length, endless part headers, empty file fields with nested names) are enough to get there. With Apache's mod_php it can be used before any application code runs; PHP validated a complete code-execution attack on mod_php with default limits. CVE-2026-109619, "RCE via stale global state": memory that belongs to the PHP worker is used after it was freed. PHP confirmed code execution through the fatal-error backtrace path on mod_php, and through the session lifecycle (the upload-progress path) on both mod_php and PHP-FPM.
It can also leak data. Sansec says CVE-2026-109618 "also leaks memory on its own, similar to Heartbleed": according to Sansec it can expose data from other requests, including passwords and even TLS private keys. SecurityWeek likewise reports that the flaws can be used to read sensitive memory, such as credentials and API keys.
Every way of running PHP on a web server: PHP-FPM, Apache's mod_php (the most dangerous), php-cgi, FrankenPHP and LiteSpeed (Help Net Security). PHP's advisory for the out-of-memory flaw says PHP-FPM is open to it on paper, but no complete attack on FPM was shown for that one. The oldest affected code dates from PHP 5.4.0, released in 2012 (Sansec).
Real applications. Calif says it confirmed attacks without a login against WordPress, Drupal, Magento, Joomla, MediaWiki, Nextcloud, Roundcube, phpMyAdmin, Laravel, Symfony and WHMCS. Wiz calls the findings "among the most severe vulnerabilities discovered in PHP, and arguably in software history".

What is confirmed, and what is not

Confirmed

Two critical flaws in PHP itself, not in a plugin or framework (PHP security team).
Both rated 9.2 out of 10 (CVSS v4.0).
The fix came out on 21 October at 14:00 UTC.
Remote code execution without logging in: PHP's advisories say it was validated on mod_php for both flaws, and on PHP-FPM through the session path.
Attacks in the wild: Amazon saw a first attempt on 17 October, before disclosure; watchTowr saw exploitation in its honeypots on 21 October; Cloudflare counts millions of attempts since.
No setting is a complete fix: PHP lists a few workarounds that block some attack paths, but only the update closes all of them.
The fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35, plus source patches for 7.4, 8.0 and 8.1 (PHP).

Reported, not confirmed by PHP

That the attack works against every application listed by the researchers (Calif, Wiz): PHP's advisories confirm the attack paths, not each application.
That every version since PHP 5.4 is affected: Sansec traces the oldest affected code to PHP 5.4.0 (2012).
How many attacks succeed: there are millions of attempts (Cloudflare), but watchTowr says most exploits in circulation don't achieve code execution, and no break-in had been confirmed publicly by 23 October. CISA, Huntress, Belgium's cyber centre and Finland's Valtori had not seen successful attacks at their last statement.
That the out-of-memory flaw leaks memory like Heartbleed (Sansec): PHP's advisories describe code execution, not this.
Code that claims to exploit the flaws is circulating. Nobody has confirmed it works, and fake exploit code often carries malware.
Exposure: Censys saw 2.58 million internet-facing PHP hosts on 21 October; of the 1.58 million that show their version, about 1.57 million were not patched yet. VulnCheck counts more than 2.6 million, at least 1 million of them on PHP versions that no longer get updates (SecurityWeek). These counts only see what servers announce.

On 20 October, watchTowr and Huntress had seen no attacks. On 21 October Cloudflare said it was seeing early attacks, Hadrian reported exploitation at scale, and watchTowr saw exploitation in its honeypots. CISA had not listed the flaws in its catalogue of exploited vulnerabilities when we last checked (23 October, 22:00 UTC), even though it urged everyone to update on 21 October; the status box at the top switches by itself when it does. Amazon's find moves the start back: the first known attempt was on 17 October, before anyone outside the researchers and PHP knew.

Why it matters

PHP is the server language of about 70% of the websites whose language can be detected (W3Techs, August 2026): blogs, shops, forums, government sites, and most WordPress installs. A flaw that lets a stranger run code on the server can mean stolen data, defaced pages, or the server quietly being used to attack others.

Two things make this one more urgent than most:

The fix shows the way in. Now that the patch and the write-ups are public, attackers can compare the old and new code. Sansec expects mass attacks, and Wiz says AI models made building the exploit much easier. Every hour without the update counts.
Many sites run old PHP. Only PHP 8.2 to 8.5 get official releases. W3Techs counts 29% of PHP sites on PHP 7 and 8% on PHP 5. For 7.4, 8.0 and 8.1 there are source patches that someone has to build and install; anything older gets nothing. Many of those sites sit in old hosting packages and devices that will never be updated.

The websites that switched themselves off

PHP2Shell did not take the internet down. But on 21 October it took a visible part of the web offline, on purpose: many organisations chose to switch their PHP sites off rather than leave them open while they waited for the fix or installed it.

Governments. Germany's federal IT provider ITZBund took several websites offline ("purely preventive", said the digital ministry). France's Interior Ministry pulled the sites of its local prefectures, and Belgium's foreign ministry took its sites down. In the Netherlands the national cyber agency NCSC went first, followed by Overheid.nl, the Port of Rotterdam, the football association KNVB, the five largest political parties and many hospitals. Finland's Valtori shut the government's public web services, and Denmark's municipal IT company Kombit took down services including the national school communication platform (The Next Web).
Wikimedia took a number of its PHP systems down until they could be patched (The Next Web, NBC News).
Forums and services. 4chan and Something Awful went offline to wait for the patch, 4chan saying it was "temporarily read-only while we await an urgent PHP security update". The bookmarking site Pinboard was down too, and in Japan systems for daycare centres and video games went offline (NBC News).

None of this shows on our map, and that is correct: Blackout Map measures whether a country can reach the internet, and the networks were fine. The sites were switched off by their owners.

If you run PHP: what to do

Find every PHP you run. The version you see with php -v on the command line can differ from the one your web server uses (PHP-FPM, Apache's module). Check the web one with php-fpm -v or a phpinfo page that you delete afterwards.
Update as soon as the release is out. This is the only real fix. If you install PHP from your Linux distribution or your hosting company, wait for their build and check their advisory: they often fix old versions without changing the main number. Updating WordPress or a plugin does not fix PHP itself.
Don't count on settings. PHP's advisories name a few workarounds, and say plainly that none of them is complete: session.upload_progress.enabled=0 blocks the session path that was shown, but not others; on PHP 8.5, fatal_error_backtraces=0 blocks the backtrace path; and an unlimited memory_limit=-1, set by the server admin, makes the out-of-memory flaw harder to reach (at the risk of one request eating all memory). PHP also advises limiting the size of request bodies, including requests without a usable Content-Length (Datadog). Use them only to bridge the hours until you can update.
Buy time if you can't patch yet. If your site runs behind Cloudflare, its firewall rules for known attack patterns are on for every plan, including free. They only cover traffic that really goes through Cloudflare, so make sure your server doesn't also answer requests sent to it directly. Taking an internet-facing PHP site offline until it is patched is the safest choice.
On PHP 8.1 or older: ask your host or vendor for a patched build (PHP published source patches for 7.4, 8.0 and 8.1) or move to a supported version. Until then, CERT-EU advises isolating internet-facing applications that cannot be fixed; Huntress suggests putting them behind a VPN or web firewall, and the UK's NCSC to consider taking them offline. Note that the community repository rpms.remirepo.net did not have the fix on release day.
Check for signs, also after patching. Huntress suggests looking for PHP worker processes that start shells. Aikido suggests looking for web shells, unexpected or modified PHP files, new admin users and unusual outbound connections, going back several months. Wiz lists signs of the attack itself: form-upload requests followed by memory-limit errors or bursts of HTTP 500 errors, unusually large or garbled PHPSESSID cookies, and PHP workers restarting for no clear reason. Datadog adds two concrete log lines: a memory-limit error ("Allowed memory size of … bytes exhausted") reported in Unknown on line 0, which means PHP failed before any script ran, and Apache workers dying with a segmentation fault (AH00052). Neither proves an attack on its own, and a successful attack can leave no error at all. The attack runs below your application, so its own logs may show nothing. Amazon suggests searching web server logs for form uploads (POST requests) that contain PHP_SESSION_UPLOAD_PROGRESS, and starting any investigation from 17 October, not from the day the flaws were announced.
Consider changing secrets. Because the out-of-memory flaw can reportedly leak memory (Sansec), a server that ran unpatched PHP on the internet after 17 October may have given away more than code. Changing database passwords, API keys and session secrets, and replacing the TLS certificate's key if PHP runs in the same process (as with mod_php), is a reasonable precaution.

Be wary of anyone promising that one firewall rule or setting makes you safe: PHP's own advisories say there is no complete workaround. Firewall rules and settings buy time; only the update closes the hole.

Also today: Node.js, and a certificate authority's stolen keys

21 October is a busy day for anyone running servers:

Node.js released security updates for its 22.x, 24.x and 26.x lines: ten issues, four rated high, including an out-of-bounds write in its Brotli decoder that "permits remote code execution" (CVE-2026-111497) and several ways around TLS certificate hostname checks. Fixed in 22.23.4, 24.22.1 and 26.12.1. More in our post on the Node.js release.
eMudhra, the certificate authority behind the emSign roots, had the private keys of eight of its intermediate certificates compromised. Chrome, Firefox, Apple, Microsoft and Go block them, and Linux distributions are shipping updated lists of trusted certificates. A side effect: other sites whose certificates chain to the same emSign root can suddenly fail to connect for programs that use the system's list. It happened to one of our own data sources today.

What Blackout Map will watch

Blackout Map measures whether countries can reach the internet. A software flaw is not an outage, and it will not turn a country red on our map. But big flaws leave traces in data we already follow, so we have added a Security watch page and an alert on the map:

Scanning of web servers. Sensors run by SANS ISC count connection attempts on web ports every day. When attackers sweep the internet for vulnerable servers, these counts can jump. Other things cause jumps too, so we will read it as a sign, not proof.
Confirmed attacks. If CISA adds these flaws to its list of exploited vulnerabilities, the alert here and on the map switches to "Attacks confirmed" by itself.
DDoS attacks. Hacked servers are often pulled into botnets that flood networks. Our map shows DDoS attacks as Cloudflare Radar sees them.

Software problems have taken large parts of the internet down before, just not usually through security flaws. Read how one routine command took Facebook offline for six hours, how a maintenance update cut off millions of Canadians, and our explainer Can a software flaw take the internet down?

Scans per day on port 443 (HTTPS), last 60 days

26 окт.: 470 139 сканирований, намного меньше обычного

Live chart. Dashed line: the usual level (median of 28 days). Red: more than twice the usual. Source: SANS ISC DShield (CC BY-NC-SA 4.0). These counts swing a lot from day to day, so one high day on its own means little.