Some companies see cybersecurity as a cost center. We see things a little different. LEARN MORE >
Experiencing a Breach?
BLOG
PHP2Shell: What to Know. What to Do.
Key Takeaways
- PHP2Shell is critical. Two flaws in the PHP engine (CVE-2026-109618 and CVE-2026-109619) let unauthenticated attackers run code on a web server with one crafted request. They carry a severity score of 9.2 out of 10.
- The reach is massive. PHP runs behind nearly 70% of websites with a known server-side language, including WordPress, Drupal, Joomla and Magento.
- Patch the PHP engine itself. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Updating WordPress, a plugin or a framework leaves the hole open.
- Isolate what you can’t patch today. Take it offline or put it behind a VPN or IP allowlist. WAF rules set to block are a bridge to the patch, not a fix.
- Assume exposure. Exploit attempts began before the fix existed, so check web servers back to at least Oct. 20.
- Inventory is the real defense. Know where you run PHP, what version it is, who owns it and whether it can be reached from the internet.
By now you’ve likely seen the headlines.
Two critical PHP vulnerabilities, nicknamed “PHP2Shell” (CVE-2026-109618 and CVE-2026-109619), were recently discovered by a human cybersecurity team augmented by frontier AI models.
Or was it the other way around?
Either way, it was a big deal. Left unpatched, these flaws allow unauthenticated attackers to run code on a web server. All it takes is a crafted web request. No login required.
That’s why they carry a severity score of 9.2 out of 10.
The reach is what makes this one so dangerous. PHP runs behind nearly 70% of websites with a known server-side language. It powers WordPress, Drupal, Joomla, Magento and a long list of software most people never think of as PHP.
Naturally, the response has been swift. The NSA, the UK’s National Cyber Security Centre (NCSC) and CERT-EU are all giving the same advice: patch now, or take your system offline until you can.
Plenty of organizations took that advice literally. Government agencies, hospitals and hosting providers across the UK and Europe pulled sites offline temporarily. The Dutch NCSC even took down its own website as a precaution.
But the attackers have moved fast too. Technical details leaked before patch, so exploit attempts began before the fix existed. Within days, researchers had caught attackers launching working shells on unpatched honeypot servers.
Bottom line: This is serious. Stay calm, and treat it as a cybersecurity emergency.
What to Do Immediately
- Find every place PHP runs. Include the places you may not think of as PHP: WordPress, Drupal, Joomla, Magento, hosting control panels, vendor appliances and device or IoT admin interfaces. Start with anything reachable from the internet, and put Apache with mod_php at the top of the list.
- Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you run your OS vendor’s PHP packages (Red Hat, Ubuntu, Debian), follow their specific instructions, since their fixed version numbers will differ. For vendor appliances, contact the vendor and restrict access until they ship a fix. Keep in mind that both flaws live in the PHP engine itself, so the fix lives there too. Updating WordPress, a plugin or a framework leaves the hole open.
- Upgrade or isolate PHP 8.1 and older. The PHP project has stopped supporting these versions, so they’ll stay vulnerable. Upgrade them or get them off the internet.
- Isolate anything you can’t patch today. Take it offline or put it behind a VPN or IP allowlist. Web application firewall (WAF) rules can buy you time. Confirm they’re set to block, since logging mode only tells you what already got through. Treat WAF rules as a bridge to the patch.
- Assume exposure before you patched.Attacks began before the patch existed. Check web servers back to at least Oct. 20 for:
- PHP processes launching shells or commands
- New or modified files in web directories
- Unexpected outbound connections
- Keep watching these systems. Install endpoint detection and response (EDR) and centralize your logs so you keep visibility long after the patch goes in.
The Big Takeaway
Critical vulnerabilities land every week. This one is worse than most, but the response playbook still works.
Right now you need answers to these four questions; and you need these answers RIGHT NOW.
- Where do we run PHP?
- What version is it?
- Who owns it?
- Can it be reached from the internet?
It’s basic asset and software inventory: knowing which applications and code libraries you actually run.
It’s unglamorous work. But it can mean the difference between a two-day patch cycle and a two-week nightmare.
The Impact of AI
Remember, these PHP2Shell flaws sat unnoticed within PHP for more than a decade. Then AI showed up and researchers suddenly found them in a matter of days.
This time, the good guys found the holes a few hours before the bad guys.
Next time it may play out differently.
Either way, AI will be a major part of the battle.
We wrote about this shift earlier this year in Claude Mythos & The Coming AI Vulnerability Storm.
It’s a lot to take in. But remember:
The pace of discovery may belong to whoever has the best AI.
But the pace of your response still belongs to you.
Need a hand?
Whether you need help finding where PHP lives in your environment, a second set of eyes on suspicious activity or an in-depth conversation about the rise of AI in the cybersecurity space, our team is ready.
