What changed in the WordPress ruleset metadata
Cloudflare now maps the WordPress login-screen XSS protection to CVE-2026-64638 in the Managed Ruleset and Free Ruleset. The rule description has been refined, but the detection behaviour and actions stay the same.
That matters because the rule still covers the same traffic patterns. The metadata update gives the finding a clearer vulnerability name, which helps when you are triaging events, comparing logs, or explaining why a request was blocked without having to decode a generic XSS label.
CVE-2026-64638 now maps to the login-screen XSS rule
CVE-2026-64638 is a pre-authentication reflected cross-site scripting issue on the WordPress login screen. Exploitation needs social engineering and explicit user interaction from the target user, which keeps it in the annoying-but-not-magic category.
Cloudflare’s metadata now ties that CVE to the WordPress XSS detection entry, so the alerting and rule naming line up better with the vulnerability being tracked. If you are filtering on rule names or CVEs, that is a cleaner way to track exposure.
Detection and actions stay as they were
The important part is the lack of behavioural change. The rule still detects the same thing and still takes the same action it took before.
That means no new block pattern, no new bypass, and no surprise change in how the Cloudflare WAF WordPress XSS detection behaves. If you already had monitoring or exceptions built around the old rule, those controls should still behave the same way after the metadata refresh.
Why Cloudflare disabled the obfuscation rule
Cloudflare also disabled the Managed Ruleset entry for Command Injection – Obfuscation. The reason given is plain enough: the detection logic has been deprecated.
That usually means the rule is tied to older logic that no longer earns its keep. Leaving dead logic in a WAF is a good way to keep a false sense of coverage while pretending the box is still doing something useful.
Deprecated logic in the Managed Ruleset
A disabled rule in a Managed Ruleset is not a small cosmetic change. It means the previous action of Block has been replaced with Disabled, so the rule no longer contributes blocking coverage.
If you were relying on that command injection obfuscation entry for a specific pattern, that coverage has gone. The change tells you Cloudflare no longer wants that detection path treated as current logic. Treat it as retired, not hidden.
What the disabled command injection entry means for coverage
The practical effect is narrow but real. A disabled rule will not fire, will not block, and will not produce the same protection signal you would expect from an active Managed Ruleset entry.
For WordPress operators, the bigger point is that Cloudflare is cleaning up rule metadata and retiring deprecated command injection logic at the same time as it clarifies the WordPress XSS mapping. The WAF is not becoming stricter here. It is becoming tidier. That is useful, but it does not make anyone’s login screen less awkward.
