OWASP CRS 4.23.0 – What’s actually new and whether you should bother
If you’re running ModSecurity (or a compatible WAF) the 4.23.0 release brings a handful of fresh detections, a few false‑positive clean‑ups, and a lot of housekeeping that most people will never notice. Below is a quick run‑through of the bits that matter to a real‑world deployment and a couple of opinions on what feels like noise.
New detection rules – the good stuff
- Vite.js path traversal (CVE‑2025‑30208) – A rule was added to flag attempts at escaping Vite’s dev server. If you host a Vite app, this will catch payloads that try “../…/etc/passwd” style tricks that previously slipped through because the default CRS didn’t know about Vite’s virtual file system.
- Fake Mozilla/5.g user‑agent block – Some bots masquerade as an ancient Mozilla string to dodge simple UA filters. The rule drops those requests outright. In practice I’ve never seen a legit browser send that header, so the hit is negligible, but it does add another line to your logs that you’ll have to ignore.
- “trap” command block – This one stops attackers from sending “trap” as a shell payload (a trick used in some obscure exploit kits). It’s a tiny win; the rule fires on a single word, so the performance impact is nil.
- PHP session file upload prevention – Files that look like PHP session files (e.g., sess_abcdef123456) are now rejected when uploaded.
False‑positive fixes you’ll actually notice
- Ad and tracker cookie noise – The CRS used to flag any request that contained typical advertising cookies, which flooded dashboards with harmless hits. The updated patterns now ignore common analytics cookies while still catching suspicious ones. If you’ve ever been annoyed by a “cookie” rule firing on every visit from a marketing platform, this will feel like a breath of fresh air.
- Malformed SSRF URLs – A new regex catches malformed URL schemes that previously triggered the generic SSRF rule and produced false alerts. This is handy if your API accepts user‑provided URLs; you’ll get cleaner logs without sacrificing protection.
- Request‑Range header handling – Two changes: the old “allow” list entry for Range was removed, and a fresh block now triggers when the header appears at all. I’ve seen legitimate browsers use it for resumable downloads, but most web apps don’t need it, so the trade‑off is usually worth it.
Housekeeping – clean‑up or bloat?
The release also stripped out a bunch of dead variables and duplicated captures, moved many regexes to the new “regex‑assembly” module, and trimmed the off‑domain check that was causing occasional false positives on CDN‑served assets. Most of this is invisible to end users, but it does shave a few milliseconds off rule processing time.
My take: the housekeeping itself isn’t groundbreaking, but it shows the CRS maintainers are finally pruning the cruft that made older versions feel sluggish. The removal of the off‑domain check might bite sites that rely on strict same‑origin policies for security monitoring, so double‑check your custom rules if you were counting on that behavior.
Should you upgrade now?
If you’re already on a recent CRS version (4.22.x or later) the upgrade is low risk – just run it through your staging environment and watch the alerts for any spikes in “ad cookie” or “range header” events. The new Vite detection and PHP session block are solid security wins; the fake UA rule is mostly noise reduction.
If you’re still on a pre‑4.20 release, consider upgrading anyway. The false‑positive clean‑ups alone will make your alerting less noisy, which is half the battle when you’re trying to separate real attacks from background chatter.
For more information and a detailed change log, check out the release announcement below:
Release Coreruleset v4.23.0
What's Changed
Important changes feat(920640): add rule to enforce content-type if there is body by @fzipi in #4406
