cloudflareJul 17, 2026

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities (opens in new tab)

Cloudflare has deployed WAF protections for two serious WordPress vulnerabilities: a high-severity SQL injection and a critical unauthenticated remote code execution flaw. The rules protect proxied WordPress sites on both free and paid Cloudflare plans, but they only reduce exposure while sites are patched. WordPress updates remain essential, with fixes available in versions 6.8.6, 6.9.5, 7.0.2, and 7.1 Beta 2. ## Vulnerabilities and Affected Versions - **CVE-2026-60137 — SQL injection** - Affects WordPress 6.8 and later. - Crafted input can alter database queries. - Rated High. - **CVE-2026-63030 — Unauthenticated RCE** - Affects WordPress 6.9 and later. - Exploits the REST API batch endpoint when persistent object caching is not enabled. - Requires no authentication or user interaction. - Rated Critical. - Versions earlier than 6.8 are not affected. - WordPress 6.8.6 fixes the SQL injection; later listed releases fix both vulnerabilities. ## Cloudflare WAF Protections - Cloudflare deployed the protections at **17:03 UTC on July 17, 2026**. - Both rules are enabled with a default **Block** action: - SQL injection rule: `1c060d3a371549219ee290d7ed933fcc` for Managed Rules and `db003b39b7774859a8d588ce33697a1a` for the Free Ruleset. - RCE rule: `7dfb2bd4708d4b88b9911dc0550664b6` for Managed Rules and `ebd3f2df15c74ddcbf6220c9b5ec246a` for the Free Ruleset. - The SQL injection rule blocks malicious parameter values before they reach WordPress. - The RCE rule targets requests attempting to access the vulnerable REST API path. ## Customer Actions - Pro, Business, and Enterprise customers should ensure Cloudflare Managed Rules are enabled. - Free-plan customers receive protection automatically through the Free Ruleset. - Review ruleset overrides, especially configurations that change blocking to logging. - Monitor Cloudflare Security Events for requests matching either rule. - Confirm that WordPress automatic updates succeeded and that the site runs a patched release. ## Ongoing Protection Cloudflare will monitor matching traffic and refine detections as attackers develop new variations. The WAF rules provide defense in depth, but they cannot repair vulnerable WordPress code. Administrators should patch WordPress immediately, verify that both WAF rules remain active with the **Block** action, and investigate suspicious requests if updating is temporarily impossible.

remote-code-executioncloudflarevulnerability-managementrest-api+3

cloudflareMar 4, 2026

Always-on detections: eliminating the WAF “log versus block” trade-off (opens in new tab)

Traditional WAFs force teams to choose between broad visibility in logging mode and active protection in blocking mode. Cloudflare’s new always-on detection model separates attack detection from mitigation, allowing every signature to inspect traffic and provide metadata without immediately blocking requests. Attack Signature Detection is available in Early Access, while Full-Transaction Detection is planned to improve accuracy by analyzing both requests and responses. ## The Always-On Framework - Detection signatures run on every proxied request for opted-in customers. - Results appear in Security Analytics and are added to request metadata usable by custom security rules. - Detection is separated from mitigation: - Signatures identify suspicious traffic. - Security rules decide whether to block, challenge, or otherwise handle it. - This preserves visibility into all matching signatures, even when one detection leads to a mitigation action. - Initially, detections can run after the request is sent to the origin, avoiding added latency. - Once a blocking rule depends on a detection, that detection runs inline and may add latency based on the application’s traffic profile. - Bot Score and Attack Score already use this detection model. ## Attack Signature Detection - The system uses the same analytical heuristics as Cloudflare Managed Rules but does not directly apply traffic actions. - It covers attack types such as: - SQL injection - Cross-site scripting - Remote code execution - Specific CVEs - Cloudflare’s Managed Ruleset contains more than 700 active rules, with new rules generally released weekly and emergency rules released for major vulnerabilities. - Each signature has: - A unique Ref ID - One confidence level - One or more attack categories - Confidence levels indicate expected false-positive risk: - **High:** Designed for high true-positive rates and low false positives; comparable to default Managed Rules behavior. - **Medium:** More likely to cause application-specific false positives and should be assessed before blocking. ## Detection Metadata Attack Signature Detection exposes three fields in Security Analytics and the Edge Rules Engine: - `cf.waf.signature.request.confidence` - An array of confidence values for matching signatures. - `cf.waf.signature.request.categories` - An array of matched attack categories, such as SQLi or XSS. - `cf.waf.signature.request.ref` - An array of up to 10 matching signature Ref IDs. These fields let teams create precise policies based on observed traffic rather than relying on broad, manually tuned rules. ## Using Security Analytics for Onboarding - Detection begins collecting data as soon as an application is proxied through Cloudflare. - Teams can review aggregate matches by signature and attack category. - Analysts can compare matches against request outcomes, including: - Blocked requests - Cached responses - Requests delivered to the origin - If malicious traffic reaches the origin, teams can quickly create appropriate security rules. - Analytics also helps identify false positives and determine where exceptions are needed. ## Full-Transaction Detection - The planned system will analyze the complete HTTP transaction, including both request and response. - Correlating both sides should reduce false positives compared with request-only engines. - It may detect threats that request analysis misses, including: - Reflective SQL injection - Subtle data-exfiltration behavior - Dangerous misconfigurations visible only in responses The practical recommendation is to enable Attack Signature Detection during application onboarding, use its metadata and analytics to understand real traffic, and then create targeted mitigation rules. This preserves continuous visibility while allowing teams to deploy blocking protections with greater confidence.

remote-code-executionweb-application-firewallcross-site-scriptingsql-injection+4