PHP2Shell: The patch is out. Will it still be a disaster?

As of 22 October 2026, 7:15 CEST, after the release. First what has changed since the afternoon, then what the release settled and what to do. The morning situation report follows at the end, shortened.

Update October 22, 7:15

Amazon writes on its own security blog that its honeypots registered a first exploitation attempt as early as October 17, four days before disclosure. Attempts by several actors followed on release day; according to Amazon, it is still unclear whether any of them would have worked on real systems. Even so, the company speaks of widespread exploitation and advises checking logs from at least October 17 onward. No successful break-in has been publicly confirmed so far, and the flaws are still not in CISA’s KEV catalog. In a blog post, the PHP Foundation explains that the first signs of the memory flaw surfaced back in 2024 during work on an audit, but the fix then stalled for a long time. The Foundation itself calls this “a structural failure” and confirms that the embargo broke several times before the release, most recently when Chainguard published images ahead of time on the morning of release day. Plesk has now also patched the PHP that runs its own panel, and Amazon Linux and further RHEL versions are shipping updates as well. The SimpleXML regression, however, has not been patched yet.

Update 22:15

Little has changed: the flaws are still not in CISA’s KEV catalog, and the agency explicitly states in its alert that it has not observed any exploitation so far. VulnCheck continues to report scans and one failed webshell attempt, but no successful break-in. Plesk has caught up and now offers patched PHP versions 8.2 to 8.5 on Windows as well; only the PHP that runs the Plesk panel itself is still waiting for its hotfix. SUSE is already shipping for SLES 15 SP7, as are Fedora and Homebrew. A correction to what we said earlier: a first regression in 8.4.27 and 8.5.12 has now been confirmed. It only affects a very specific setup involving SimpleXML, and a fix is in the works. In the Netherlands, DigiD and MijnOverheid are reachable again.

Update 18:20

Reports of attack attempts have picked up since the release. The security firm watchTowr now lists the flaws as exploited in the wild, based on its network of honeypots, servers set up as traps. Shortly after the release, Patchstack saw only probing and no hard evidence of breaches. No successful break-in has been publicly confirmed so far. CISA rates exploitation as “none” in the CVE record, and according to NOS the Dutch justice minister sees no signs of active abuse yet.

The researchers who found the bugs, at Calif and Wiz, have published their write-ups. Wiz says the flaws allow more than code execution: an attacker can also read memory from the PHP process, which may hold passwords, tokens, and API keys. Dozens of supposed exploits have appeared on GitHub. VulnCheck found that only a handful implement the right mechanism and none gets past the usual protections on common x86 servers on its own. Rapid7 still expects a working exploit to go public soon. Don’t wait for it.

Packages are arriving. Debian and Ubuntu have shipped updates, Ubuntu even for its old PHP 7 packages under extended support. The official Docker images are updated, Alpine is catching up, cPanel ships fixes from PHP 7.4 to 8.5, and Plesk has Linux packages for 8.2 to 8.5. Plesk’s Windows builds and older branches are still pending, and SUSE’s packages are still in testing. No problems with the updates themselves have been reported. In the Netherlands, some of the sites taken down as a precaution, such as RTL and Tweakers, are back; DigiD.nl was still unreachable shortly after 18:00.

The message hasn’t changed: patch today.

What the release settled

This afternoon the PHP team published the announced updates for the two critical flaws CVE-2026-109618 and CVE-2026-109619. The security advisory on php.net is clearer than much of what circulated in the morning: both flaws can let an unauthenticated attacker run code on the server, and PHP urges everyone to update immediately.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. According to the CVE records, every earlier version of the supported branches is affected; Wiz says every release since PHP 5.4 is hit by at least one of the two. PHP, which assigns these CVE numbers itself, rates both at 9.2 out of 10 under CVSS 4.0. Germany’s BSI lists them as critical and expects large-scale exploitation within hours of the release.

Any installation that serves web requests is at risk, PHP says: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The risk is highest with mod_php, where a demonstrated exploit lets a single unauthenticated request trigger the attack before any application code runs. Clean application code won’t save you. Both bugs sit in how PHP cleans up after an aborted request: one involves data left half-initialised after an out-of-memory abort, the other internal state that outlives a request and gets used by the next one in the same worker.

Red Hat rates the flaws only “Important” for its own packages, because RHEL uses PHP-FPM by default and an attack there is harder in practice. That is an assessment of one configuration, not a reason to wait, and Red Hat, too, calls the update the only complete fix.

PHP 8.1 and older normally get nothing more from the PHP project. Given the severity, the security team made an exception and published minimal source backports for 7.4, 8.0, and 8.1 for people who build their own. If you install PHP from the popular Remi repository, PHP says there will be no updates there today; switch to your distribution’s packages or build from source.

If you can’t patch right away

PHP lists stopgaps but is clear that they only close off individual attack paths. Only the update makes an installation safe. For CVE-2026-109618, PHP advises setting memory_limit=-1 in a way applications cannot override, for example via php_admin_value, keeping post_max_size low, and enforcing size limits at the web server or proxy. For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini or the pool configuration and restart every worker; on PHP 8.5 also set fatal_error_backtraces=0. Doing this via ini_set() or .user.ini has no effect.

So the switch everyone shared this morning partly helps against one flaw and does nothing against the other.

Cloudflare writes on its blog that its WAF rules have been live for all customers since 05:02 CEST, free plan included. Even before the release it saw attackers reshaping requests to slip past the rules, which is why Cloudflare also tells customers to patch. If you can neither patch nor protect an exposed service, take it offline, as CERT-EU and the FBI advise.

How the morning’s claims held up

Confirmed: 9.2 under CVSS 4.0 for both flaws. The CVSS 10 going around this morning was wrong.
Confirmed: The circulating version numbers 8.5.12, 8.4.27, 8.3.36, and 8.2.35 were right. I had listed them as unsupported.
Partly confirmed: Session Upload Progress plays a role, but only in one of the two flaws and only on one of several paths. The switch alone is not enough, as heise and Patchstack already said this morning.
Confirmed: Attack attempts before the patch, described by Cloudflare on its own blog. Successful break-ins are still not publicly documented, and the flaws are not in CISA’s KEV catalogue yet.
Outdated: The idea that only LiteSpeed servers were targeted. PHP names every web setup and sees the highest risk with mod_php.
Largely confirmed: “From PHP 5 onwards”. PHP itself names no lower bound; Wiz, one of the finders, says every version from 5.4 is affected.
Still unsupported: the claim that the patch is “compromised”.

Will this become a disaster?

The morning’s first question is essentially answered. The technical details are public in the advisories and the researchers’ write-ups, and attackers are already trying. That most public exploits are still half-baked may buy you hours, not days. The researchers showed unauthenticated code execution against WordPress, Drupal, Joomla, and Magento, among others.

That leaves the second question: how fast hosts, platform teams, and distributions roll out. Many large providers have been shipping since the afternoon. With a supported version and an attentive host, you will be through tonight. The risk lies with the old PHP 7 or 8.1 servers nobody looks after, and with devices that run PHP under the hood, such as firewalls, NAS boxes, and appliance web interfaces. Backports now exist for the old branches, but someone has to build and install them. For appliances, you depend on the vendor.

What to do now

Install 8.5.12, 8.4.27, 8.3.36, or 8.2.35 today, or your distribution’s patched package. Then restart PHP-FPM or Apache; containers need to be rebuilt and redeployed.
Start with Apache and mod_php, where the risk is highest.
Check the version your website runs, not your shell. php -v only shows the command-line version. The hosting panel, the container image, or a brief phpinfo() that you delete right after will tell you what the site actually uses.
Settle who patches: whoever owns the PHP runtime, be it the host, the platform team, or whoever maintains the container base image. On shared hosting, ask your host; for appliances, ask the vendor.
On PHP 8.1 or older, get the backport from your distribution or LTS vendor, build PHP’s source backports yourself, or take the application offline until it is migrated.
If you can’t patch right away, apply PHP’s stopgaps in the server or pool configuration and keep a WAF in front. That buys hours, nothing more.
Over the next few days, watch for new files in the web root, for programs PHP suddenly starts, and for unusual numbers of error pages. If you find traces, treat the server as compromised and replace the credentials stored on it.

Whether PHP2Shell becomes a disaster won’t be decided on X, but by whether the update is running on our servers tonight.

The morning situation report (as of 13:30) follows in shortened form, so it stays clear what was known before the release. What has since been overtaken is covered above under “How the morning’s claims held up”.

Morning: What was confirmed

The PHP security team had announced two critical vulnerabilities, both rated 9.2 under CVSS 4.0, with the update due at 16:00 CEST. Affected versions and components were to be named only with the release. The security firm watchTowr had confirmed on X that the leaked information was genuine. In its Advisory 2026-018, CERT-EU advised preparing to patch and, where needed, isolating internet-facing applications until the fix was out.

Morning: What was only claimed

According to The Hacker News, the deleted post that triggered the leak spoke of CVSS 10 and of every version since PHP 5 being affected. A proof of concept making the rounds could not be reproduced in a lab, heise security reported, and only targeted the LiteSpeed server. Cloudflare CTO Dane Knecht wrote on X that his company was seeing early attacks, and Patchstack said hosting partners had observed active exploitation. That did not amount to confirmed break-ins.

From midday, several large services took their sites offline as a precaution, among them the Dutch government portals DigiD and MijnOverheid, the House of Representatives’ website, and RTL.nl (NOS). It showed how seriously operators took the flaw, but it was not evidence of break-ins: the Dutch NCSC had seen no active exploitation.

Nobody knows how many servers are affected. According to The Hacker News, Mallory counted around 884,000 hosts whose banner reports PHP 8.1 or older. Those are banner figures, not systems confirmed to be vulnerable.