Summary
I am experiencing issues when using regular expressions containing variable-length lookbehind assertions (e.g., (?<!.(?:target|origin).{0,20})\bhaving\b) in ModSecurity v3. The pattern fails to match as expected, likely due to limitations in the underlying PCRE library integration or configuration within src/utils/regex.cc.
Steps to Reproduce
Create a SecRule using a variable-length lookbehind:
SecRule ARGS "@rx (?<!.(?:target|origin).{0,20})\bhaving\b" "id:12345,phase:2,deny,status:403"
Send a request with a payload that should match (e.g., ?data=select having count).
Observe that the rule is not triggered.
Actual Behavior
The regex fails to match the input. In some environments, no explicit compilation error is shown in the debug log, leading to "silent failure" where the rule is simply ignored.
Expected Behavior
The regex should either:
Match the input if the linked PCRE library (PCRE2 10.30+) supports variable-length lookbehind.
Provide a clear compilation error in the ModSecurity log indicating that the pattern is unsupported by the current PCRE version.
Technical Context
Looking at src/utils/regex.cc, ModSecurity wraps PCRE/PCRE2. However:
Most PCRE1 versions (still common in many distros) strictly forbid non-fixed-width lookbehind (errors like lookbehind assertion is not fixed length).
If ModSecurity is compiled with PCRE2, it should theoretically support this, but the implementation may not be passing the necessary JIT or match options to handle complex lookbehind depth.
Summary
I am experiencing issues when using regular expressions containing variable-length lookbehind assertions (e.g., (?<!.(?:target|origin).{0,20})\bhaving\b) in ModSecurity v3. The pattern fails to match as expected, likely due to limitations in the underlying PCRE library integration or configuration within src/utils/regex.cc.
Steps to Reproduce
Create a SecRule using a variable-length lookbehind:
SecRule ARGS "@rx (?<!.(?:target|origin).{0,20})\bhaving\b" "id:12345,phase:2,deny,status:403"
Send a request with a payload that should match (e.g., ?data=select having count).
Observe that the rule is not triggered.
Actual Behavior
The regex fails to match the input. In some environments, no explicit compilation error is shown in the debug log, leading to "silent failure" where the rule is simply ignored.
Expected Behavior
The regex should either:
Match the input if the linked PCRE library (PCRE2 10.30+) supports variable-length lookbehind.
Provide a clear compilation error in the ModSecurity log indicating that the pattern is unsupported by the current PCRE version.
Technical Context
Looking at src/utils/regex.cc, ModSecurity wraps PCRE/PCRE2. However:
Most PCRE1 versions (still common in many distros) strictly forbid non-fixed-width lookbehind (errors like lookbehind assertion is not fixed length).
If ModSecurity is compiled with PCRE2, it should theoretically support this, but the implementation may not be passing the necessary JIT or match options to handle complex lookbehind depth.