PHP Security Patches: Leaked RCE Flaws Force Emergency Release

A broken embargo leaves PHP admins racing to patch

PHP, the language behind a huge share of the web, is going through one of the worst disclosure breakdowns in its history. On October 20, 2026, the PHP security team warned that it would issue fixes for two critical vulnerabilities on Wednesday, October 21, at 14:00 UTC. It rated both flaws 9.2 under CVSS v4.0.16 The notice told every PHP user to get ready to upgrade the moment the release lands. It also said the team might ship early if details of either bug became public or if attacks were spotted in the wild.16

That warning came late in the process. By the time the notice went out, the embargo had already been broken. Security firm watchTowr confirmed that the flaws, tracked as CVE-2026-109618 and CVE-2026-109619, are real remote code execution bugs. It said they had originally been held under embargo until Thursday at 11 a.m. ET.2 Defenders did not get a quiet patch day. They got a public countdown, with attackers able to watch the same clock.

How the leak unfolded

The accounts largely agree on the order of events. On October 20, a Hacker News post claimed two critical PHP RCE disclosures were on the way. The post was deleted, but screenshots had already spread across social media.17 That post named the same two CVE identifiers watchTowr later shared. It also claimed both flaws scored a perfect 10.0 and reached back to PHP 5.2 Sansec's timeline places the Hacker News post at 15:20 UTC. It says PHP announced the security release that same day, and watchTowr confirmed the leak.11

A leaked screenshot of an exploit tool called PHP2Shell, credited to Calif.IO, appeared alongside the advisory. The tool's banner claims it works against every PHP release since 5.4.0.11 Coverage of a related video describes the tool running code on servers with current versions of WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal and WHMCS. Ars Technica noted that it could not find the original report.41 Within hours, a researcher posted what were described as full details of the flaws, along with two proofs of concept. iTnews saw the site but could not confirm that the exploits work.10

One analysis of a proof-of-concept bundle traces the problem to heap use-after-free bugs in PHP's session upload-progress handler. It also points to a second suspected path in the multipart form parser itself. The same analysis stresses that the jump from memory corruption to full code execution is claimed, not shown.18

Where the reporting diverges

The accounts disagree on several points, and those gaps matter for anyone deciding how to respond.

Severity. PHP's official rating is 9.2 under CVSS v4.0.16 watchTowr's CEO Benjamin Harris described both flaws as "CVSS10," matching the deleted Hacker News post.2 The difference is mostly academic. Either score means an attacker could take over an exposed server without help from the victim.

Affected versions. watchTowr said the flaws are believed to affect PHP 5, 6, 7 and 8.2 Phoenix Security pointed out that PHP 6 never shipped as a production release and should not appear in any version list. It also noted that the claim of impact back to PHP 5 has not been confirmed.18 Sansec put the range at PHP 5.4 or later.11 PHP itself has said it will publish affected and fixed versions only with the release. For planning, the safest assumption is that any PHP version in production is at risk until proven otherwise.

Who gets a fix. Here the coverage lines up, and the news is bad. Sansec notes that PHP officially supports only version 8.2 and later, so servers on 8.1 or older will not get an official patch.11 Phoenix Security estimates that about 884,000 end-of-life hosts will get no upstream fix.18 One researcher cited by Ars Technica put the number of likely affected internet-connected hosts at around 1.3 million.1

Exploitation status. This is where the story has moved fastest. watchTowr said it had seen no exploitation in the wild.2 Huntress reported the same for its partner environments as of October 20.17 By the morning of October 21, Sansec reported that Cloudflare had seen early attacks against PHP sites at 07:43 UTC and had deployed web application firewall rules.11 Techzine reported that Cloudflare and Akamai had both seen automated scans hunting for vulnerable endpoints.4 Early silence followed by mass probing is the normal pattern once exploit code is public. Defenders should treat the exploitation window as already open.

Preemptive shutdowns, not yet a breach wave

So far, there are no confirmed reports of data stolen through these flaws. The visible damage is to availability: organizations have taken their own sites offline to protect themselves. Sansec recorded Dutch tech site Tweakers, the Dutch parliament (Tweede Kamer), the national cybersecurity center NCSC and Security.NL going offline by 10:35 UTC on October 21.11 Techzine reported temporary outages at Dutch government platforms including MijnOverheid, DigiD and the House of Representatives. It said universities, Magento shops and phpBB or vBulletin forums were also shutting public interfaces.4

The theft risk is the reason for the shutdowns. GoDaddy told customers that a flaw of this kind could let an attacker run code on a server remotely, leading to stolen data, defaced sites or full takeover.15 PHP sits under e-commerce checkouts, customer portals and internal tools. Unpatched servers that stay online during an active scanning campaign are likely sources of breach reports in the weeks ahead. Sansec specifically named Magento, Shopware and WooCommerce stores as exposed.11

Not everyone is pulling the plug. Techzine notes that large operators running heavily modified runtimes, firewalls and microservice setups are less exposed to flaws in standard upstream PHP. That includes Meta, which uses HHVM.4

Governments and vendors move before the patch

Official agencies issued alerts before any fix existed, which is unusual. The Australian Signals Directorate published a pre-patch alert telling organizations to watch their PHP applications and prepare to update. CERT-EU advised isolating internet-facing applications from public networks where patching isn't possible.10 Techzine reported that the UK NCSC and US CISA had also raised alarms.4

Across the ecosystem, Laravel said its Forge and Cloud services would ship patched base images. It warned that customers may need to redeploy to pick them up.8 Sansec warned that the PHP Foundation had said Remi's repository, a common package source for Red Hat-family Linux systems, would not have updates on release day.11 For many admins, that means the fix will not simply arrive through their usual package manager.

Mitigation: patch, then argue about workarounds

The official line is blunt. According to Sansec's timeline, a PHP core developer said patching is the only mitigation.11 Community discussion relayed similar comments from a PHP release manager. Some commenters argued that turning off multipart form handling at the server or CDN level could block the suspected attack path.9 Phoenix Security described a partial workaround: set session.upload_progress.enabled = Off. Even the proof-of-concept author says this closes only one of the two suspected paths. The analysis suggests filtering multipart POSTs at the edge to cover the second.18

Basic preparation advice is the same everywhere. Name an owner for PHP, list every PHP application, schedule a maintenance window from 14:00 UTC with a plan for an earlier release, back up files and databases, and watch PHP.net.1 Sansec has gone further, predicting mass attacks within 15 minutes of the release.11

The takeaway

In our view, the biggest lesson here is about disclosure process, not code. Coordinated disclosure only works if the embargo holds, and this one failed in public. Proof-of-concept code was out before any fix, and scanning had reportedly started before release day.1011 The PHP team responded sensibly by moving its release up a day from the original Thursday target.17 Still, the leak meant attackers and defenders started at the same moment.

The longer-term problem is the large number of servers on end-of-life PHP versions that will never get an upstream fix.18 If the reported version range holds up, this episode could finally push many of those systems to upgrade. That push may come through breach reports instead of maintenance plans. Admins on supported branches have a clear path: patch as soon as the release lands and restart PHP. Admins on older versions have one realistic choice: upgrade or take those systems offline.