From 05642aa7f5c4d84fc2c5de07545c260848a1152a Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Tue, 30 Jun 2026 11:33:45 +0200 Subject: [PATCH 1/8] draft: add v4.25.1 LTS release blog post Co-Authored-By: Claude Sonnet 4.6 --- ...6-06-30-crs-version-4-25-1-lts-released.md | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 content/blog/2026-06-30-crs-version-4-25-1-lts-released.md diff --git a/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md b/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md new file mode 100644 index 0000000..e366282 --- /dev/null +++ b/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md @@ -0,0 +1,120 @@ +--- +title: 'CRS version 4.25.1 LTS released' +date: '2026-06-30' +author: fzipi +categories: + - Blog +tags: + - CRS-News + - Release +draft: true +--- + +The OWASP CRS team is pleased to announce the release of **CRS v4.25.1**, the first patch release on our LTS-4.25 branch. This release fixes two high-severity security vulnerabilities alongside a set of false-positive reductions and regex hardening backports. All users on the CRS 4.25.x LTS line are strongly encouraged to update. + +For downloads and installation instructions, please refer to the [Installation](https://coreruleset.org/docs/deployment/install/) page. + +## Security fixes + +### XML attribute value bypass (GHSA-6jp8-c2w2-x7wr) + +**Severity:** HIGH — CVSS 3.1 score 7.2 (`AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N`) +**CWE:** CWE-138 — Improper Neutralization of Special Elements + +#### Impact + +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 using the XPath expression `XML:/*`. That expression matches element text nodes only — it does **not** match XML attribute values. An attacker who places an attack payload inside an XML attribute (e.g. `` or ``) bypasses CRS detection entirely. + +The bypass affects approximately 159 rules across nine rule files and applies at **every paranoia level (PL1 through PL4)**. The 944 (Java) family already correctly includes `XML://@*` and is therefore unaffected. + +**Who is impacted:** Deployments that protect applications which parse XML request bodies (SOAP, REST/XML, ATOM, XML-RPC, XML config endpoints, etc.) where ModSecurity's XML body processing is enabled. Deployments that do not accept XML bodies, or that block XML content types upstream, are not impacted. + +#### Workaround for users unable to update immediately + +Until you can deploy v4.25.1, you can mitigate by adding the following directives to your local configuration (e.g. a file loaded after CRS): + +```apache +SecRuleUpdateTargetByTag "attack-protocol" "XML://@*" +SecRuleUpdateTargetByTag "attack-lfi" "XML://@*" +SecRuleUpdateTargetByTag "attack-rfi" "XML://@*" +SecRuleUpdateTargetByTag "attack-rce" "XML://@*" +SecRuleUpdateTargetByTag "attack-php" "XML://@*" +SecRuleUpdateTargetByTag "attack-generic" "XML://@*" +SecRuleUpdateTargetByTag "attack-xss" "XML://@*" +SecRuleUpdateTargetByTag "attack-sqli" "XML://@*" +SecRuleUpdateTargetByTag "attack-fixation" "XML://@*" +``` + +This change is purely additive — it inspects an additional XPath axis without altering existing matches or transformations. + +#### Full advisory + +The full advisory will be published at [GHSA-6jp8-c2w2-x7wr](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-6jp8-c2w2-x7wr) once the associated CVE has been assigned and published. We will update this post with the CVE number at that time. + +Credit goes to [@HackingRepo](https://github.com/HackingRepo) for reporting this issue and to [@theseion](https://github.com/theseion) for the fix. + +### Unix RCE ReDoS in shared regex-assembly include (GHSA-f5qm-3h4p-8qhg) + +**Severity:** HIGH — CVSS score pending +**CWE:** CWE-1333 — Inefficient Regular Expression Complexity + +#### Impact + +A regular-expression denial of service (ReDoS) affects the shared include file `regex-assembly/include/unix-shell-evasion-prefix.ra`, which is used to build **12 Unix RCE detection rules**: 932220, 932230, 932231, 932232, 932235, 932236, 932238, 932239, 932250, 932260, 932340, and 932350. + +A single unauthenticated crafted request drives PCRE2 past its backtracking limit on the generated pattern. When PCRE2 exceeds that limit, the `@rx` operator returns an error rather than a match result, which has two consequences: + +- **Detection bypass** — the affected rule fails to evaluate for that request, so the RCE payload is not inspected. +- **CPU denial of service** — the engine burns CPU exploring the ambiguous pattern on every such request. + +**Root cause:** The commands-prefix group in the shared include has an ambiguous whitespace-handling alternation inside a `*` quantifier. A whitespace run between prefix tokens can be consumed by more than one quantifier (the trailing `\s*` of one iteration and the leading `\s*` of the next), so the number of parse paths grows combinatorially with the length of the run. This has been confirmed reproducible with `pcre2test` 10.47. + +**Who is affected:** Deployments running CRS on **ModSecurity v2 or v3** (both link against PCRE2). **Coraza (RE2) is not affected** — RE2 does not backtrack. + +#### Workaround for users unable to update immediately + +There is no workaround that fully preserves detection without applying the patch: + +- **Run CRS on a RE2-based engine (Coraza).** RE2 is not affected. +- **Constrain request size.** Tighter `SecRequestBodyLimit` and argument-length limits reduce exploitability but do not eliminate it. +- Lowering `SecPcreMatchLimit` / `SecPcreMatchLimitRecursion` makes the engine error sooner (less CPU per request) but does **not** remove the detection bypass — the rule still fails to evaluate when the limit is hit. +- Disabling the affected rules removes the DoS exposure but also removes the RCE detection they provide, and is not recommended. + +#### Full advisory + +The full advisory will be published at [GHSA-f5qm-3h4p-8qhg](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-f5qm-3h4p-8qhg) once the associated CVE has been assigned and published. We will update this post with the CVE number at that time. + +## Regex hardening: exponential backtracking removed + +Three rules carrying structurally ambiguous alternations that could lead to catastrophic backtracking on non-PCRE2 engines have been corrected. PCRE2 users (ModSecurity) were already protected by auto-possessification and required-literal optimizations, but engines using Oniguruma, Python `re`, or other backtracking engines were exposed. The fixes are purely additive in detection terms — all existing positive tests continue to pass. + +- **Rules 933160 and 933161** — PHP function-call detection: the optional whitespace/comment suffix between the function name and the opening `(` now uses unrolled comment forms and newline-anchored line-comment branches, removing the overlap between the whitespace and comment branches under the `*` quantifier. ([#4666](https://github.com/coreruleset/coreruleset/pull/4666)) +- **Rule 933180** — PHP variable function calls: the "noise" group between the variable name and call `(...)` now uses bounded bracket/brace forms and the unrolled block-comment pattern instead of free `.+`/`.*`, eliminating the shared-character ambiguity under the outer `*` quantifier. ([#4669](https://github.com/coreruleset/coreruleset/pull/4669)) +- **Rule 941140** — CSS `url(javascript:...)` XSS detection: the declaration-list loop value changed from free `.+` to `[^;]+`, bounding it at the declaration separator and removing the ambiguity with the adjacent key pattern. The rule has been migrated from an inline pattern to `regex-assembly/941140.ra`. ([#4670](https://github.com/coreruleset/coreruleset/pull/4670)) + +## False-positive reductions + +- **Rules 920240 and 920400** — These rules validate URL-encoded request bodies and enforce file-size limits. They previously relied solely on the `Content-Type` header to determine if a request body is URL-encoded, which could fail for applications that send URL-encoded data with non-standard content types such as `text/plain`. They now use the `REQBODY_PROCESSOR` variable, which is set by the engine based on the actual body processor in use, making them more robust in non-standard configurations. ([#4639](https://github.com/coreruleset/coreruleset/pull/4639)) +- **Rule 942200** — SQL injection detection: a regression introduced by an earlier false-positive fix caused user-agent strings containing a comma but no surrounding whitespace to be blocked incorrectly. The rule's comment-handling logic has been refined to cover these cases. ([#4608](https://github.com/coreruleset/coreruleset/pull/4608)) +- **Parameter name `.history`** — Matching against the string `.history` was producing substring false positives, e.g. triggering on the parameter name `history.history`. A word boundary has been added to restrict the match to actual `.history` file access attempts. ([#4614](https://github.com/coreruleset/coreruleset/pull/4614)) +- **Unix RCE (PL1) — `pg` command** — The `pg` command has been removed from the PL1 Unix command list. It is not installed by default on most Linux distributions and was causing false positives in application traffic. ([#4613](https://github.com/coreruleset/coreruleset/pull/4613)) +- **Internal bug fix 4RI-250413** — An additional bug fix addresses an internally tracked issue. ([#4672](https://github.com/coreruleset/coreruleset/pull/4672)) + +## Protocol enforcement + +- **Rule 920100** — Request line validation: support for HTTP/0.9 bare `GET` requests (without a protocol suffix) has been removed. HTTP/0.9 is obsolete per RFC 9110, and the earlier rule 920430 already excluded it from the allowed HTTP versions list by default. The HTTP/0.9 branch was the only alternative in rule 920100 that did not require a protocol version, creating an inconsistency that has now been resolved. ([#4621](https://github.com/coreruleset/coreruleset/pull/4621)) + +## Setup improvement + +- **`crs-setup.conf.example`** — `SecDefaultAction` directives for phases 3, 4, and 5 are now defined in anomaly scoring mode. Without explicit default actions for these phases, some engines (notably Coraza) may fall back to engine-level defaults, leading to inconsistent logging and auditing behavior across backends. The new directives make CRS behavior consistent regardless of the WAF engine in use. ([#4675](https://github.com/coreruleset/coreruleset/pull/4675)) + +## Upgrading + +The release is available on [GitHub](https://github.com/coreruleset/coreruleset/releases/tag/v4.25.1). Given the two high-severity security fixes included in this release, all deployments on the CRS 4.25.x LTS line should update promptly. Users on the CRS 4.x main branch will receive the same security fixes in a forthcoming release. + +**nginx + libmodsecurity3 users:** update libmodsecurity3 to **v3.0.16** alongside this CRS release. v3.0.16 is required for the XML attribute bypass fix (GHSA-6jp8-c2w2-x7wr) to take full effect on that stack. + +If you have questions or concerns, please reach out via the [CRS GitHub repository](https://github.com/coreruleset/coreruleset), in our Slack channel (#coreruleset on [owasp.slack.com](https://owasp.slack.com/)), or on our [mailing list](https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project). + +Sincerely, +Felipe Zipitria on behalf of the CRS development team From e94b2101b618f6851bcd370c1f737efb148d06e4 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Wed, 1 Jul 2026 19:48:05 +0200 Subject: [PATCH 2/8] draft: update v4.25.1 blog with cross-branch release notes Co-Authored-By: Claude Sonnet 4.6 --- ...6-06-30-crs-version-4-25-1-lts-released.md | 21 +++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md b/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md index e366282..ac0d11b 100644 --- a/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md +++ b/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md @@ -47,6 +47,23 @@ SecRuleUpdateTargetByTag "attack-fixation" "XML://@*" This change is purely additive — it inspects an additional XPath axis without altering existing matches or transformations. +#### Opt-in gate: `tx.crs_xml_attr_inspect` + +To allow operators to stage the rollout, XML attribute inspection ships behind a runtime gate on the LTS branch. It is **enabled by default** — no action is needed to get the protection. Operators who need to disable it temporarily (e.g. to work around false positives while tuning) can add the following to their local configuration: + +```apache +SecAction "id:900130,phase:1,nolog,pass,\ + setvar:tx.crs_xml_attr_inspect=0" +``` + +Setting `tx.crs_xml_attr_inspect=0` strips the `XML://@*` target from all affected rules for the duration of that transaction. + +#### Known limitation on ModSecurity v2 (Apache) + +On **ModSecurity v2/Apache**, the opt-out mechanism (`tx.crs_xml_attr_inspect=0`) cannot fully suppress XML attribute inspection due to an upstream engine bug: `ctl:ruleRemoveTargetByTag` does not correctly remove `XML://@*` selectors at runtime on that engine. Detection of XML-attribute payloads therefore remains active even with the gate disabled. + +This has been reported upstream as [ModSecurity#3591](https://github.com/owasp-modsecurity/ModSecurity/issues/3591). **libmodsecurity v3 (nginx) is unaffected** — the opt-out works correctly there. ModSecurity v2 users who need to suppress XML attribute inspection entirely should use the `SecRuleUpdateTargetByTag` workaround directives listed above (which operate at config-load time, not per-transaction). + #### Full advisory The full advisory will be published at [GHSA-6jp8-c2w2-x7wr](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-6jp8-c2w2-x7wr) once the associated CVE has been assigned and published. We will update this post with the CVE number at that time. @@ -98,7 +115,7 @@ Three rules carrying structurally ambiguous alternations that could lead to cata - **Rule 942200** — SQL injection detection: a regression introduced by an earlier false-positive fix caused user-agent strings containing a comma but no surrounding whitespace to be blocked incorrectly. The rule's comment-handling logic has been refined to cover these cases. ([#4608](https://github.com/coreruleset/coreruleset/pull/4608)) - **Parameter name `.history`** — Matching against the string `.history` was producing substring false positives, e.g. triggering on the parameter name `history.history`. A word boundary has been added to restrict the match to actual `.history` file access attempts. ([#4614](https://github.com/coreruleset/coreruleset/pull/4614)) - **Unix RCE (PL1) — `pg` command** — The `pg` command has been removed from the PL1 Unix command list. It is not installed by default on most Linux distributions and was causing false positives in application traffic. ([#4613](https://github.com/coreruleset/coreruleset/pull/4613)) -- **Internal bug fix 4RI-250413** — An additional bug fix addresses an internally tracked issue. ([#4672](https://github.com/coreruleset/coreruleset/pull/4672)) +- **Rules 932171 and 942361** — A JSON-body SQLi detection fix (a `(?:json\.)?` prefix on the `ARGS_NAMES` check) was silently lost during conflict resolution when backporting to the LTS branch, because both rules carry hand-written regexes with no `.ra` source file and were therefore invisible to the `crs-toolchain` regeneration pass used to resolve conflicts. The fix was caught by re-testing against a live nginx/libmodsecurity3 engine and has been restored. ([#4672](https://github.com/coreruleset/coreruleset/pull/4672)) ## Protocol enforcement @@ -112,7 +129,7 @@ Three rules carrying structurally ambiguous alternations that could lead to cata The release is available on [GitHub](https://github.com/coreruleset/coreruleset/releases/tag/v4.25.1). Given the two high-severity security fixes included in this release, all deployments on the CRS 4.25.x LTS line should update promptly. Users on the CRS 4.x main branch will receive the same security fixes in a forthcoming release. -**nginx + libmodsecurity3 users:** update libmodsecurity3 to **v3.0.16** alongside this CRS release. v3.0.16 is required for the XML attribute bypass fix (GHSA-6jp8-c2w2-x7wr) to take full effect on that stack. +**nginx + libmodsecurity3 users:** update libmodsecurity3 to **v3.0.16** alongside this CRS release. The opt-in gate introduced by GHSA-6jp8-c2w2-x7wr uses `ctl:ruleRemoveTargetByTag` with an `XML://@*` target; versions of libmodsecurity3 prior to 3.0.16 reject the `@` character in that position at parse time, preventing the configuration from loading at all ([ModSecurity#3589](https://github.com/owasp-modsecurity/ModSecurity/pull/3589)). If you have questions or concerns, please reach out via the [CRS GitHub repository](https://github.com/coreruleset/coreruleset), in our Slack channel (#coreruleset on [owasp.slack.com](https://owasp.slack.com/)), or on our [mailing list](https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project). From 58cf795ecac2763a4eb7af457f95c7325c670b7b Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Wed, 1 Jul 2026 23:25:12 +0200 Subject: [PATCH 3/8] draft: expand release post to cover v4.28.0, v4.25.1 LTS, and v3.3.10 Co-Authored-By: Claude Sonnet 4.6 --- ...6-06-30-crs-version-4-25-1-lts-released.md | 137 -------------- ...sions-4-28-0-4-25-1-lts-3-3-10-released.md | 175 ++++++++++++++++++ 2 files changed, 175 insertions(+), 137 deletions(-) delete mode 100644 content/blog/2026-06-30-crs-version-4-25-1-lts-released.md create mode 100644 content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md diff --git a/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md b/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md deleted file mode 100644 index ac0d11b..0000000 --- a/content/blog/2026-06-30-crs-version-4-25-1-lts-released.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: 'CRS version 4.25.1 LTS released' -date: '2026-06-30' -author: fzipi -categories: - - Blog -tags: - - CRS-News - - Release -draft: true ---- - -The OWASP CRS team is pleased to announce the release of **CRS v4.25.1**, the first patch release on our LTS-4.25 branch. This release fixes two high-severity security vulnerabilities alongside a set of false-positive reductions and regex hardening backports. All users on the CRS 4.25.x LTS line are strongly encouraged to update. - -For downloads and installation instructions, please refer to the [Installation](https://coreruleset.org/docs/deployment/install/) page. - -## Security fixes - -### XML attribute value bypass (GHSA-6jp8-c2w2-x7wr) - -**Severity:** HIGH — CVSS 3.1 score 7.2 (`AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N`) -**CWE:** CWE-138 — Improper Neutralization of Special Elements - -#### Impact - -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 using the XPath expression `XML:/*`. That expression matches element text nodes only — it does **not** match XML attribute values. An attacker who places an attack payload inside an XML attribute (e.g. `` or ``) bypasses CRS detection entirely. - -The bypass affects approximately 159 rules across nine rule files and applies at **every paranoia level (PL1 through PL4)**. The 944 (Java) family already correctly includes `XML://@*` and is therefore unaffected. - -**Who is impacted:** Deployments that protect applications which parse XML request bodies (SOAP, REST/XML, ATOM, XML-RPC, XML config endpoints, etc.) where ModSecurity's XML body processing is enabled. Deployments that do not accept XML bodies, or that block XML content types upstream, are not impacted. - -#### Workaround for users unable to update immediately - -Until you can deploy v4.25.1, you can mitigate by adding the following directives to your local configuration (e.g. a file loaded after CRS): - -```apache -SecRuleUpdateTargetByTag "attack-protocol" "XML://@*" -SecRuleUpdateTargetByTag "attack-lfi" "XML://@*" -SecRuleUpdateTargetByTag "attack-rfi" "XML://@*" -SecRuleUpdateTargetByTag "attack-rce" "XML://@*" -SecRuleUpdateTargetByTag "attack-php" "XML://@*" -SecRuleUpdateTargetByTag "attack-generic" "XML://@*" -SecRuleUpdateTargetByTag "attack-xss" "XML://@*" -SecRuleUpdateTargetByTag "attack-sqli" "XML://@*" -SecRuleUpdateTargetByTag "attack-fixation" "XML://@*" -``` - -This change is purely additive — it inspects an additional XPath axis without altering existing matches or transformations. - -#### Opt-in gate: `tx.crs_xml_attr_inspect` - -To allow operators to stage the rollout, XML attribute inspection ships behind a runtime gate on the LTS branch. It is **enabled by default** — no action is needed to get the protection. Operators who need to disable it temporarily (e.g. to work around false positives while tuning) can add the following to their local configuration: - -```apache -SecAction "id:900130,phase:1,nolog,pass,\ - setvar:tx.crs_xml_attr_inspect=0" -``` - -Setting `tx.crs_xml_attr_inspect=0` strips the `XML://@*` target from all affected rules for the duration of that transaction. - -#### Known limitation on ModSecurity v2 (Apache) - -On **ModSecurity v2/Apache**, the opt-out mechanism (`tx.crs_xml_attr_inspect=0`) cannot fully suppress XML attribute inspection due to an upstream engine bug: `ctl:ruleRemoveTargetByTag` does not correctly remove `XML://@*` selectors at runtime on that engine. Detection of XML-attribute payloads therefore remains active even with the gate disabled. - -This has been reported upstream as [ModSecurity#3591](https://github.com/owasp-modsecurity/ModSecurity/issues/3591). **libmodsecurity v3 (nginx) is unaffected** — the opt-out works correctly there. ModSecurity v2 users who need to suppress XML attribute inspection entirely should use the `SecRuleUpdateTargetByTag` workaround directives listed above (which operate at config-load time, not per-transaction). - -#### Full advisory - -The full advisory will be published at [GHSA-6jp8-c2w2-x7wr](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-6jp8-c2w2-x7wr) once the associated CVE has been assigned and published. We will update this post with the CVE number at that time. - -Credit goes to [@HackingRepo](https://github.com/HackingRepo) for reporting this issue and to [@theseion](https://github.com/theseion) for the fix. - -### Unix RCE ReDoS in shared regex-assembly include (GHSA-f5qm-3h4p-8qhg) - -**Severity:** HIGH — CVSS score pending -**CWE:** CWE-1333 — Inefficient Regular Expression Complexity - -#### Impact - -A regular-expression denial of service (ReDoS) affects the shared include file `regex-assembly/include/unix-shell-evasion-prefix.ra`, which is used to build **12 Unix RCE detection rules**: 932220, 932230, 932231, 932232, 932235, 932236, 932238, 932239, 932250, 932260, 932340, and 932350. - -A single unauthenticated crafted request drives PCRE2 past its backtracking limit on the generated pattern. When PCRE2 exceeds that limit, the `@rx` operator returns an error rather than a match result, which has two consequences: - -- **Detection bypass** — the affected rule fails to evaluate for that request, so the RCE payload is not inspected. -- **CPU denial of service** — the engine burns CPU exploring the ambiguous pattern on every such request. - -**Root cause:** The commands-prefix group in the shared include has an ambiguous whitespace-handling alternation inside a `*` quantifier. A whitespace run between prefix tokens can be consumed by more than one quantifier (the trailing `\s*` of one iteration and the leading `\s*` of the next), so the number of parse paths grows combinatorially with the length of the run. This has been confirmed reproducible with `pcre2test` 10.47. - -**Who is affected:** Deployments running CRS on **ModSecurity v2 or v3** (both link against PCRE2). **Coraza (RE2) is not affected** — RE2 does not backtrack. - -#### Workaround for users unable to update immediately - -There is no workaround that fully preserves detection without applying the patch: - -- **Run CRS on a RE2-based engine (Coraza).** RE2 is not affected. -- **Constrain request size.** Tighter `SecRequestBodyLimit` and argument-length limits reduce exploitability but do not eliminate it. -- Lowering `SecPcreMatchLimit` / `SecPcreMatchLimitRecursion` makes the engine error sooner (less CPU per request) but does **not** remove the detection bypass — the rule still fails to evaluate when the limit is hit. -- Disabling the affected rules removes the DoS exposure but also removes the RCE detection they provide, and is not recommended. - -#### Full advisory - -The full advisory will be published at [GHSA-f5qm-3h4p-8qhg](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-f5qm-3h4p-8qhg) once the associated CVE has been assigned and published. We will update this post with the CVE number at that time. - -## Regex hardening: exponential backtracking removed - -Three rules carrying structurally ambiguous alternations that could lead to catastrophic backtracking on non-PCRE2 engines have been corrected. PCRE2 users (ModSecurity) were already protected by auto-possessification and required-literal optimizations, but engines using Oniguruma, Python `re`, or other backtracking engines were exposed. The fixes are purely additive in detection terms — all existing positive tests continue to pass. - -- **Rules 933160 and 933161** — PHP function-call detection: the optional whitespace/comment suffix between the function name and the opening `(` now uses unrolled comment forms and newline-anchored line-comment branches, removing the overlap between the whitespace and comment branches under the `*` quantifier. ([#4666](https://github.com/coreruleset/coreruleset/pull/4666)) -- **Rule 933180** — PHP variable function calls: the "noise" group between the variable name and call `(...)` now uses bounded bracket/brace forms and the unrolled block-comment pattern instead of free `.+`/`.*`, eliminating the shared-character ambiguity under the outer `*` quantifier. ([#4669](https://github.com/coreruleset/coreruleset/pull/4669)) -- **Rule 941140** — CSS `url(javascript:...)` XSS detection: the declaration-list loop value changed from free `.+` to `[^;]+`, bounding it at the declaration separator and removing the ambiguity with the adjacent key pattern. The rule has been migrated from an inline pattern to `regex-assembly/941140.ra`. ([#4670](https://github.com/coreruleset/coreruleset/pull/4670)) - -## False-positive reductions - -- **Rules 920240 and 920400** — These rules validate URL-encoded request bodies and enforce file-size limits. They previously relied solely on the `Content-Type` header to determine if a request body is URL-encoded, which could fail for applications that send URL-encoded data with non-standard content types such as `text/plain`. They now use the `REQBODY_PROCESSOR` variable, which is set by the engine based on the actual body processor in use, making them more robust in non-standard configurations. ([#4639](https://github.com/coreruleset/coreruleset/pull/4639)) -- **Rule 942200** — SQL injection detection: a regression introduced by an earlier false-positive fix caused user-agent strings containing a comma but no surrounding whitespace to be blocked incorrectly. The rule's comment-handling logic has been refined to cover these cases. ([#4608](https://github.com/coreruleset/coreruleset/pull/4608)) -- **Parameter name `.history`** — Matching against the string `.history` was producing substring false positives, e.g. triggering on the parameter name `history.history`. A word boundary has been added to restrict the match to actual `.history` file access attempts. ([#4614](https://github.com/coreruleset/coreruleset/pull/4614)) -- **Unix RCE (PL1) — `pg` command** — The `pg` command has been removed from the PL1 Unix command list. It is not installed by default on most Linux distributions and was causing false positives in application traffic. ([#4613](https://github.com/coreruleset/coreruleset/pull/4613)) -- **Rules 932171 and 942361** — A JSON-body SQLi detection fix (a `(?:json\.)?` prefix on the `ARGS_NAMES` check) was silently lost during conflict resolution when backporting to the LTS branch, because both rules carry hand-written regexes with no `.ra` source file and were therefore invisible to the `crs-toolchain` regeneration pass used to resolve conflicts. The fix was caught by re-testing against a live nginx/libmodsecurity3 engine and has been restored. ([#4672](https://github.com/coreruleset/coreruleset/pull/4672)) - -## Protocol enforcement - -- **Rule 920100** — Request line validation: support for HTTP/0.9 bare `GET` requests (without a protocol suffix) has been removed. HTTP/0.9 is obsolete per RFC 9110, and the earlier rule 920430 already excluded it from the allowed HTTP versions list by default. The HTTP/0.9 branch was the only alternative in rule 920100 that did not require a protocol version, creating an inconsistency that has now been resolved. ([#4621](https://github.com/coreruleset/coreruleset/pull/4621)) - -## Setup improvement - -- **`crs-setup.conf.example`** — `SecDefaultAction` directives for phases 3, 4, and 5 are now defined in anomaly scoring mode. Without explicit default actions for these phases, some engines (notably Coraza) may fall back to engine-level defaults, leading to inconsistent logging and auditing behavior across backends. The new directives make CRS behavior consistent regardless of the WAF engine in use. ([#4675](https://github.com/coreruleset/coreruleset/pull/4675)) - -## Upgrading - -The release is available on [GitHub](https://github.com/coreruleset/coreruleset/releases/tag/v4.25.1). Given the two high-severity security fixes included in this release, all deployments on the CRS 4.25.x LTS line should update promptly. Users on the CRS 4.x main branch will receive the same security fixes in a forthcoming release. - -**nginx + libmodsecurity3 users:** update libmodsecurity3 to **v3.0.16** alongside this CRS release. The opt-in gate introduced by GHSA-6jp8-c2w2-x7wr uses `ctl:ruleRemoveTargetByTag` with an `XML://@*` target; versions of libmodsecurity3 prior to 3.0.16 reject the `@` character in that position at parse time, preventing the configuration from loading at all ([ModSecurity#3589](https://github.com/owasp-modsecurity/ModSecurity/pull/3589)). - -If you have questions or concerns, please reach out via the [CRS GitHub repository](https://github.com/coreruleset/coreruleset), in our Slack channel (#coreruleset on [owasp.slack.com](https://owasp.slack.com/)), or on our [mailing list](https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project). - -Sincerely, -Felipe Zipitria on behalf of the CRS development team diff --git a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md new file mode 100644 index 0000000..d3386b3 --- /dev/null +++ b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md @@ -0,0 +1,175 @@ +--- +title: 'CRS versions 4.28.0, 4.25.1 LTS, and 3.3.10 released' +date: '2026-07-01' +author: fzipi +categories: + - Blog +tags: + - CRS-News + - Release +draft: true +--- + +The OWASP CRS team is pleased to announce three coordinated releases today: **v4.28.0** (main branch), **v4.25.1** (v4 LTS), and **v3.3.10** (v3 LTS). All three fix the same two high-severity security vulnerabilities. Users on any supported branch are strongly encouraged to update. + +For downloads and installation instructions, please refer to the [Installation](https://coreruleset.org/docs/deployment/install/) page. + +## Security fixes + +Both vulnerabilities affect all three release lines. The security advisories will be published once the associated CVEs have been assigned; this post will be updated with CVE numbers at that time. + +### XML attribute value bypass (GHSA-6jp8-c2w2-x7wr) + +**Severity:** HIGH — CVSS 3.1 score 7.2 (`AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N`) +**CWE:** CWE-138 — Improper Neutralization of Special Elements + +#### Impact + +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 using the XPath expression `XML:/*`. That expression matches element text nodes only — it does **not** match XML attribute values. An attacker who places an attack payload inside an XML attribute (e.g. `` or ``) bypasses CRS detection entirely. + +The bypass affects approximately 159 rules across nine rule files and applies at **every paranoia level (PL1 through PL4)**. The 944 (Java) family already correctly includes `XML://@*` and is therefore unaffected. + +**Who is impacted:** Deployments that protect applications which parse XML request bodies (SOAP, REST/XML, ATOM, XML-RPC, XML config endpoints, etc.) where ModSecurity's XML body processing is enabled. Deployments that do not accept XML bodies, or that block XML content types upstream, are not impacted. + +#### Opt-in gate on LTS branches (v4.25.1 and v3.3.10) + +On the LTS branches the fix ships behind a runtime gate (`tx.crs_xml_attr_inspect`) so operators can stage the rollout. It is **enabled by default** — no action is needed to get the protection. Operators who need to temporarily disable it can add the following to their local configuration: + +```apache +SecAction "id:900130,phase:1,nolog,pass,\ + setvar:tx.crs_xml_attr_inspect=0" +``` + +**v4.28.0** ships the fix unconditionally with no gate. + +#### Known limitation on ModSecurity v2 (Apache) — LTS branches + +On **ModSecurity v2/Apache**, the opt-out (`tx.crs_xml_attr_inspect=0`) cannot fully suppress XML attribute inspection. The `ctl:ruleRemoveTargetByTag` directive does not correctly remove `XML://@*` selectors at runtime on that engine, even though the same mechanism works correctly for ordinary variables and works correctly on libmodsecurity v3. Detection of XML-attribute payloads therefore remains active even with the gate disabled. + +This has been reported upstream as [ModSecurity#3591](https://github.com/owasp-modsecurity/ModSecurity/issues/3591). ModSecurity v2 users who need to suppress XML attribute inspection entirely should use config-load-time directives instead: + +```apache +SecRuleUpdateTargetByTag "attack-protocol" "!XML://@*" +SecRuleUpdateTargetByTag "attack-lfi" "!XML://@*" +SecRuleUpdateTargetByTag "attack-rfi" "!XML://@*" +SecRuleUpdateTargetByTag "attack-rce" "!XML://@*" +SecRuleUpdateTargetByTag "attack-php" "!XML://@*" +SecRuleUpdateTargetByTag "attack-generic" "!XML://@*" +SecRuleUpdateTargetByTag "attack-xss" "!XML://@*" +SecRuleUpdateTargetByTag "attack-sqli" "!XML://@*" +SecRuleUpdateTargetByTag "attack-fixation" "!XML://@*" +``` + +#### Full advisory + +The full advisory will be published at [GHSA-6jp8-c2w2-x7wr](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-6jp8-c2w2-x7wr) once the associated CVE has been assigned and published. + +Credit goes to [@HackingRepo](https://github.com/HackingRepo) for reporting this issue and to [@theseion](https://github.com/theseion) for the fix. + +### Unix RCE ReDoS in shared regex-assembly include (GHSA-f5qm-3h4p-8qhg) + +**Severity:** HIGH — CVSS score pending +**CWE:** CWE-1333 — Inefficient Regular Expression Complexity + +#### Impact + +A regular-expression denial of service (ReDoS) affects the shared include `regex-assembly/include/unix-shell-evasion-prefix.ra`, used to build **12 Unix RCE detection rules**: 932220, 932230, 932231, 932232, 932235, 932236, 932238, 932239, 932250, 932260, 932340, and 932350. + +A single unauthenticated crafted request drives PCRE2 past its backtracking limit. When PCRE2 exceeds that limit, the `@rx` operator returns an error rather than a match result, which has two consequences: + +- **Detection bypass** — the affected rule fails to evaluate, so the RCE payload is not inspected. +- **CPU denial of service** — the engine burns CPU exploring the ambiguous pattern on every such request. + +**Root cause:** The commands-prefix group contained an ambiguous whitespace-handling alternation inside a `*` quantifier. A whitespace run between prefix tokens could be consumed by more than one quantifier, so the number of parse paths grew combinatorially with the length of the run. This has been confirmed reproducible with `pcre2test` 10.47. + +**Who is affected:** Deployments running CRS on **ModSecurity v2 or v3** (both link against PCRE2). **Coraza (RE2) is not affected** — RE2 does not backtrack. + +#### Workaround for users unable to update immediately + +There is no workaround that fully preserves detection without applying the patch: + +- **Run CRS on a RE2-based engine (Coraza).** RE2 is not affected. +- **Constrain request size.** Tighter `SecRequestBodyLimit` and argument-length limits reduce exploitability but do not eliminate it. +- Lowering `SecPcreMatchLimit` / `SecPcreMatchLimitRecursion` makes the engine error sooner (less CPU per request) but does **not** remove the detection bypass. +- Disabling the affected rules removes the DoS exposure but also removes the RCE detection they provide, and is not recommended. + +#### Full advisory + +The full advisory will be published at [GHSA-f5qm-3h4p-8qhg](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-f5qm-3h4p-8qhg) once the associated CVE has been assigned and published. + +## Changes in v4.28.0 + +### New features and detections + +- **UTF-8 validation enabled by default** — Rule 920250 (`@validateUtf8Encoding` on `REQUEST_FILENAME|ARGS|ARGS_NAMES`) is now active at PL1 without additional configuration. Sites that genuinely use a non-UTF-8 parameter encoding can opt out via the `900950` `SecAction` in `crs-setup.conf.example`. ([#4647](https://github.com/coreruleset/coreruleset/pull/4647)) + +- **Shell quote evasion detection** — New detection for shell quote evasion techniques used to bypass command-detection rules. ([#3813](https://github.com/coreruleset/coreruleset/pull/3813)) + +- **ORM lookup operator injection** — Two new rules detect Django-style ORM lookup-operator injection in request parameter names, a class of attack that can lead to data leakage or authentication-filter bypass when unsanitized parameter keys are passed directly into a query builder: + - **Rule 934220** (PL2): nested relationship traversal — two or more `__` separators — followed by an operator suffix (e.g. `created_by__departments__user__username__startswith`). Multi-hop traversal exposed to clients is rarely legitimate. + - **Rule 934210** (PL3): any operator suffix on a parameter name (e.g. `username__startswith`). Sits at PL3 as single-field operator syntax is documented and legitimate in some APIs. + + Both rules inspect `ARGS_NAMES` and `REQUEST_BODY`. ([#4659](https://github.com/coreruleset/coreruleset/pull/4659)) + +- **Uninitialized variable spacer in RCE evasion** — The unix-shell evasion prefix now recognises an uninitialised shell variable used as a spacer (e.g. `$a`), which expands to the empty string at runtime. Payloads such as `;$a cat test.txt` previously bypassed PL1–PL3 detection; they now trigger at PL2 (rule 932236) or PL1 (rule 932235). This change regenerates all 12 rules sharing the `unix-shell-evasion-prefix.ra` include. ([#4652](https://github.com/coreruleset/coreruleset/pull/4652)) + +### Other changes + +- **NPM subdirectories in restricted files** — `restricted-files.data` now covers common `node_modules/` subdirectories (`.bin`, `.cache`, `package.json`, `package-lock.json`) in a way that avoids the false positives the bare `node_modules/` entry caused on static sites. ([#4653](https://github.com/coreruleset/coreruleset/pull/4653)) + +- **Regex hardening** — In addition to the ReDoS security fix above, four further rules had ambiguous patterns corrected: + - Rules 933160/933161 — PHP function-call comment suffix de-ambiguated. ([#4666](https://github.com/coreruleset/coreruleset/pull/4666)) + - Rule 933180 — PHP variable-function noise suffix de-ambiguated. ([#4669](https://github.com/coreruleset/coreruleset/pull/4669)) + - Rule 941140 — CSS `url(javascript:...)` XSS detection, declaration-list loop bounded. ([#4670](https://github.com/coreruleset/coreruleset/pull/4670)) + - Rule 942522 — Removed a redundant `^.*?` prefix that negated the benefit of anchoring the regex to the start of the string. ([#4676](https://github.com/coreruleset/coreruleset/pull/4676)) + +- **Rules 932171 and 942361** — Restored a `(?:json\.)?` prefix fix on the `ARGS_NAMES` check that had been silently lost during conflict resolution. These two rules carry hand-written regexes with no `.ra` source file and were therefore missed when regenerating other rules from source. ([#4672](https://github.com/coreruleset/coreruleset/pull/4672)) + +- **Rule 942390** — Migrated from an inline regex to `regex-assembly/942390.ra`. ([#4011](https://github.com/coreruleset/coreruleset/pull/4011)) + +- **`crs-setup.conf.example`** — `SecDefaultAction` directives for phases 3, 4, and 5 are now defined in anomaly scoring mode, ensuring consistent logging and auditing behavior across WAF engines. ([#4675](https://github.com/coreruleset/coreruleset/pull/4675)) + +- **RESPONSE_BODY false positives** — Several overly broad phrases in response-body error-detection rules have been replaced with more specific alternatives. ([#4684](https://github.com/coreruleset/coreruleset/pull/4684)) + +## Changes in v4.25.1 LTS + +This release backports security and false-positive fixes onto the v4.25.x LTS branch. The two security fixes above apply in full; the `tx.crs_xml_attr_inspect` opt-in gate and the libmodsecurity v3.0.16 requirement described in the security section are specific to this branch. + +### Regex hardening backports + +- Rules 933160/933161 — PHP function-call comment suffix. ([#4666](https://github.com/coreruleset/coreruleset/pull/4666)) +- Rule 933180 — PHP variable-function noise suffix. ([#4669](https://github.com/coreruleset/coreruleset/pull/4669)) +- Rule 941140 — CSS `url(javascript:...)` XSS detection. ([#4670](https://github.com/coreruleset/coreruleset/pull/4670)) + +### False-positive reductions + +- **Rules 920240 and 920400** — Now use `REQBODY_PROCESSOR` instead of the `Content-Type` header to determine whether a request body is URL-encoded, making them more robust for applications that send URL-encoded data with non-standard content types. ([#4639](https://github.com/coreruleset/coreruleset/pull/4639)) +- **Rule 942200** — Refined comment-handling logic to fix a regression that blocked user-agent strings containing a comma but no surrounding whitespace. ([#4608](https://github.com/coreruleset/coreruleset/pull/4608)) +- **Parameter name `.history`** — Added a word boundary to prevent substring false positives (e.g. `history.history`). ([#4614](https://github.com/coreruleset/coreruleset/pull/4614)) +- **Unix RCE (PL1) — `pg` command** — Removed from the PL1 Unix command list; not installed by default on most Linux distributions. ([#4613](https://github.com/coreruleset/coreruleset/pull/4613)) +- **Rules 932171 and 942361** — Restored the `(?:json\.)?` ARGS_NAMES-prefix fix that was silently dropped during conflict resolution, as these rules have hand-written regexes with no `.ra` source file. ([#4672](https://github.com/coreruleset/coreruleset/pull/4672)) + +### Protocol enforcement + +- **Rule 920100** — Removed support for bare HTTP/0.9 `GET` requests (obsolete per RFC 9110), resolving an inconsistency with rule 920430 which already excluded HTTP/0.9 from the allowed HTTP versions list. ([#4621](https://github.com/coreruleset/coreruleset/pull/4621)) + +### Setup improvement + +- **`crs-setup.conf.example`** — `SecDefaultAction` for phases 3, 4, and 5 in anomaly scoring mode. ([#4675](https://github.com/coreruleset/coreruleset/pull/4675)) + +## Changes in v3.3.10 + +This is a **security-only** release on the v3.3 LTS line. It contains both security fixes described above and no other functional changes. + +The `tx.crs_xml_attr_inspect` opt-in gate (rules 901180 and 901181 in `REQUEST-901-INITIALIZATION.conf`) is present on this branch, with the same default-on behavior and the same ModSecurity v2 opt-out limitation described above. + +## Upgrading + +All three releases are available on the [CRS GitHub releases page](https://github.com/coreruleset/coreruleset/releases). + +**nginx + libmodsecurity3 users on v4.25.1 or v3.3.10:** update libmodsecurity3 to **v3.0.16** alongside this CRS release. The opt-in gate on these branches uses `ctl:ruleRemoveTargetByTag` with an `XML://@*` target; versions of libmodsecurity3 prior to 3.0.16 reject the `@` character in that position at parse time, preventing the configuration from loading at all ([ModSecurity#3589](https://github.com/owasp-modsecurity/ModSecurity/pull/3589)). v4.28.0 does not use this syntax and has no additional engine version requirement. + +If you have questions or concerns, please reach out via the [CRS GitHub repository](https://github.com/coreruleset/coreruleset), in our Slack channel (#coreruleset on [owasp.slack.com](https://owasp.slack.com/)), or on our [mailing list](https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project). + +Sincerely, +Felipe Zipitria on behalf of the CRS development team From 34ba0b1f266550912886eb7449bb80684e0ddc54 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Thu, 2 Jul 2026 22:11:33 +0200 Subject: [PATCH 4/8] blog: publish v4.28.0, v4.25.1 LTS, v3.3.10 release post Co-Authored-By: Claude Sonnet 4.6 --- .../2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md index d3386b3..2e7c1e2 100644 --- a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md +++ b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md @@ -7,7 +7,6 @@ categories: tags: - CRS-News - Release -draft: true --- The OWASP CRS team is pleased to announce three coordinated releases today: **v4.28.0** (main branch), **v4.25.1** (v4 LTS), and **v3.3.10** (v3 LTS). All three fix the same two high-severity security vulnerabilities. Users on any supported branch are strongly encouraged to update. From fe375f747079b63ef0b24a7f0bd93df102a0acb7 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Thu, 2 Jul 2026 22:20:24 +0200 Subject: [PATCH 5/8] blog: add advisory links to security fix headings Co-Authored-By: Claude Sonnet 4.6 --- ...1-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md index 2e7c1e2..a6586c8 100644 --- a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md +++ b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md @@ -17,7 +17,7 @@ For downloads and installation instructions, please refer to the [Installation]( Both vulnerabilities affect all three release lines. The security advisories will be published once the associated CVEs have been assigned; this post will be updated with CVE numbers at that time. -### XML attribute value bypass (GHSA-6jp8-c2w2-x7wr) +### XML attribute value bypass ([GHSA-6jp8-c2w2-x7wr](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-6jp8-c2w2-x7wr)) **Severity:** HIGH — CVSS 3.1 score 7.2 (`AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N`) **CWE:** CWE-138 — Improper Neutralization of Special Elements @@ -59,13 +59,9 @@ SecRuleUpdateTargetByTag "attack-sqli" "!XML://@*" SecRuleUpdateTargetByTag "attack-fixation" "!XML://@*" ``` -#### Full advisory - -The full advisory will be published at [GHSA-6jp8-c2w2-x7wr](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-6jp8-c2w2-x7wr) once the associated CVE has been assigned and published. - Credit goes to [@HackingRepo](https://github.com/HackingRepo) for reporting this issue and to [@theseion](https://github.com/theseion) for the fix. -### Unix RCE ReDoS in shared regex-assembly include (GHSA-f5qm-3h4p-8qhg) +### Unix RCE ReDoS in shared regex-assembly include ([GHSA-f5qm-3h4p-8qhg](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-f5qm-3h4p-8qhg)) **Severity:** HIGH — CVSS score pending **CWE:** CWE-1333 — Inefficient Regular Expression Complexity @@ -94,7 +90,7 @@ There is no workaround that fully preserves detection without applying the patch #### Full advisory -The full advisory will be published at [GHSA-f5qm-3h4p-8qhg](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-f5qm-3h4p-8qhg) once the associated CVE has been assigned and published. +The full advisory is available at [GHSA-f5qm-3h4p-8qhg](https://github.com/coreruleset/coreruleset/security/advisories/GHSA-f5qm-3h4p-8qhg). ## Changes in v4.28.0 From 88ed54adb52a21502ca7ff180e8a2753c5848bb8 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Thu, 2 Jul 2026 22:24:58 +0200 Subject: [PATCH 6/8] blog: update ModSecurity v2 gate note for 2.9.14 fix Co-Authored-By: Claude Sonnet 4.6 --- ...7-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md index a6586c8..c208d0a 100644 --- a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md +++ b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md @@ -41,11 +41,11 @@ SecAction "id:900130,phase:1,nolog,pass,\ **v4.28.0** ships the fix unconditionally with no gate. -#### Known limitation on ModSecurity v2 (Apache) — LTS branches +#### ModSecurity v2 (Apache) — LTS branches -On **ModSecurity v2/Apache**, the opt-out (`tx.crs_xml_attr_inspect=0`) cannot fully suppress XML attribute inspection. The `ctl:ruleRemoveTargetByTag` directive does not correctly remove `XML://@*` selectors at runtime on that engine, even though the same mechanism works correctly for ordinary variables and works correctly on libmodsecurity v3. Detection of XML-attribute payloads therefore remains active even with the gate disabled. +**ModSecurity 2.9.14** (released 2026-07-02) fixes the `ctl:ruleRemoveTargetByTag` bug that prevented the opt-out gate from working on that engine ([owasp-modsecurity/ModSecurity#3592](https://github.com/owasp-modsecurity/ModSecurity/issues/3592)). ModSecurity v2/Apache users on 2.9.14 or later can use the `tx.crs_xml_attr_inspect` gate normally. -This has been reported upstream as [ModSecurity#3591](https://github.com/owasp-modsecurity/ModSecurity/issues/3591). ModSecurity v2 users who need to suppress XML attribute inspection entirely should use config-load-time directives instead: +Users on **ModSecurity v2 older than 2.9.14** should update ModSecurity alongside this CRS release. If that is not immediately possible, the gate's opt-out will not take effect; use config-load-time directives instead to suppress attribute inspection: ```apache SecRuleUpdateTargetByTag "attack-protocol" "!XML://@*" @@ -162,6 +162,8 @@ The `tx.crs_xml_attr_inspect` opt-in gate (rules 901180 and 901181 in `REQUEST-9 All three releases are available on the [CRS GitHub releases page](https://github.com/coreruleset/coreruleset/releases). +**ModSecurity v2/Apache users on v4.25.1 or v3.3.10:** update ModSecurity to **v2.9.14** alongside this CRS release to ensure the `tx.crs_xml_attr_inspect` opt-out gate works correctly. + **nginx + libmodsecurity3 users on v4.25.1 or v3.3.10:** update libmodsecurity3 to **v3.0.16** alongside this CRS release. The opt-in gate on these branches uses `ctl:ruleRemoveTargetByTag` with an `XML://@*` target; versions of libmodsecurity3 prior to 3.0.16 reject the `@` character in that position at parse time, preventing the configuration from loading at all ([ModSecurity#3589](https://github.com/owasp-modsecurity/ModSecurity/pull/3589)). v4.28.0 does not use this syntax and has no additional engine version requirement. If you have questions or concerns, please reach out via the [CRS GitHub repository](https://github.com/coreruleset/coreruleset), in our Slack channel (#coreruleset on [owasp.slack.com](https://owasp.slack.com/)), or on our [mailing list](https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project). From 12abff204df4953ebe7452b6e0e60e6c5d585586 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Thu, 2 Jul 2026 22:29:13 +0200 Subject: [PATCH 7/8] blog: remove manual signature, handled by theme Co-Authored-By: Claude Sonnet 4.6 --- ...026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md index c208d0a..43a9904 100644 --- a/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md +++ b/content/blog/2026-07-01-crs-versions-4-28-0-4-25-1-lts-3-3-10-released.md @@ -168,5 +168,4 @@ All three releases are available on the [CRS GitHub releases page](https://githu If you have questions or concerns, please reach out via the [CRS GitHub repository](https://github.com/coreruleset/coreruleset), in our Slack channel (#coreruleset on [owasp.slack.com](https://owasp.slack.com/)), or on our [mailing list](https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project). -Sincerely, -Felipe Zipitria on behalf of the CRS development team + From 733e63ec4ba888770f0026ef66d43e2a1cf7ddf8 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Fri, 3 Jul 2026 09:42:36 +0200 Subject: [PATCH 8/8] chore(renovate): exempt CRS releases from 7-day cooldown Co-Authored-By: Claude Sonnet 4.6 --- renovate.json | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/renovate.json b/renovate.json index b97d7e8..f4bc360 100644 --- a/renovate.json +++ b/renovate.json @@ -10,12 +10,14 @@ { "matchDepNames": ["coreruleset-v3"], "allowedVersions": "<4.0.0", - "groupName": "CRS v3 updates" + "groupName": "CRS v3 updates", + "minimumReleaseAge": "0 days" }, { "matchDepNames": ["coreruleset-v4"], "allowedVersions": ">=4.0.0", - "groupName": "CRS v4 updates" + "groupName": "CRS v4 updates", + "minimumReleaseAge": "0 days" } ], "customManagers": [