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.

wordpresscloudflarevulnerability-managementrest-api+3

cloudflareApr 1, 2026

Introducing EmDash — the spiritual successor to WordPress that solves plugin security (opens in new tab)

EmDash is presented as a modern, TypeScript-based successor to WordPress, designed for today’s serverless hosting environment. Its central innovation is isolating plugins in sandboxed Dynamic Workers and granting them only explicitly declared capabilities. The project aims to preserve WordPress’s open-source publishing model while addressing plugin security, marketplace dependence, and licensing concerns. ## Modernizing WordPress for Today’s Web - WordPress powers more than 40% of the Internet but was designed when hosting commonly meant managing virtual private servers. - EmDash is: - Written entirely in TypeScript - Built on Astro - Serverless, while still deployable on personal hardware or Node.js servers - Fully open source and MIT licensed - Intended to remain compatible with WordPress-style functionality without using WordPress code - Version 0.1.0 is available as an early developer beta for Cloudflare or Node.js deployment, along with an online playground. ## Building on WordPress’s Publishing Legacy - WordPress democratized publishing and created a large ecosystem of core contributors, plugin developers, and theme developers. - The authors argue that WordPress will continue to have a role, but newer developers increasingly use Astro and TypeScript frameworks. - EmDash seeks to provide a similarly accessible, inexpensive, and open publishing platform suited to modern development practices. ## Sandboxed Plugins and Explicit Permissions - WordPress plugins are PHP scripts with direct access to the site’s database and filesystem. - This lack of isolation is identified as the source of most WordPress security problems: - 96% of WordPress site security issues reportedly originate in plugins. - High-severity vulnerabilities increased substantially in 2025. - EmDash runs each plugin inside an isolated Dynamic Worker. - Plugins access platform functionality through capability-based bindings rather than direct access to underlying resources. - A plugin must declare its required permissions in its manifest, allowing administrators to evaluate permissions before installation. - The example notification plugin: - Reacts to content-save events - Checks whether a post has been published - Sends an email to editors - Logs the notification - Plugins have no general external network access. If network access is necessary, the plugin can request permission for specific hostnames. - Administrators or platforms could enforce installation policies based on requested permissions instead of relying solely on approved-plugin allowlists. ## Security, Marketplaces, and Licensing - WordPress.org manually reviews plugins because the platform cannot otherwise guarantee their safety. - The review queue reportedly exceeds 800 plugins and can take at least two weeks. - Marketplace reputation, ratings, and reviews therefore become essential substitutes for technical trust. - Because WordPress plugins run inside WordPress and are tightly coupled to its code, developers may also face GPL licensing constraints. - The article argues that plugin security creates marketplace lock-in: - Customers rely on marketplaces to assess plugin trustworthiness. - Developers may need to distribute code under restrictive licensing terms to participate. - Hosting platforms inherit the risk of running third-party plugins. - EmDash’s sandboxing and permission model is positioned as a way to reduce reliance on centralized marketplace approval, though the provided article excerpt ends before explaining the promised “two important properties” in full. EmDash’s practical recommendation is to use capability-limited, isolated plugins as the foundation for a more secure and flexible WordPress-like ecosystem. Its early beta is intended for developers who want to evaluate that model on Cloudflare or Node.js.

wordpressdatabase-designopen-sourcetypescript+4

cloudflareFeb 27, 2026

Toxic combinations: when small signals add up to a security incident (opens in new tab)

Small security signals can become dangerous when combined: automated bots probing sensitive paths, unusual request behavior, and weak authentication or configuration. Cloudflare argues that analyzing these signals together—rather than judging each request independently—can reveal likely attack campaigns before compromise. Although toxic combinations are uncommon outside WordPress, the affected hosts may be highly exposed. ## What “Toxic Combinations” Mean - A toxic combination occurs when attackers compound several minor weaknesses into a viable breach. - Relevant signals include: - Bot activity and automated scanning - Sensitive paths such as `/admin`, `/debug`, `/metrics`, search, and payment endpoints - Anomalies such as unexpected HTTP status codes, geographic jumps, identity mismatches, high identifier churn, distributed rate-limit evasion, and traffic spikes - Missing session cookies or authorization headers and predictable identifiers - Traditional WAF, bot, and API defenses often assess the risk of individual requests. - Cloudflare’s approach examines the broader context across multiple requests, hosts, and paths. ## Measuring Exposure - Cloudflare analyzed a 24-hour sample of application-security data. - About 11% of analyzed hosts appeared susceptible to toxic combinations, largely because of vulnerable WordPress sites. - Excluding WordPress, only about 0.25% of hosts showed signs of exploitable combinations. - The analysis separated attacks into three stages: - **Hosts probed:** systems receiving requests for sensitive paths such as `/wp-admin` - **Hosts matching a toxic combination:** systems meeting the full detection criteria - **Reachable hosts:** systems that successfully responded to an exploit attempt - A `200 OK` response alone is not proof of exposure. Cloudflare recommends validating results against authentication requirements, redirects, and origin configurations to eliminate false positives. ## Probing Administrative Endpoints - Automated scanners targeted common administrative interfaces, including: - WordPress `/wp-admin` pages - Database management tools - Server dashboards - Cloudflare’s Log Explorer query groups successful requests by host, filters for likely bot traffic using a low bot score, and searches for configurable path patterns. - The query also excludes hosts represented only by raw IP addresses unless that filter is removed. ## Why Public Admin Panels Are Dangerous - Exposed administrative panels enable brute-force login attempts. - A successful compromise can allow attackers to: - Identify software and versions such as WordPress or Tomcat - Search for relevant CVEs and launch targeted exploits - Add the compromised host to a botnet that scans other websites - A sensitive endpoint returning successfully should therefore be tested for actual reachability and authentication weakness, not treated as conclusive evidence on its own. ## Practical Recommendation Monitor combinations of bot activity, sensitive-path access, anomalous behavior, and missing authentication signals. Investigate confirmed reachable endpoints, restrict or protect administrative interfaces, remove debug exposure, and validate detection queries against real application behavior to distinguish exploitable systems from false positives.

wordpresscloudflarevulnerability-managementapplication-security+3