Plenty of teams will treat today’s PHP emergency as a CDN ticket. Cloudflare already pushed WAF rules. Your firewall still sits in front of the app. The dashboard looks calm. That is the wrong read. CVE-2026-109618 and CVE-2026-109619 are remote code execution bugs in PHP itself, scored 9.2 by the PHP security team, with early attacks already showing up. If your cybersecurity program counts CMS plugins and edge filters while the language runtime stays on 8.1 or 7.4, you are watching the wrong layer.

The PHP Foundation scheduled an out-of-cycle release for 14:00 UTC on October 21, 2026. Expected fixed builds are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Everything from PHP 5 through 8.1 is end-of-life. There is no official fix coming for those branches. CERT-EU’s advisory 2026-018 says the bugs may reach back to PHP 5. Researcher Silas Cutler put internet-exposed vulnerable hosts north of 1.3 million. Henk Poley’s Shodan cut landed closer to 1.9 million. W3Techs still has PHP on 69.3 percent of sites with a known server-side language. WordPress, Drupal, Joomla, Laravel, Magento: the runtime under all of them is the patch target, not the theme you updated last week.

Cybersecurity Teams Keep Counting Plugins Instead of Interpreters

You already have a ritual for this class of news. Check WordPress. Check the hoster’s auto-updater. Glance at the WAF hit count. Close the change window if nothing looks on fire. That ritual is built for plugin CVEs and theme XSS. It fails when the language runtime is the bug.

Tenable’s roundup is blunt about the gap. Public reporting describes both CVEs as remote code execution. The PHP security team held technical details until the release, which did not stop exploit-shaped code from circulating, and did not stop Cloudflare CTO Dane Knecht from saying the company is “seeing early attacks emerging.” watchTowr told reporters it believes it reproduced CVE-2026-109618. Researcher Kirill Firsov posted a video of the chain, credited to LCFR and Calif.io. You do not need the internals to see the operational shape. Unauthenticated RCE against a runtime that sits under most of the public web gets mass-scanned the same hour the version string is known.

Core developer Gina Peter Banyard said the only mitigation is patching or upgrading PHP. Release manager Joe Ferguson shut down the usual ini-tinkering advice with “ini settings won’t save you.” That should end the hallway debate about turning off session upload progress or tightening a random php.ini knob. Configuration is not a substitute for a new binary. Your threat-protection catalog can still be useful as a temporary filter. It does not move you off 8.1.32.

This is also why “we patched WordPress” is a comforting lie. WordPress ships PHP code. It does not replace php-fpm, mod_php, or the CGI binary in the container image you froze in 2023. Drupal and Laravel shops make the same mistake with composer updates. You refreshed application files. The process answering port 443 is still yesterday’s interpreter.

The Hosts That Can’t Patch Are the Ones Getting Lined Up

Mass exploitation does not start with your hardest target. It starts with banners. PHP version strings, default pages, forgotten staging vhosts, and that one marketing microsite someone stood up on a cheap VPS. The same opportunistic pattern you already know from brute-force waves against admin panels. Noisy, cheap, and completely uninterested in your network diagram.

SecurityWeek’s framing is the part operators should take personally: mass exploitation looms because the research, the CVEs, and the public PoC-shaped noise arrived while a huge fraction of PHP on the internet cannot take the official fix. Linux distros may backport. They also may not, or they may take days you do not have. Shared hosts, appliance vendors that bundle PHP, and “internal” tools accidentally published through a reverse proxy are the messy middle. Those boxes rarely sit in the same patch train as your carefully maintained 8.4 app.

End-of-life PHP is a decision to stay exploitable

If you are still on 8.1, 8.0, 7.4, or anything older, today’s emergency release is a spectator event. CERT-EU’s advice for that situation is not a clever workaround. Isolate internet-facing applications from public networks until you have a fixed runtime. That sounds dramatic until you remember CISA’s Known Exploited Vulnerabilities catalog already includes PHP RCEs that ransomware crews used, including CVE-2024-4577 in PHP-CGI and CVE-2019-11043 in PHP-FPM. The industry has run this play before. Attackers kept the notes.

Defense in depth is supposed to make a runtime bug expensive. In practice, a lot of stacks put TLS, a WAF, and PHP on the same logical path and call it layered. The WAF inspects requests. The app trusts the interpreter. The interpreter is the vulnerability. There is no second execution environment to fail closed. Threat detection that only watches WordPress file integrity or plugin hashes will miss a shell dropped through the language itself, especially if the first payload lives in memory or in a writable upload path you never classified as code.

Unverified exploit code is already part of the weather. Tenable warned that some of it may be malware-laced. Do not “test” random GitHub gists against production to see if you are vulnerable. You will learn the hard way. Use version inventory, vendor advisories, and your own staging binaries. Cyber security programs that reward curiosity-as-validation are about to donate shells to whoever wrapped the proof in a miner.

Patch the Binary First, Then Prove Nobody Else Did

You need a two-clock plan. The first clock is hours: get a fixed interpreter onto every internet-reachable PHP worker you actually control. The second clock is days: find the PHP you forgot, and assume scanners were not polite while you scheduled a window.

1. Inventory the runtime, not the app name. On every host, container image, serverless layer, and appliance that can execute PHP, record the binary path, SAPI (php-fpm, Apache module, CGI, CLI used by cron), and PHP_VERSION. Include marketing sites, WP Engine-style shared pools you can still SSH to, CI runners that expose preview apps, and that forgotten phpMyAdmin. If you cannot list it, you cannot patch it.
2. Sort by exposure and branch. Internet-facing 8.2, 8.3, 8.4, and 8.5 go first, today, to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or whatever your distro backports as the equivalent. Confirm the running process, not the package that happens to be on disk. Reload php-fpm or the httpd workers and re-check the version banner.
3. Treat EOL PHP as an outage, not a backlog item. If the site must stay public and the vendor will not move you off 8.1 or 7.4, take it off the public internet. Private VPN, IP allowlists, or a maintenance page beat a webshell. CERT-EU already said this out loud. Use that cover with whoever owns uptime.
4. Keep edge filters in place, and label them temporary. WAF signatures, virtual patches, and managed rulesets buy you minutes to hours against known request shapes. They rotate as new vectors show up. Knecht called Cloudflare’s rules a stopgap for a reason. Do not close the change because a threat-protection counter ticked up. Origin patching is the control; the filter is a shock absorber.
5. Hunt like the box already lost. After you patch, look for new PHP files in upload and cache directories, unexpected cron entries, new admin users, outbound callbacks from www-data or nginx users, and modified interpreter configs. Incident response starts from “internet-facing and unpatched during a public RCE” rather than from a confirmed EDR alert. Prior PHP bugs became ransomware footholds. Plan for a web shell, not a clean miss.

Ongoing security hardening still matters after the binary moves. Drop unused SAPIs. Stop publishing phpinfo(). Make upload directories non-executable. Run php-fpm as a dedicated user with no extra groups. Pin PHP versions in base images so a rebuild cannot silently roll you backward. Put “interpreter version” in the same SLA you use for OpenSSL and the kernel. None of that replaces today’s upgrade. It stops the next RCE from being a season-long occupancy.

One more operational trap: PoC collection as a hobby. You do not need to reproduce php2shell in prod to justify the patch. You need a version number and an exposure flag. If leadership wants proof, show the pre-announcement, the CVSS 9.2 from the PHP team, the CERT-EU note, and the public statement that attacks are emerging. That is enough evidence for a production change. Waiting for a prettier write-up is how 1.9 million banners become a hit list.

Frequently Asked Questions

Does updating WordPress, Drupal, or Composer packages fix CVE-2026-109618 and CVE-2026-109619?

No. Those updates change application code. These CVEs sit in PHP itself, so you need a new interpreter build on every worker that handles requests. Confirm the running php-fpm, CGI, or Apache module version after the deploy, because disk packages and live processes diverge more often than people admit.

Can we wait on a WAF or firewall rule instead of rushing a PHP upgrade?

You can use those rules as a short delay, not as the fix. Cloudflare said it is updating mitigations as new vectors appear and still told operators to patch at the 14:00 UTC release. Ini tweaks will not save you either. If you cannot upgrade an EOL branch, isolation from the public internet is the remaining control.

What should incident response do if a host was online before you patched?

Assume opportunistic scanning started as soon as details and exploit-shaped code circulated. Check for new PHP files, unexpected scheduled tasks, credential additions, and outbound connections from the web user. Pull logs for the window between public discussion and your upgrade, and rotate secrets that the app could read, including database passwords and API keys in .env files.

Sources

• php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities
• PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws
• PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert