PHP2Shell: What the Critical PHP Flaws Mean for Your Web Servers

PHP2Shell: the patch is out. Here’s how to check no one got in first.

If your organization runs WordPress, Magento, Drupal or any PHP-based site, PHP2Shell needs your attention this week.

On October 20, details of two critical PHP vulnerabilities leaked online before a fix existed. They are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 under CVSS v4.0. The PHP project shipped emergency patches on October 21.

This is not a plugin bug or a single CMS problem. It sits in PHP itself, so the exposure follows the runtime wherever it is deployed.

What happened

Both flaws allow unauthenticated remote code execution. An attacker can take over a web server with a single crafted request, before your application code runs. No login, no user interaction. A related flaw lets attackers read server memory, which can hold passwords, tokens and API keys.

The leak changed the timeline. Researchers at Sansec expected mass attacks within 15 minutes of the patch going live, and Cloudflare reported signs of exploitation before the fix shipped. A public proof-of-concept is already circulating.

The scale is large. Palo Alto Networks Unit 42 counts more than 22.6 million exposed instances that are potentially vulnerable, and Wiz says PHP powers 70% of websites. Government cyber agencies in the UK, Canada, Australia and the EU urged operators to take sites offline until patched. Finland's government and the Dutch House of Representatives disconnected theirs. (Cybersecurity Dive)

Who found it

Two teams found the flaws independently. Wiz Research, now part of Google, used its Wiz Atlas tool and Google's Gemini 4 Argon. Calif used OpenAI's GPT-5.6 Sol. Both worked with the PHP team on the fix. The bugs had sat in PHP's core engine for more than a decade, and frontier AI made a complex exploit chain practical in days.

That is the bigger lesson. Attackers have the same models. Old, hard-to-exploit flaws are now realistic targets, and the window between disclosure and attack keeps shrinking.

Who is exposed

Public reporting puts affected versions as far back as PHP 5.4. Fixes are available for supported branches only:

That last row is the real problem. Legacy apps, forgotten marketing microsites and vendor appliances often run end-of-life PHP. They will stay exploitable until they are upgraded, isolated or retired.

Online stores carry extra risk. An attacker with code execution can plant a hidden card skimmer on a checkout page and collect payment data for weeks before anyone notices.

What to do today

1. Find every PHP instance. Include staging, dev and third-party hosted sites. You cannot patch what you have not inventoried.
2. Patch supported versions to the releases above, starting with internet-facing and payment systems. Restart PHP-FPM or the web server so the patched version loads.
3. Contain what you cannot patch. Put end-of-life PHP behind a WAF, restrict access or take it offline. Apply a vendor backport (they exist for 7.4, 8.0 and 8.1) or upgrade. Until then, use a WAF with PHP2Shell rules and PHP's interim settings. These buy time, not safety. PHP says updating is the only complete fix.
4. Apply a vendor backport (they exist for 7.4, 8.0 and 8.1) or upgrade. Until then, put it behind a WAF with PHP2Shell rules, restrict access or take it offline.
5. Check whether anyone got in. Patching does not remove an attacker who got in first. Look for web server processes spawning shells, new or modified PHP files, new admin accounts, outbound connections to unfamiliar destinations and changes to checkout pages. Spikes in memory errors, worker crashes or segfaults are warning signs, and Wiz also flags oversized PHPSESSID cookies. If you find an intruder, isolate the system, preserve web server and PHP logs, and report it to your local FBI field office.
6. Keep watching. New exploit variants will follow. Detection needs to run around the clock, not just this week.

Patching is not the hard part

Most teams can deploy a patch. The harder question is whether someone validated the threat before the patch existed, knew exactly which systems were exposed, and is still watching for what comes next.

When PHP2Shell leaked, our SOC validated the threat and notified customers with payment environments first, then the rest of our base. We are building detections with our technology partners and supporting customers through patching and end-of-life decisions. Our 24x7 SOC runs on Google SecOps, with named practitioners reviewing every high-impact action. That combination of machine speed and human accountability is a big part of why Google named Foresite its 2026 Google Cloud Security Partner of the Year for North America.

Get a second set of eyes

We are offering a complimentary PHP2Shell exposure review. In 20 minutes we will show you where you stand and what to fix first.

Book a free PHP2Shell exposure review → · Download the PHP2Shell threat brief →

FAQ

What is PHP2Shell? Two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution on web servers.

Am I affected if I use WordPress? If your WordPress site runs on an unpatched PHP version, yes. The flaw is in PHP, not WordPress, so updating WordPress alone does not fix it.

Which PHP versions are fixed? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older will not receive official fixes.

Is PHP2Shell being exploited? Cloudflare and Patchstack reported exploitation attempts on October 21, and public proof-of-concept code exists. Neither CVE is in CISA's Known Exploited Vulnerabilities catalog yet. Assume active scanning.

I patched. Am I safe? Patching closes the door. It does not remove an attacker who got in before you patched. Check your servers for signs of an intruder.

Should I take my site offline? If you cannot patch or contain it today, yes. That is what UK, Canadian, Australian and EU cyber agencies advised.

Sources: PHP security advisory, Wiz Research, OpenAI, Unit 42, Wired, Cybersecurity Dive, watchTowr, SecurityWeek, Brandefense.