PHP2Shell: Two Critical RCE Flaws Hit 69% of the Web — Patch Lands at 14:00 UTC

Cloudflare's CTO reported early attacks against PHP sites on the morning of October 21, 2026 — hours before a scheduled emergency patch release meant to close two critical remote code execution vulnerabilities that researchers say affect every PHP installation from version 5.4 onward. The patch, covering PHP 8.2 through 8.5, is due at 14:00 UTC. Sites running older, end-of-life branches will receive no official fix.

We are seeing early attacks emerging and are updating mitigations as new vectors show up. This is a STOPGAP only. Patch as soon as @ThePHPF releases the update at 14:00 UTC today.— Dane Knecht, CTO, Cloudflare

The two vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — were rated CVSSv4.0 9.2 by the PHP security team, though some early reports including watchTowr and a Hacker News post described them as CVSS 10.0. The PHP security team has not published technical details ahead of the patch. What is known publicly comes from a leaked screenshot of an exploit tool called PHP2Shell, credited to Calif.IO, whose banner claims it works against every PHP release from 5.4.0 onward.

The CVE identifiers first circulated on Hacker News and social media on October 20, 2026 — a day before the originally planned embargo date of October 22. Later that day, the PHP security team published advance notice of the October 21 release and said it reserved the right to release earlier if details became public or active exploitation appeared. CERT-EU also published advisory 2026-018 naming both CVEs. A video shared by researcher Kirill Firsov, crediting the exploit to researcher LCFR and Calif.io, demonstrated an exploit chain the video's creator dubbed php2shell.

watchTowr CEO Benjamin Harris confirmed the flaws are real and said the company reproduced CVE-2026-109618, while withholding technical details until the fix ships. watchTowr told BleepingComputer it had seen no in-the-wild exploitation as of its report, though Cloudflare's statement on the morning of October 21 changed that picture. The Sansec Forensics Team warned it expects mass attacks to begin within 15 minutes of the patch release — the moment a patch is public, reverse-engineering it to find the vulnerable code becomes straightforward.

The scale of potential exposure is significant. According to W3Techs, PHP is used by 69.3% of websites whose server-side language is known, underpinning platforms including WordPress, Drupal, Joomla, Laravel and Magento. Security researcher Silas Cutler estimated over 1.3 million internet-exposed hosts are potentially vulnerable; a Shodan search by Henk Poley counted over 1.9 million internet-exposed hosts running PHP. Mallory, using Shodan's 'X-Powered-By: PHP/' header data, counted roughly 1.5 million hosts that report a PHP version — and found that approximately 883,717 of them, about 59 percent, run a branch that will receive no official fix.

A critical detail shapes every mitigation discussion: the vulnerabilities sit in PHP core itself, meaning they are reachable before any application code, maintenance mode, or application-level firewall runs. Sansec put it plainly — you cannot fix PHP2Shell from within your store or application codebase. Infrastructure-level action is required.

On the question of what actually protects you before the patch, PHP's own developers were direct. PHP core developer Gina Peter Banyard said 'the only mitigation is patching / upgrading PHP.' When a suggestion was made to turn off the session.upload_progress setting, PHP 8.6 release manager Joe Ferguson said 'ini settings won't save you.' Banyard herself made the same point in reply to a suggestion about session.upload_progress.enabled, according to Sansec.

That said, several partial measures can reduce — not eliminate — exposure for sites that cannot patch immediately. Cloudflare has deployed WAF rules covering the known exploit vectors for all customers, including the free tier, and is updating them as new attack methods appear. Cloudflare explicitly describes these as a stopgap. Critically, the rules only protect traffic routed through Cloudflare; an attacker who knows a site's origin IP address can bypass them by connecting directly. Sansec advises that sites using Cloudflare should also configure their firewalls to accept HTTP and HTTPS only from Cloudflare's IP ranges.

At the web server level, blocking multipart/form-data requests — the format browsers use for file uploads — prevents PHP from parsing the request bodies believed to be involved in the attack path. Sansec published specific nginx and Apache configuration rules to do this. The trade-off is significant: the rule breaks every file upload on the site, including product image uploads in Magento's admin panel and the WordPress media library, and may affect checkout forms on some stores. It should be removed as soon as PHP is patched.

Sansec also published php.ini settings — setting session.upload_progress.enabled to 0 and session.use_strict_mode to 1 — as additional steps, while being explicit that these are not a guarantee and that patching remains the only real fix. For PHP-FPM users, these settings must be added to each pool configuration file, not just php.ini, because PHP-FPM reads its own pool configuration. Sansec notes that on stores keeping sessions in Redis or a database, the strict session mode setting has no protective effect.

For sites that can afford downtime, PHP core developer Gina Peter Banyard called going offline the most sensible option. Several Dutch sites took that step on October 21 as a precaution, according to Sansec: tech site Tweakers, the House of Representatives (Tweede Kamer), the National Cyber Security Centre (NCSC), and security news site Security.NL. Sansec notes that maintenance modes built into Magento and WordPress do not help, because PHP still parses each request before the application checks for the maintenance flag. The correct approach is to stop PHP-FPM and serve a static maintenance page directly from the web server.

Sites that cannot go fully offline can make themselves read-only by having the web server reject every request method other than GET and HEAD, allowing visitors to browse but preventing logins or order placement.

One infrastructure trap: sites that install PHP from Remi's repository, common on RHEL-based servers, will not receive the fix on October 21. The PHP Foundation said the volunteer-run repository will not publish updates that day. Sansec advises those sites to switch to their distribution's PHP packages or build PHP from source before the release so they can apply the fix immediately.

Unverified proof-of-concept code claiming to exploit these vulnerabilities is circulating publicly. Tenable has not verified that any of it works against CVE-2026-109618 or CVE-2026-109619, and warns that unverified exploit code is sometimes laced with malware. A 'Zer061/CVE-2026-109618' repository appeared on an exploit aggregator on October 20; RedEye Security advises treating any public proof of concept posted before the fix ships as bait, not a tool to run.

The closest precedent cited by researchers is CVE-2024-4577, a PHP-CGI argument injection vulnerability disclosed on June 6, 2024, that was exploited by ransomware within 48 hours and added to CISA's Known Exploited Vulnerabilities catalog on June 12, 2024 — six days later. RedEye Security assessed that this vulnerability has a wider blast radius and expects a KEV listing within days of the fix shipping, once CISA's criteria of a CVE ID, a clear remediation, and reliable evidence of active exploitation are all met.

The official advisory, fixed version numbers, and technical details are expected at php.net at 14:00 UTC on October 21. That is the authoritative source for affected versions and confirmed mitigations.

Why it matters — With attacks already underway and mass exploitation expected within minutes of today's patch release, every administrator running PHP — across an estimated 1.9 million internet-exposed hosts — needs to know exactly which mitigations work, which don't, and why patching is the only real fix.

Sources differ on CVSS score for CVE-2026-109618 and CVE-2026-109619: 9.2 (CVSSv4.0) (tenable.com (citing PHP security team)) vs 10.0 (threat-intelligence.redeyesecurity.com (citing watchTowr's early comments and a leaked Hacker News post))

Reported by tenable.com, exploitr.com, threat-intelligence.redeyesecurity.com, sansec.io