PHP2Shell: Two Critical PHP Flaws Hit Every WordPress and Laravel Site. Here's the Patch Plan

Today is a different kind of patch day. Two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, got emergency fixes on October 21, 2026. Both are rated CVSS v4.0 9.2, both can lead to remote code execution, and attacks were already being reported before the patches shipped. If you run WordPress, Laravel, Drupal, or anything else on PHP, this is your afternoon.

What happened

The problem is in the PHP interpreter, not in any CMS or plugin. According to BleepingComputer's coverage, both bugs come from PHP leaving memory in a bad state when a request ends abnormally. One involves out-of-memory handling, the other involves stale global state that can trigger a use-after-free. In both cases the result can be code execution with the web worker's privileges, and no login is required.

The timeline was compressed. Details leaked ahead of the coordinated disclosure, Patchstack reported active exploitation incidents from hosting partners that morning, and PHP released fixes at about 13:52 UTC. Cloudflare's CTO said the company was already seeing early attacks.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older no longer get official updates, though some Linux distributions and LTS vendors backport fixes, and minimal source backports exist for 7.4, 8.0, and 8.1. Researchers say the flaws reach back to at least PHP 5.4.

What Cloudflare did, and what it does not do

Cloudflare deployed emergency WAF rules for the known exploit vectors, and says they are available to every plan, including Free. That is genuinely useful for the hours before you can patch.

It is also, in Cloudflare's own framing, a stopgap. Two caveats matter for agencies:

• The rules only see traffic that goes through Cloudflare. If your origin server is reachable directly by IP, an attacker can skip the WAF entirely. Locking the origin down to Cloudflare's IP ranges is the difference between a real layer and a false sense of security.
• Rules cover known exploit methods. New variants will keep appearing, and a WAF rule is always a step behind the exploit.

Our take

We treat this as a same-day patch for every client environment, and we would not wait for a maintenance window. Here is why we are not using our usual 48 to 72 hour window for security releases: the flaw is unauthenticated, it sits below the application layer, and exploitation is already underway. Your plugin hygiene, strong passwords, and two-factor setup do not matter if the interpreter itself can be taken over before your application code runs.

It also changes who is responsible. Most WordPress security news is about a plugin or core release you control. This one is about the PHP version your host runs, which on managed hosting may not be yours to change. So the first job is finding out where each site actually stands.

The less comfortable lesson is about inventory. Agencies that know exactly which PHP version every site runs, including staging copies and forgotten legacy sites, will clear this in an hour. Agencies that do not will spend the day finding out.

Practical steps for today

1. Inventory PHP versions. Check every site and server, including staging, dev, and old client sites nobody has touched in a year.
2. Update to a fixed version. On your own servers, move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install your distribution's patched package. Restart PHP-FPM or Apache so the new binary is actually in use.
3. On managed hosting, ask or check. Look at your host's status page or security notice, confirm the patched version is live for your plan, and open a ticket if it is not. Do not assume.
4. Lock the origin to Cloudflare. If you rely on Cloudflare's rules in the meantime, make sure the server only accepts traffic from Cloudflare.
5. Treat PHP 8.1 and older as an emergency migration. Official fixes are not coming for those branches. Use a vendor backport if you have one and plan the upgrade right after.
6. Do not rely on ini tweaks. PHP lists partial mitigations such as memory_limit=-1 and session.upload_progress.enabled=0, but PHP's own developers say they do not make an installation safe. Patching is the only real fix.
7. If a site could not be patched while attacks were live, consider rotating credentials the server holds and checking for unexpected files and admin users.
8. Skip "fix" plugins and pasted snippets. Nothing at the CMS layer fixes an interpreter bug, and fake remedies are a classic follow-on attack.

For clients, the message is simple: a critical PHP security update shipped, we are applying it today, and no action is needed on their end.

Originally referenced: PHP ships emergency patches for critical PHP2Shell flaws on BleepingComputer, with additional detail from Patchstack and Tenable.

If you are not sure which PHP version your sites run, or you want a standing process for responses like this one, get in touch. We handle patching and monitoring for our maintenance clients, and today is exactly why.