When Rule Downloads Lose Hostname Verification: CVE-2026-61812 in ModSecurity

Three of the four ModSecurity flaws patched in this batch affect how requests are inspected. CVE-2026-61812 affects how the engine gets its rules, and that is a different kind of risk. At disclosure the vendor had not yet published a severity score for it.

Overview of the flaw

CVE-2026-61812 was disclosed together with CVE-2026-73856, CVE-2026-73857 and CVE-2026-61813. The description states that a misconfigured libcurl setting weakens TLS hostname verification during remote rule downloads — listed in the advisory table as awaiting analysis.

Mechanism and exploitation conditions

Remote rule sets let a ModSecurity deployment pull detection logic from a server rather than shipping it in a config file. That fetch uses libcurl, and it is supposed to validate both the certificate chain and the hostname in the certificate.
The flaw is that hostname verification is weakened by a setting the library applies. Certificate-chain validation can still succeed while the identity check is looser than it should be. In that state a party able to intercept the connection — through DNS manipulation, a hostile network path, or a compromised intermediary — can present a certificate that the client accepts even though it does not match the rule host.
Exploiting this requires a position in the network path. It is not reachable by sending a single malformed HTTP request, which is why it belongs to a different risk category from the request-parsing bug in the same batch.

Impact

The payoff for an attacker is control of the rule set. A malicious rule source can disable specific signatures, inject allow rules that exempt an attacker's traffic, or simply deliver a rule set that looks complete and is not. Because the engine treats downloaded rules as authoritative, the WAF keeps reporting that it is protecting the application.
For organisations that fetch rules over the public internet on a schedule, the window is recurring. Every refresh is another opportunity. Organisations that vendor rules, sign them, and deploy from an internal artefact store do not have this exposure at all, which makes this a good moment to check which model is actually in use.

Affected products and scope

• libmodsecurity3, versions 3.0.16 and earlier
• mod_security2, versions 2.9.14 and earlier Reachability depends entirely on whether the deployment downloads rules remotely. A deployment with a static, locally managed rule file is not affected by this flaw even on a vulnerable version.

Exposure context

ZoomEye counts recorded for this topic: ModSecurity title matches 340, application-fingerprint matches 27, banner matches 1,700, body-text matches 777,209. A CVE-scoped query returns zero.
None of those numbers indicates whether a host downloads rules. This particular flaw is decided by configuration, and the inventory question that matters is which hosts pull rules from outside the network.

Remediation and mitigation

Upgrade to libmodsecurity3 3.0.17 or mod_security2 2.9.15.
Independent of the patch, the stronger control is to stop fetching rules from the open internet. Mirror rule sets into an internal store, pin the version, verify a signature or checksum, and deploy from there. That removes the network position the flaw depends on.
Where remote fetching must continue, restrict the destination to a known host, pin the certificate rather than trusting the chain alone, and log every refresh with the downloaded artefact hash so that a substitution would be visible after the fact.

References

• ModSecurity Vulnerabilities: 4 WAF Bypasses Patched — https://securityonline.info/modsecurity-security-vulnerabilities/
• OWASP ModSecurity project releases — https://github.com/owasp-modsecurity/ModSecurity/releases