A WAF is not a patch
A web application firewall inspects requests before they reach your server. The PHP running behind it stays exactly as it was. The PHP project says there is no complete mitigation for CVE-2026-109618 and CVE-2026-109619 and that upgrading is the only safe option. Use a WAF rule to gain time while you patch.
What Cloudflare published
On 21 October 2026 Cloudflare published managed WAF rules aimed at these two CVEs. According to Cloudflare:
- The rules are named "Generic Rules - Anomalous Execution - 1" to "- 7".
- They sit in the Managed Free Ruleset (Free plan, on by default) and in the Managed Ruleset (Pro, Business and Enterprise).
- The action is Block.
- A response-side rule that blocks by default was added to the Managed Response Firewall Default ruleset.
The mitigation runs at Cloudflare's edge. PHP on your origin stays unpatched. We keep the details, evidence and links on the Cloudflare WAF page.
Cloudflare also reports that it saw attack traffic against its customers and that attackers changed their payloads to get past WAF rules. That is Cloudflare's own telemetry; no volumes or indicators were published. In practice, a rule that blocks today's request shape may miss tomorrow's.
Why the origin must refuse everyone else
A WAF only sees traffic that goes through it. Your server still has an IP address, and attackers can find it in old DNS records, certificate transparency logs, mail headers or an internet-wide scan. If the origin answers on ports 80 and 443 to anyone, a request sent straight to that IP never meets the WAF.
A WAF in front of an open origin therefore filters only the attackers who choose to go through it. The steps below make the origin refuse direct connections.
Lock the origin to Cloudflare
Cloudflare's guide lists several methods and rates them. From strongest to weakest:
1. Cloudflare Tunnel
cloudflared runs on your server and opens outbound connections to Cloudflare. You then block all inbound web traffic at the firewall, so nothing but the tunnel can reach the site. No public listener is left to attack. Setup: Cloudflare Tunnel docs. Cloudflare notes that Authenticated Origin Pulls does not apply to tunneled hostnames, because there is no inbound listener.
2. Authenticated Origin Pulls (mTLS)
Cloudflare presents a client certificate to your origin, and the origin rejects connections without one. It needs SSL/TLS mode Full or Full (strict) and works on all plans. The shared Cloudflare certificate only proves that the request came from Cloudflare's network. To prove it came through your account, upload your own certificate (zone-level or per-hostname). Setup guides for global, zone-level and per-hostname modes are in the Cloudflare docs.
On nginx the origin side looks like this, with the CA file saved where the setup guide tells you:
ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client on;
On Apache:
SSLVerifyClient require
SSLCACertificateFile /path/to/origin-pull-ca.pem
Test from an outside machine with curl -k https://ORIGIN_IP/ -H 'Host: example.com'. The handshake should fail.
3. Firewall allowlist of Cloudflare IP ranges
Cloudflare publishes its ranges at cloudflare.com/ips, as plain lists at https://www.cloudflare.com/ips-v4 and https://www.cloudflare.com/ips-v6. The Cloudflare docs give this pattern for iptables: accept web traffic from each range, then drop all other web traffic.
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
iptables -I INPUT -p tcp -m multiport --dports http,https -s "$ip" -j ACCEPT
done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
ip6tables -I INPUT -p tcp -m multiport --dports http,https -s "$ip" -j ACCEPT
done
iptables -A INPUT -p tcp -m multiport --dports http,https -j DROP
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROP
Read the lists before you run this, and make sure your own SSH and monitoring access does not depend on those ports. Cloudflare rates this method below the first two, because it is "vulnerable to IP spoofing". Ranges change rarely and new ones are announced before use, so schedule a refresh. Cloud providers have their own security-group tools for the same job.
Check for leaks
Review DNS-only records for the origin IP (A records for mail, ftp or direct subdomains, SPF entries), keep mail off the web server, and consider changing the origin IP if it was ever public. Cloudflare's origin protection guide covers these.
Other firewalls: what the sources say
Several products work at the host or application level. The table lists only what our sources say about them.
| Product | What our sources say |
|---|---|
| Imunify360 | CloudLinux reported on 21 Oct 2026 that ruleset 8.83 blocks one public exploit pattern on Apache and is log-only on LiteSpeed. No claim about other patterns. |
| ModSecurity with OWASP CRS | Our research found no vendor statement tying a rule to these CVEs. Rules you write yourself are your own responsibility to test. |
| Patchstack | Its 21 Oct article advises updating PHP and makes no claim of a virtual patch. |
| Wordfence | Our research found no firewall rule page for these CVEs. |
None of these changes the PHP binary. Plugin-level firewalls run as PHP application code, and the mod_php attack can fire before any application code runs. Do not count on them to stop it.
What to do next
- Patch. Move to a fixed build: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor backport for older branches. See /fix for your distribution or panel.
- Restart every PHP worker. A new package is not a fixed server until the old processes are gone.
- Verify from the web side with after patching.
If you cannot patch today, add the interim settings and keep the WAF and the locked origin in place.
Last reviewed on 22 October 2026.