November 3, 2026
By
Felipe Zipitria
A web application firewall produces exactly one thing you can hold in your hands: logs. Blocking is a side effect of a rule matching; the log line is the record that it happened, why, and what the request looked like. If nobody reads those logs, the WAF is a very expensive way to return 403s.
This is the first of a three part series on logging with OWASP CRS:
Part 1 (this post): what ModSecurity and CRS write to disk, how to read it, what to look for, and the two small additions we recommend before you ship a single line to a log platform. Part 2: ModSecurity, with the logs shipped to the Elastic Stack (Logstash, Elasticsearch, Kibana) and a ready made dashboard. Part 3: Coraza, with the logs shipped to Grafana and Loki through Alloy, and the same dashboard. Parts 2 and 3 come with Docker Compose stacks you can run locally in a few minutes. Each post has its files attached, and a zip with all of them at the end. Both use the CRS project’s own container images and the same CRS release. Part 2 runs owasp/modsecurity-crs, NGINX with ModSecurity v3 (libmodsecurity). Part 3 runs coraza-crs, Caddy with Coraza. The examples in this post come from ModSecurity v3; most of it applies to ModSecurity v2 on Apache and to Coraza as well, and where the engines differ, we say so.
October 2, 2026
By
Felipe Zipitria
The OWASP CRS team is pleased to announce two coordinated releases today: v4.30.0 (main branch) and v4.25.2 (v4 LTS). Both fix the same three security vulnerabilities, published today as GitHub security advisories, along with a file upload bypass in the PHP and Java upload checks. Users on either supported v4 line are strongly encouraged to update.
For downloads and installation instructions, please refer to the Installation page.
Security fixes All three vulnerabilities affect both release lines. CVE identifiers have been requested and will be added to the advisories once assigned.
July 2, 2026
By
Felipe Zipitria
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 that affect all previous CRS releases. Users on any supported branch are strongly encouraged to update.
For downloads and installation instructions, please refer to the Installation page.
Security fixes Both vulnerabilities affect all three release lines.
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
June 29, 2026
By
Felipe Zipitria
Open WAF Day Vienna 2026 is behind us, and it’s time to look back at a great day of talks and discussions at the Austria Center.
We had around 20-30 people join us in the room, catching up between talks, comparing notes on running WAFs in production, and asking the kind of pointed questions that only come from people who actually operate these systems. The agenda ended up being:
June 3, 2026
By
Felipe Zipitria
We are happy to share the full agenda for Open WAF Day Vienna 2026, taking place on Wednesday, June 24, 2026 at the Austria Center in Vienna. Five talks, two connectors, one adaptive honeypot, and a day full of WAF discussions await you.
Schedule All times are local (CEST).
Time Speaker(s) Title 09:45 – 10:00 — Registration & Welcome 10:00 – 10:45 Matteo Pace Embracing Envoy’s Dynamic Modules: Meet the new Coraza connector 10:45 – 11:00 — Coffee break 11:00 – 11:45 Ervin Hegedüs WAF error log analysis at the highest level: ultra-fast filtering and multi-level aggregation with minimal resources 11:45 – 12:45 — Lunch break 12:45 – 13:30 Juan Pablo Tosso Coraza Center: bringing your WAF closer to GitOps 13:30 – 13:45 — Coffee break 13:45 – 14:30 Lukas Funk Ingress NGINX is retired – now what about my WAF rules?! 14:30 – 14:45 — Coffee break 14:45 – 15:30 Adrian Winckles & Gautam Juvarajiya CHAMELEON-REN: Instrumenting Adaptive Honeypots with CRS for Education-Sector Threat Intelligence 15:30 – 16:00 — Closing & Networking Talks Embracing Envoy’s Dynamic Modules: Meet the new Coraza connector Matteo Pace
May 11, 2026
By
Felipe Zipitria
This is Part 7 — the final post — in the CRS 3.3 → 4.25 LTS migration series. The previous six posts covered the overview, configuration, plugins, anomaly scoring, rule changes, and tuning. This post covers the engine layer: what WAF engines CRS 4 supports, how support differs across them, and the changes to container-based deployments.
Choosing the right engine for CRS 4 Brett Sayles on Pexels
May 4, 2026
By
Felipe Zipitria
This is Part 6 of the CRS 3.3 → 4.25 LTS migration series. Part 5 covered rule changes and how to audit your existing exclusions. This post covers the tuning phase itself — the practical work of establishing a clean CRS 4 baseline for your applications.
Fine-tuning for production Dave H on Pexels
Two Migration Strategies There are two approaches to handling false positive tuning during the migration. Neither is universally better — choose based on the size and complexity of your existing setup.
April 27, 2026
By
Felipe Zipitria
This is Part 5 of the CRS 3.3 → 4.25 LTS migration series. Part 4 covered anomaly scoring and reporting. This post covers the rule-level changes: what is new, what is gone, what moved, and how to audit your existing exclusions against the CRS 4 rule set.
Hundreds of rules changed under the hood Egor Komarov on Pexels
The Scale of Change There are hundreds of rule-level changes between CRS 3.3 and CRS 4.0. This is not a point release — it is the result of years of accumulated improvements, a public bug bounty programme, and deliberate architectural cleanup. Understanding the shape of this change helps you plan your tuning work.
April 20, 2026
By
Felipe Zipitria
This is Part 4 of the CRS 3.3 → 4.25 LTS migration series. Part 3 covered the plugin architecture. This post covers anomaly scoring, the reporting model, and paranoia level changes — the areas most likely to affect your baseline after a migration.
Measuring and scoring every request ThisIsEngineering on Pexels
How Anomaly Scoring Changed The CRS 3 Model In CRS 3, every rule that fires adds to a single transaction variable tx.anomaly_score. At the end of phase 2 (for inbound) and phase 4 (for outbound), the total accumulated score is compared against tx.inbound_anomaly_score_threshold and tx.outbound_anomaly_score_threshold. If the score exceeds the threshold, the request is blocked.
April 13, 2026
By
Felipe Zipitria
This is Part 3 of the CRS 3.3 → 4.25 LTS migration series. Part 2 covered crs-setup.conf changes. This post covers the plugin architecture — the most structurally significant change in CRS 4, and the one that requires the most hands-on action from operators who used application exclusion packages in CRS 3.
The Key Change: Application Exclusions Are No Longer in Core In CRS 3.3, the release tarball included a set of optional rule exclusion packages. If you ran WordPress, Nextcloud, phpBB, phpMyAdmin, Drupal, or a handful of other applications, you could include these files to suppress false positives specific to those applications:
