DEBIAN-CVE-2026-62971: XSS
The OWASP core rule set (CRS) is a set of generic attack detection rules for use with compatible web application firewalls. Prior to versions 3.3.10, 4.25.1, and 4.28.0, CRS rules in the 921 (protocol-attack), 930 (LFI), 931 (RFI), 932 (RCE), 933 (PHP), 934 (generic), 941 (XSS), 942 (SQLi), and 943 (session-fixation) families inspect XML request bodies via the XPath expression XML:/. That expression matches only element text nodes — it does not match XML attribute values. As a result, an attacker who places an attack payload inside an XML attribute (e.g. <a href="javascript:alert(1)=window.name"></a> or <a value="' OR 1=1 --"></a>) bypasses CRS detection entirely. This is verified empirically against a local CRS test instance and against the public CRS sandbox. The bypass affects approximately 159 rules across 9 rule files and applies at every paranoia level (PL1 through PL4), since the variable list is more or less shared across PLs. The 944 (Java) family is the only one that correctly includes XML://@ in addition to XML:/ and is therefore unaffected. This issue has been patched in versions 3.3.10, 4.25.1, and 4.28.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OWASP Core Rule Set (CRS)to a version that resolves this vulnerability.Fixed in 3.3.10 - Upgrade
Upgrade
OWASP Core Rule Set (CRS)to a version that resolves this vulnerability.Fixed in 4.25.1 - Upgrade
Upgrade
OWASP Core Rule Set (CRS)to a version that resolves this vulnerability.Fixed in 4.28.0
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
Deployments using affected CRS versions and relying on rule families 921, 930 through 934, or 941 through 943 to inspect XML request bodies are exposed. The bypass applies at all paranoia levels, PL1 through PL4.
What does an attacker need to do to evade detection?
An attacker must send an XML request body with the attack payload placed in an XML attribute value rather than element text. The affected XPath expression XML:/* does not inspect XML attributes, allowing payloads such as XSS or SQL injection strings to bypass the affected rules.
Are any CRS rule families unaffected?
The 944 Java rule family is unaffected because it includes XML://@* as well as XML:/*, so it inspects XML attribute values.
What versions contain the fix?
The issue is patched in CRS versions 3.3.10, 4.25.1, and 4.28.0. Versions prior to those releases are affected.