coreruleset: Improper Neutralization of Special Elements
CVE-2026-62971 is a high-severity improper neutralization of special elements vulnerability in coreruleset, with a CVSS 3.1 base score of 7.2 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. Affected coreruleset versions: < 3.3.10; < 4.25.1; < 4.28.0. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.43% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Check which version of coreruleset you run against the affected versions below, and install the vendor's latest release.
- Read the advisory on github.com for workarounds and exact fixed builds.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Coreruleset | coreruleset | < 3.3.10; < 4.25.1; < 4.28.0 | Not stated |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- ChangedThe attack can reach beyond the vulnerable component into other systems.
- Confidentiality
- LowSome restricted data can be read.
- Integrity
- LowLimited modification of data is possible.
- Availability
- NoneAvailability is not affected.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N. Scored by CNA (github.com).
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Improper Neutralization of Special Elements
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.
How developers prevent this class of flaw
- Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their product. One defense is to create an allowlist (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the allowlist. Properly encode your output, and quote any elements that have special meaning to the component with which you are communicating.
- Use and specify an appropriate output encoding to ensure that the special elements are well-defined. A normal byte sequence in one encoding could be a special element in another.
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
More Improper Neutralization of Special Elements vulnerabilities (CWE-138)
Timeline
- CVE record published.
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other references
Other vulnerabilities in coreruleset
- 8.8 High severity
- 7.5 High severity
Recent Improper Neutralization of Special Elements vulnerabilities
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 9.8 Critical severity
- 7.2 High severity
Spotted an error? Tell us.