ModSecurity CVE-2026-42268

Exploitation requires that the administrator has configured the ModSecurity rule set to use at least one of the operators @verifySSN, @verifyCPF, or @verifySVNR - this is the exact prerequisite named in the description and is captured by the CVSS 4.0 AT:P (attack requirement) metric. Given PR:N/UI:N, no attacker authentication or user interaction is needed and the request can be sent remotely over the network, but the limiting factor is decisive: these three national-ID validation operators are not part of default or common rule sets, so any deployment that does not use them is not exploitable. Impact is limited to availability (VA:H, VC:N/VI:N) - a WAF-engine crash - with no confidentiality or integrity effect.

Signals are mixed and point to a real but conditional and non-widespread risk. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VA:H, base 8.2) correctly models a network-reachable, unauthenticated availability-only impact, with AT:P (attack requirement present) reflecting that the vulnerable code path only exists when an administrator deploys one of three uncommon rule operators. SSVC classifies exploitation as 'poc' and automatable as 'yes' with 'partial' technical impact - meaning working proof-of-concept-style triggering is feasible and scriptable, but impact is limited to crashing the engine, not code execution or data theft. Counterbalancing this, EPSS is only 0.04% (13th percentile) and the CVE is not in CISA KEV, indicating no evidence of active or widespread exploitation. The key limiting factor is configuration dependence: @verifySSN/@verifyCPF/@verifySVNR are niche operators absent from most default rule sets, so the majority of ModSecurity deployments are simply not affected. Net: prioritize patching only where these operators are in use; elsewhere this is low real-world risk despite the high CVSS.

An attacker sends a crafted HTTP request whose body or parameter is inspected by a ModSecurity rule using @verifySSN, @verifyCPF, or @verifySVNR; the malformed value triggers the unsigned-integer underflow and an uncaught std::out_of_range exception, crashing the WAF worker and knocking the protected web application offline. Because SSVC rates the issue as automatable with public proof-of-concept indicators, an attacker can script repeated requests to sustain the outage against any endpoint whose rules use these operators.