ModSecurity + OWASP CRS

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 9 Last 12 months Parsing/validation 50 % Memory safety 30 % Denial of service 20 % Latest advisories Loading the feed Overview ModSecurity and the OWASP Core Rule Set are the default WAF layer of the conventional web: libmodsecurity3 with its Apache, nginx and IIS connectors, running CRS rules in front of an enormous number of PHP and nginx applications, throughout shared hosting, and inside commercial WAF products that embed CRS wholesale. They belong in one entry because nobody deploys one without the other. CVE-2026-21876 is the reference point, a CRITICAL multipart bypass on the rule side: the request the operator paid to have blocked arrives at the application intact, with no error and no log line saying anything went wrong. Neither project has a cent behind it, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Two policies, one target. ModSecurity takes reports through GitHub private vulnerability reporting on owasp-modsecurity/ModSecurity ; CRS takes them at [email protected] for the two latest point releases plus the v4.25.x LTS line The libmodsecurity3 engine in full: rule parsing, the transaction lifecycle, phase handling, transformations, operators and actions Every body processor, covering multipart/form-data, XML, JSON, URL-encoded and raw bodies Request-line, header, query-string and cookie parsing, plus the response-body inspection path on the way back out The Apache, nginx and IIS connectors that hand the request to libmodsecurity3 in the first place The audit log and its serialisation of attacker-controlled request data The complete CRS rule set at every Paranoia Level, including the regex-assembly includes and the rules generated from them The CRS rule groups in full: protocol enforcement, application attack detection, file upload handling, and the anomaly scoring and exclusion packages shipped alongside them Out of scope Coraza, a separate OWASP project with its own reporting channel, even though it runs the same rule set Commercial WAF products that embed CRS, which are those vendors' targets CRS releases outside the supported-version policy: the two latest point releases and the v4.25.x LTS line are what the project patches Rules that fail to catch an attack nobody wrote a rule for, which is a coverage request rather than a bypass Paranoia Level tuning and false positives, which are documented configuration outcomes Most-valued findings A body-parser differential that gets a payload past the WAF and into the application intact, the densest class of the last twelve months: the CRITICAL multipart bypass in CVE-2026-21876, the XML attribute value bypass in CVE-2026-62971, and the engine's line-break-stripping multipart defect in CVE-2026-52747 Multipart handling in particular, which has now produced a CRITICAL on the rule side and a HIGH on the engine side inside the same year and is plainly not finished Memory-safety and integer defects in libmodsecurity3 reachable from an ordinary request, the shape of the @verifySSN , @verifyCPF and @verifySVNR underflow in CVE-2026-42268 and the single-character query-string segfault in CVE-2026-30923, because the engine runs inside the web server process on every request that server handles ReDoS in a shipped CRS rule, as CVE-2026-61619 put into the shared unix-shell-evasion regex assembly, letting one request consume the CPU of the layer protecting everything behind it Upload-handling bypasses that get a file past the extension and content checks, the CVE-2026-33691 whitespace-padding class, given that these rules are frequently the only thing between a shared-hosting tenant and a webshell Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. The two halves have different channels and you have to pick correctly: engine bugs go through GitHub private vulnerability reporting on owasp-modsecurity/ModSecurity , which the SECURITY.md routes to via the README's security section Rule-set bugs go to [email protected] , with a GPG fingerprint published for encryption: 3600 6F0E 0BA1 6783 2158 8211 38EE ACA1 AB8A 6E72 , the same key CRS signs its releases with Work the CRS pre-submission checklist before sending: confirm you are on the latest version, identify the Paranoia Level, and reproduce the bypass against the public CRS Sandbox Include the Sandbox X-Unique-ID from that reproduction, since it is what lets the maintainers pull your exact transaction rather than guess at it CRS supports the two latest point releases plus the v4.25.x LTS line, patched until Q3 2027; a finding against anything older gets closed on the supported-version policy CRS will obtain a CVE identifier on request if you want one Disclosure Two coordinated processes running in parallel: ModSecurity publishes through GitHub Security Advisories on owasp-modsecurity/ModSecurity , and CRS coordinates by email under its own GPG key and will request a CVE on your behalf. CRS also publishes a supported-version policy, so the release you test against decides whether there is anything to coordinate at all. Both sides expect the finding held until the fixing release ships. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability