The OWASP Core Rule Set released v4.30.0 and v4.25.2 (LTS) within thirteen minutes of each other on 2 October 2026, pushing three security bypass fixes to both its newest feature line and its older LTS branch. The fixes close a path-based command injection gap in the RCE rules (GHSA-575j-qr6p-9763), a case-sensitivity bug that left the charset allow-list inert at default paranoia levels (GHSA-89h9-2j8h-9gp2), and a multipart _charset_ shadowing trick that let attackers bypass encoding checks (GHSA-qmx4-jfcv-fgww). Beyond security, v4.30.0 adds detections for Active Directory ds tools, Velocity/FreeMarker SSTI, and SELinux commands, while repairing the response-skipping flag. Operators on any v4.x between 4.0.0 and 4.29.x should upgrade to v4.30.0 or v4.25.2 LTS, or apply the advisories' targeted workarounds.
OWASP CRS Ships Coordinated v4.30.0 and v4.25.2 (LTS) Releases
The OWASP Core Rule Set landed two updates within thirteen minutes of each other today, sending three critical WAF bypass fixes both to its newest feature line and to the older LTS branch in a single coordinated push.
Rather than patch just the bleeding-edge release, the maintainers carried the same security fixes straight down the LTS track. That's a deliberate call. When the project pairs a feature bump with an LTS patch on the same day, the fixes were usually deemed urgent enough to warrant cross-line coverage. Both v4.30.0 and v4.25.2 went out signed by Felipe Zipitría (@fzipi), the project's single most active contributor, at 21:19 and 21:06 GMT respectively.
The OWASP CRS is one of those quiet pieces of infrastructure that quietly sits behind a decent chunk of the public web. It's a set of generic, rule-based protections for web application firewalls, shipping with OWASP ModSecurity and the Go-based Coraza, plus other compatible engines. It detects SQL injection, XSS, remote command execution, and template injection, and it's an OWASP Flagship project under the Apache 2.0 license, starred by more than 3,300 developers on GitHub.
Keep in mind that the CRS isn't a magic wall. It's generic detection tuned across four Paranoia Levels, so operators trade false positives for depth depending on where they set the dial. That framing matters here, because two of the three bypasses are tied directly to paranoia level in use.
The three bypasses being closed
All three are "bypass" issues, a specific and annoying class of bug. It's not that a rule fails to match a novel attack. It's that an attacker crafts input that dodges a rule that was already supposed to catch it. In order, the fixes are:
The first, GHSA-575j-qr6p-9763 (CVSS 6.3), lives in the RCE rule family, 932xxx. Those rules watch command-injection payloads inside request parameters, the values you pass as query-string or POST body data. But the rules never listed REQUEST_FILENAME as a target.
So a payload dropped into the URL path itself, such as GET /files/x;id, scores zero anomaly and walks straight through. Even at Paranoia Level 4, the strictest setting, the path went unevaluated. Worth stressing: this isn't weak pattern matching. Rule 932 simply never looked at the path. The XSS and SQL injection families already check the filename, so only RCE had the hole.
Real exploitation still needs the backend to hand a path segment to a shell via something like os.popen or child_process.exec with shell: true. Non-shell calls like execFile are out of scope. And CRS 3.x gets no fix, so legacy users are being pushed to upgrade.
The more serious one is GHSA-89h9-2j8h-9gp2, which lands at CVSS 7.2 and is a v4-only regression. Rule 920480 is supposed to enforce an allow-list of permitted character sets from the Content-Type header. Its anchor regex matched the header with only a t:none transformation and no case-normalizing step.
ModSecurity's @rx operator is case-sensitive by default, so CHARSET= wouldn't match. That might look cosmetic, but rule 920480 is the second link in a rule chain, so when the anchor fails the whole chain dies. No charset gets extracted, no anomaly score accumulates, and the control goes fully inert for any uppercase or mixed-case spelling.
That bites at PL1 and PL2, the defaults behind most production installs. The advisory flags it as a regression from the v3-to-v4 rewrite. v3.3.x already carried a t:lowercase transformation and never had the problem. None of the 23 regression tests bothered to exercise an uppercase spelling, which is how the gap slipped through.
Not cheap. The third bypass, GHSA-qmx4-jfcv-fgww (CVSS 5.8), is multipart-related and easy to picture. Rule 922100 watches the global _charset_ field in a multipart request. The reporter, @airween, showed that a second _charset_ value anywhere in the request, say a benign utf-8 in the query string, shadows the disallowed one the rule had flagged.
One extra argument and the check just skips. The fix makes the rule collect every _charset_ value so a shadowing second value can no longer hide.
All three ship in both v4.30.0 and v4.25.2. Versions between 4.0.0 and 4.29.x are affected, while CRS 3.3.x isn't hit by the casing bug at all.
New detections, repairs, and the LTS backport
On top of the security work, v4.30.0 adds a batch of new detections. You get rules for Active Directory ds command-line tools, a tell after compromise; Apache Velocity and FreeMarker SSTI syntax; SELinux command usage; a new Mozilla/6.0 scanner user-agent signature; and .claude added to the restricted-files list.
A handful of false positives get cleared, including the case where the vega scanner signature matched the legitimate domain veganism.social, a classic substring overreach.
But the genuinely useful fix here is to response skipping. The tx.crs_skip_response_analysis flag used to skip only phase 3 (header) rules. Operators who turn off response-body inspection for speed now find phase 4 rules actually get skipped too, via new rule 950022. It does what the documentation promised for the first time.
Then there's v4.25.2 LTS, which is really just the same security fixes carried down the branch, plus a couple of fixes that showed up in between. At the time it shipped, the LTS tag sat 117 commits behind main. So the backport also pulls in an SQL injection length-bound hardening (rule 942390) and the upload trailing-slash closure. Operators locked to a controlled upgrade cadence get the same shield without being dragged onto a newer feature baseline.
This dual release is standard practice for mature open-source projects. It quietly flags how widespread the casing regression was: essentially every v4.x release from 4.0.0 on carried it, which is exactly why it got backported so aggressively.
One aside: the advisory for the casing issue carries an AI Disclosure note. Per the project's AI-CONTRIBUTIONS.md policy, Claude (Sonnet 5) reportedly helped triage the bypass, confirm the root cause against the rule source, and draft the advisory. Given how tightly this fix hinges on a case-normalization step, that's a plausible fit. It's the kind of detail you'd want to verify against the source yourself.
So what happens if you run CRS right now? Upgrade promptly if you're on any v4.x between 4.0.0 and 4.29.x, either to v4.30.0 for the newest detections or to v4.25.2 LTS if you value a supported, low-risk baseline. Both close all three bypasses. If you can't upgrade this minute, the advisories spell out workarounds: add REQUEST_FILENAME to the affected 932 rules, inject t:lowercase into rule 920480 with SecRuleUpdateActionById, and make sure all _charset_ values are collected for 922100. Still on 3.x? There's no October fix for you except the isolated casing issue you likely already dodge, so plan the migration and use targeted SecRuleUpdateTargetById overrides at your own false-positive risk. And before you deploy, run your regression suite, especially anything touching charset declarations or multipart uploads, since these fixes touch content-type handling and response-skip behavior.
Release v4.30.0 · coreruleset/coreruleset
What's Changed
Security fix: inspect REQUEST_FILENAME in RCE (932) rules to close path-based command injection bypass — https://github.com/coreruleset/coreruleset/security/advisories/GHSA-575j-q...
Release v4.25.2 (LTS) · coreruleset/coreruleset
v4.25.2 - 2026-10-02 Security Fixes Backport fix for [GHSA-575j-qr6p-9763] via adding REQUEST_FILENAME to the targets of the RCE rules, so command injection payloads placed in the URL path are ins...
