On July 17, 2026, Cloudflare deployed new Web Application Firewall (WAF) rules to protect every customer whose traffic passes through its network — including free-tier users — from two high-severity vulnerabilities in WordPress. The rules went live at 17:03 UTC after the WordPress security team privately disclosed the flaws so Cloudflare could prepare defenses before public details circulated Cloudflare: WAF protects WordPress from two high-severity vulnerabilities.
The two flaws
The pair affects different parts of the request path, and both are serious enough that WordPress is treating them as its highest-severity, highest-priority class of issue:
- CVE-2026-60137 — SQL injection (rated High). Present in WordPress 6.8 and later, it lets crafted input alter a database query. SQL injection can expose or corrupt stored data and, in chained attacks, open the door to deeper compromise.
- CVE-2026-63030 — Unauthenticated remote code execution. Present in WordPress 6.9 and later, it allows an unauthenticated attacker to execute code on the server. An RCE that needs no login is among the most dangerous bug classes a public website can face, because it can be fired at scale by automated bots.
Versions earlier than 6.8 are not affected. WordPress shipped fixes in version 7.0.2, with backports for the still-supported branches 6.9.5, 6.8.6, and 7.1 Beta 2, and is forcing automatic updates to affected sites so most installations patch themselves.
What the WAF actually does here
A WAF sits in front of an origin server and inspects incoming HTTP requests, blocking ones that match known attack patterns. In this case, Cloudflare’s managed rules are tuned to the specific request shapes of these two CVEs, so malicious traffic is dropped at the edge before it ever reaches the WordPress PHP process.
The key point Cloudflare stresses: the WAF is a stopgap, not a cure. It dramatically reduces exposure for the window between disclosure and patching, but it does not fix the vulnerable code on the server. A site left unpatched remains vulnerable the moment traffic bypasses the WAF — for example, if DNS is pointed directly at the origin, or if an attacker finds a path the rules don’t cover.
What site owners should do now
If your WordPress site sits behind Cloudflare, the edge is already helping. That is not a reason to relax:
- Confirm the patched release. Check that you are on 7.0.2, or on the backport for your branch (6.9.5 or 6.8.6). Even with auto-update forced, verify rather than assume — especially on custom or heavily modified installs.
- Keep traffic proxied. The WAF only protects what actually flows through it. Ensure your DNS records are orange-clouded (proxied) and that no direct origin IP is exposed.
- Patch plugins and themes too. Core WordPress is the headline here, but a WAF tuned to core CVEs won’t catch equivalent flaws in third-party code; keep everything updated.
- Watch the official advisory. WordPress publishes its security releases with full detail and guidance for site operators WordPress.org news and security releases.
Why coordinated disclosure matters
The fact that Cloudflare had rules ready at disclosure time is the quiet headline. When a vendor shares details with a major edge provider under embargo, millions of sites gain a protective layer the same day the bug becomes public — turning a potential mass-exploitation event into a managed rollout. It is the model that makes “patch now, but you had a head start” realistic for the long tail of small site owners who can’t react in minutes.
Bottom line: If your WordPress site is proxied through Cloudflare, the WAF is already blunting both CVE-2026-60137 and CVE-2026-63030 at the edge — but the fix still lives in version 7.0.2 (or the relevant backport). Confirm you are patched, keep traffic behind the WAF, and treat the rule as breathing room, not a replacement for updating.
