ModSecurity's HttpsClient::download function incorrectly sets libcurl's SSL_VERIFYHOST option to a non‑strict value (1 instead of 2), weakening the verification of the server’s hostname during TLS handshakes. In the presence of a man‑in‑the‑middle or TLS interception, this may allow the client to accept a certificate issued for an unintended host, thereby exposing the communication to potential spoofing. Although bypassing hostname validation does not immediately grant remote execution, it can facilitate credential theft or data tampering if the attacker controls the TLS link.

The vulnerability affects the ModSecurity web application firewall engine for Apache, IIS, and Nginx, specifically versions released before ModSecurity 2.9.15 and 3.0.17. The earlier 2.x and 3.x branches contain the insecure setting. Users deploying those editions should review their version and upgrade to at least 2.9.15 or 3.0.17 to eliminate the issue.

The CVSS base score of 3.7 indicates low severity, and the lack of a publicly disclosed exploit and absence from the CISA KEV catalog suggest limited threat. Nonetheless, the EPSS score is unavailable, so the precise exploitation likelihood is uncertain, but under suitable man‑in‑the‑middle conditions the weakness can be leveraged. The primary attack vector is a TLS interception that forces the client to accept a non‑hostmatching certificate, which requires physical or network control of traffic, making widespread exploitation challenging but still relevant for targeted attacks.