AI found it. AI is stopping it.

Ramy HoussainiVP, Field CTO, F5

Debrup GhoshPrincipal Product Manager | F5

Muhammad AbidSr. Director, Product Marketing, F5

Every security team knows the moment: a critical flaw is published, and the first question is no longer, “What do we fix?” It’s, “What’s protecting us until we do?”

With PHP2Shell, defenders didn’t even get the usual head start. Details leaked on October 20, before any patch existed, and attackers were reportedly exploiting it before the fixes shipped the next day.

On October 21, the PHP project released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws that affect almost every PHP server on the internet. An attacker doesn’t need to log in. They only need to reach the server and send a crafted file-upload request that makes PHP run out of memory partway through. PHP then trusts the broken memory it leaves behind, and the attacker can steer it into running their own code, all before the application itself runs a single line. That means the request has to be stopped before it ever reaches PHP.

The flaws are decades old. What’s new is how they were made exploitable. In the words of the Wiz researchers who disclosed them, “Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”

When AI shrinks the time from an old bug to a working exploit, protection has to be in place before the advisory is.

For F5 customers running F5 WAF in blocking mode, whether on F5 BIG-IP, F5 NGINX or F5 Distributed Cloud, it was.

AI-Powered WAF was already blocking it

F5 security engineers took the published proof-of-concept exploit, built multiple variants of it, and sent them at an application protected by F5 WAF for Distributed Cloud with AI-powered WAF turned on. They added nothing specific to PHP2Shell and made no configuration changes.

The variants used different encodings, payload placements, HTTP methods, and common evasion techniques. AI-powered WAF stopped them in blocking mode. That’s real enforcement, not a log entry someone reads the next morning. Meanwhile, a normal request to the same application went straight through.

Here’s what one of those blocked requests looked like inside F5 WAF for Distributed Cloud:

In F5 testing, existing F5 WAF for Distributed Cloud signatures for PHP object serialization injection flagged a PHP2Shell-style request in PHP’s session upload-progress field, before any PHP2Shell-specific signature existed.

Blocking with confidence, not fear

Detecting an attack and being confident enough to block it are two different things. Many security teams keep new detections in alert-only mode, because blocking the wrong request means turning away a real customer. For those teams, an attack like PHP2Shell gets logged, not stopped.

AI-powered WAF changes that. At its core is a neural network, a type of machine learning model, trained on real attack data from F5’s global security operations. Because it learns from attack patterns instead of waiting for a new rule, it can recognize a fresh exploit that behaves like attacks it has seen before. For each suspicious request, it weighs the parts that look malicious against what it has learned, decides whether the content is truly harmful, and returns one risk verdict that the WAF acts on immediately.

AI-powered WAF rated a PHP2Shell attack request 95 out of 100, critical risk, based on what it had already learned from past attacks. Best practice: configure for the outcome you want.

For PHP2Shell, that verdict was 95 out of 100. The malicious requests were blocked on the spot, and legitimate traffic kept flowing.

That’s the shift that matters to the business. When you run in blocking mode, you block with confidence. You don’t have to worry that security might slow the business down, or that your help desk will fill up with complaints from customers who were wrongly turned away.

There’s one more piece of good news. Teams used to hold back detection rules that were more likely to misfire, out of fear of false positives. That advice no longer holds. F5 recommends turning on detection at every accuracy level (high, medium and low) and blocking requests that AI-powered WAF rates high or medium risk. The model then sees every available signal and does the work of filtering out the false alarms.

Virtual patching closes the exposure window

PHP2Shell isn’t an outlier. According to Mandiant’s M-Trends 2026 report, attackers now exploit vulnerabilities about seven days before a patch is available, on average. On the other side of the gap, the Verizon 2024 Data Breach Investigations Report found that organizations take about 55 days to fix even half of their critical vulnerabilities that are known to be under attack. Put those together and most organizations are exposed for weeks.

Virtual patching is how you cover that gap. It isn’t a single product feature. It’s a concept: anything that neutralizes the effect of a vulnerability without updating the vulnerable software itself. A WAF signature that blocks an exploit is a virtual patch. So is a security policy rule written for one specific flaw, and so is a model that recognizes the attack for what it is. In every case, malicious traffic is stopped in the data path and never reaches the vulnerable code, while developers fix the real problem through normal change control.

That’s what happened with PHP2Shell. F5 WAF across F5 Distributed Cloud, F5 BIG-IP, and F5 NGINX already provided coverage through existing signatures, before any PHP2Shell-specific rule existed.

Because we believe in defense in depth, F5 threat research didn’t stop there. The team has released dedicated signatures for CVE-2026-109618 and CVE-2026-109619 across these products, adding even more protection on top of what customers already had. Signature details and availability by product are in the F5 Security Advisory.

The next one is already written

PHP2Shell is a preview of what’s coming: flaws more than a decade old, turned into working exploits at AI speed, with the next one arriving even faster. Defenses that wait for a new rule after disclosure will keep losing the first round. Here’s how to be ready for this one and the next:

1. Patch PHP when your operations allow. Most teams can’t upgrade every server overnight, and that’s exactly the gap virtual patching is built to cover.
2. Make sure your WAF is blocking, not watching. A WAF in monitoring mode records an attack; it doesn’t stop one. Check that policies protecting PHP applications are in blocking mode.
3. Turn on AI-powered WAF and give it every signal. Enable detection at all accuracy levels, block high- and medium-risk requests, and confirm the dedicated PHP2Shell signatures are active.
4. Apply the dedicated PHP2Shell signatures as they are released, and track availability for your products in the F5 Security Advisory.
5. Look for signs of attempted exploitation. Review recent traffic for unusual multipart requests followed by PHP memory-limit errors or repeated HTTP 500 responses. Also look for unexpectedly large PHPSESSID response cookies and unexplained PHP worker restarts.
6. Shrink the attack surface. Tighten request and upload size limits, and disable upload endpoints your PHP applications don’t need.

You can’t control when the next vulnerability goes public. You can control whether you’re ready when it does.

Learn more about AI-powered risk scoring and AI-powered WAF.

The F5 Security Advisory has authoritative, up-to-date information on product impact, signature IDs, mitigations, and upcoming patch availability.

About the Authors

Ramy HoussainiVP, Field CTO, F5

More blogs by Ramy Houssaini

Debrup GhoshPrincipal Product Manager | F5

More blogs by Debrup Ghosh

Muhammad AbidSr. Director, Product Marketing, F5

Muhammad Abid is Senior Director of Product Marketing for Application Security and WAAP at F5. With over 20 years of experience scaling networking and cybersecurity businesses at Netskope, Cisco, Juniper, and Fortinet, Muhammad oversees F5’s unified WAAP portfolio, spanning WAF, API Security, Bot Defense, and Post-Quantum Cryptography.

More blogs by Muhammad Abid