A web application firewall fixes none of this autumn’s big web flaws. It can keep attackers off them while you patch. We’ve checked PHP, Java, WordPress and Atlassian, and here’s what ten major WAF vendors have published for each, where they’ve said nothing, and where a WAF is no use at all.
Status: correct as at 25 October 2026. Cyber-Threat.net has not tested any of the products mentioned; everything below comes from the vendors’ own published guidance, linked in each case. No vendor sponsored, reviewed or saw this article before publication, and there are no affiliate links.
The flaws in play
These are the web-facing flaws from the past six weeks or so that matter most for anyone running a WAF.
- PHP2Shell, CVE-2026-109618 and CVE-2026-109619 (PHP, 21 October). These are two remote code execution bugs in PHP itself. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and CISA says to patch immediately. On 23 October PHP flagged a follow-on bug, CVE-2026-115560. Those releases don’t fix it, though PHP calls it “unlikely in practice”. Our patch-and-hunt guide covers the PHP side.
- Oracle WebLogic, CVE-2026-91323, CVE-2026-87302 and CVE-2026-83399 (20 October). Oracle’s October Critical Patch Update rates the first two, which are reachable over HTTP, at 9.8 and 9.1. The third, also 9.8, comes in over T3/IIOP.
- Apache Struts, CVE-2026-104711 (S2-075, early October). This is OGNL injection in the legacy RESTful action mapper. Apache rates it Moderate, though CISA’s scoring on the US vulnerability database gives it 9.8, and default setups aren’t affected. Separately, CISA added CVE-2016-3081, a ten-year-old Struts flaw, to its exploited list on 8 October. It only bites where Dynamic Method Invocation is switched on, but F5 Labs, summarising a joint FBI-led advisory, lists it among the flaws exploited by hackers working for a sanctioned China-linked firm, using the firm’s own custom scanner alongside open-source tools. That is why a 2016 bug sits in this table.
- Apache Tomcat, CVE-2026-101296 (20 October). This one is an authentication bypass in JNDIRealm. It only applies when Tomcat talks to LDAP with a non-GSSAPI SASL mechanism (oss-security, 20 October).
- Java SE JSSE, CVE-2026-91403 (21 October). Oracle’s out-of-band alert stops Java trusting a set of affected eMudhra intermediate CA certificates. That is a change to which certificates Java trusts, so the fix is a Java update.
- WordPress core, CVE-2026-87902 (22 September). This is an unauthenticated page-template file inclusion that can become code execution under certain conditions. It was fixed in 7.1.2 with backports to 4.7 and went onto CISA’s exploited list on 25 September (NVD). Its July predecessor, WP2Shell (CVE-2026-63030), is older than our window, but CISA has listed both of its CVEs (63030 and the SQL injection 60137 it chains with) as exploited since 21 July, so it gets a column too.
- Atlassian Data Center, CVE-2026-21589 (5 October). This is a pre-authentication file read across Jira, Confluence, Bitbucket and others. If you can’t patch at once, Atlassian’s own advisory says to take affected instances off the internet first, and failing that, to block the attack with a WAF or proxy rule. CISA added it on 15 October.
We left out the other items on our alerts ticker on purpose. Arista EOS, the SafePay VPN flaws, LiteLLM and ConnectWise are network-device or supply-chain problems, and Plex servers rarely sit behind a WAF.
Why a WAF matters this month
Patching takes days. Attackers don’t wait. Amazon says it saw a PHP2Shell exploit attempt on 17 October, four days before the flaw was made public, and F5 Labs saw scanning start before disclosure too. Cloudflare had rules live about nine hours before disclosure, and Akamai switched its rule from alert to block within four hours of it. That head start is what a WAF buys you.
Where a WAF can’t help
- JSSE. The fix changes which certificate authorities Java trusts. That decision happens inside Java, and no WAF rule touches it. Patch the JDK.
- WebLogic over T3/IIOP. A WAF only understands HTTP. CVE-2026-83399 never passes through one, and T3 shouldn’t face the internet anyway.
- Tomcat’s LDAP bypass. The bug lives in how Tomcat checks passwords against a directory. To a WAF, a malicious login looks much like a normal one. No vendor we checked has published anything for it, and we’d be surprised if one did.
- Anything that bypasses the WAF. If your origin answers the internet directly, attackers can go around the WAF. Microsoft’s origin security guidance is a clear example of what to look for from your own vendor. Body-size limits matter too: AWS and Google both tell you to handle oversized requests explicitly.
Even where a WAF does help, it’s the stopgap and not the cure. That’s the whole point of virtual patching, and Akamai, AWS, Cloudflare, Google, Imperva and Microsoft all say in their own guidance to patch as well.
Who has published what
Vendors are listed alphabetically, not ranked. Yes means the vendor has published a rule or guidance that names the CVE. Opt-in means a rule exists but you have to enable it. Partly means the vendor’s coverage is incomplete or still rolling out. Existing rules means the vendor says rules it already had stop the attack, but we could not find a rule that names the CVE. Not released means a rule has been written but isn’t in a release you can install yet. None found means we found nothing published by 25 October, which isn’t proof that no protection exists. The “Struts” column covers both S2-075 and CVE-2016-3081. Tomcat and JSSE are left out because we found nothing from any vendor for either.
| Vendor | PHP2Shell | WebLogic | Struts | WordPress 87902 | WP2Shell | Atlassian |
|---|---|---|---|---|---|---|
| Akamai | Yes | None found | None found | None found | Yes | Yes |
| AWS WAF | Yes | None found | None found | None found | None found | None found |
| Cloudflare | Yes | None found | None found | Yes | Yes | Yes |
| F5 | Existing rules | None found | None found | None found | None found | None found |
| Fastly | Opt-in | None found | None found | None found | Opt-in | Opt-in |
| Fortinet FortiWeb | Partly | None found | None found | None found | Yes | Yes |
| Google Cloud Armor | Yes | None found | None found | None found | None found | None found |
| Imperva | Yes | None found | None found | None found | Yes | Yes |
| Microsoft Azure WAF | Opt-in | None found | None found | None found | Opt-in | None found |
| OWASP CRS | Not released | None found | None found | None found | Existing rules | None found |
The Java columns are where it gets thin. AWS, Azure, Google and CRS all document general Java attack rules (AWS’s Java deserialisation rules, Azure’s and Google’s Java rule families, CRS’s Java group), and others may have similar rules. None of the ten has published anything we could find that ties those rules to these CVEs. Many rule sets have carried Struts rules for years, but no vendor restated coverage for CVE-2016-3081 this month, so ask your vendor by CVE number rather than taking it on trust.
Vendor by vendor
- Akamai App & API Protector. Akamai has rules for PHP2Shell (switched from alert to block on 21 October, per its timeline), WP2Shell (20 July) and Atlassian (7 October), and it says its existing command injection rules also catch PHP2Shell payloads.
- AWS WAF. AWS has PHP2Shell guidance (21 October, updated 23 October). Default rule group versions pick it up automatically, but pinned ones don’t. AWS says the rules also help against CVE-2026-115560. Its managed rules changelog names no other CVE here.
- Cloudflare. Cloudflare names four of the six flaws in its published rules, more than any other vendor here. It deployed PHP2Shell rules before disclosure and says one of them also covers CVE-2026-115560, provided the site keeps PHP’s default upload progress field name. It shipped an emergency WordPress 87902 release (25 September), WP2Shell rules (17 July) and an Atlassian rule (12 October). Paid plans should confirm the managed ruleset is set to block.
- F5 (BIG-IP Advanced WAF, Distributed Cloud). F5 says that in its own testing (22 October), existing PHP object serialisation signatures in F5 WAF for Distributed Cloud, in blocking mode, stopped PHP2Shell-style requests before any PHP2Shell-specific signature existed. F5 says customers running F5 WAF in blocking mode on BIG-IP and NGINX were protected too. Its PHP2Shell advisory and signature update list sit behind its support portal, which we couldn’t read, so we can’t confirm what has been added since. We found nothing public for the other flaws.
- Fastly Next-Gen WAF. Fastly has virtual patches for PHP2Shell, WP2Shell and Atlassian, and every one is opt-in. A new setting (22 October) switches on future patches automatically, but it doesn’t reach back to the ones already released.
- Fortinet FortiWeb. Fortinet has three PHP2Shell signatures; two arrive pending and need approving. It also lists FortiWeb protection in its WP2Shell and Atlassian outbreak alerts.
- Google Cloud Armor. Google applies its PHP2Shell protection automatically where Cloud Armor managed rules are active, though those managed rules are still listed as a preview. Its release notes name none of the other CVEs. Google says its newer managed rules are “powered by Thales Imperva”, but it hasn’t said whether Imperva’s CVE coverage carries over.
- Imperva. Cloud WAF is covered out of the box for PHP2Shell, WP2Shell (18 July) and Atlassian (8 October). For PHP2Shell, Elastic WAF needs a software update, and WAF Gateway needs a software update plus a security content update.
- Microsoft Azure WAF. Microsoft has published PHP2Shell custom rules for Front Door, Application Gateway and Application Gateway for Containers, which you have to add yourself. Its Front Door managed rule is rolling out until 28 October. It is off by default, removes suspect content from responses rather than blocking requests, and writes no log entries. Application Gateway gets a header rewrite workaround until its own managed rule arrives. Microsoft’s default rule sets for Front Door and Application Gateway include a WP2Shell rule, but it is a paranoia level 2 rule, and those are switched off by default in the current rule set.
- ModSecurity / OWASP CRS. The latest release came out on 2 October. A rule blocking the user agents of known PHP2Shell exploit tools was merged on 22 October but isn’t in a release yet, and it won’t stop anyone who changes their user agent. The maintainers declined a WP2Shell-specific rule in July, saying CRS’s existing rules should already block SQL injection and command injection exploits.
A rule in detection mode is a security guard with a clipboard and no keys. Check yours. Cloudflare’s paid plans need the managed ruleset confirmed in block mode, pinned AWS rule group versions need updating, two of FortiWeb’s PHP2Shell signatures arrive pending, and every Fastly and Azure entry above is opt-in.
Bottom line
- Patch PHP, WebLogic, Struts, Tomcat, the JDK, WordPress and Atlassian. Nothing in the table replaces that.
- For the Java flaws, assume your WAF has nothing specific unless your vendor names the CVE.
- Where a rule exists, confirm it’s enabled, current and blocking, not just logging.
- Make sure nobody can reach your origin without going through the WAF.
“Set it and forget it” works for rotisserie chickens. It doesn’t work for WAF rule sets.
Cyber-Threat.net has not tested the products named. Vendor guidance is changing daily; check the linked pages before you act. No sponsorship, no affiliate links.