crs-toolchain expands `[\s\S]` to `[\x00-\x{10ffff}]` breaking PCRE/ModSecurity v2

[fzipi]

what

When a .ra file contains [\s\S] (match any character including newlines), the toolchain expands it to [\x00-\x{10ffff}]. This is valid RE2 syntax but invalid in PCRE non-UTF mode as used by ModSecurity v2/Apache, causing:

AH00526: Syntax error on line 294 of .../REQUEST-941-APPLICATION-ATTACK-XSS.conf:
Error creating rule: Error compiling pattern (offset 55): character code point value in \x{} or \o{} is too large

why

[\s\S] is a common cross-engine idiom for "match any character including newlines" and works in both PCRE and RE2. The toolchain's expansion to [\x00-\x{10ffff}] breaks PCRE compatibility, preventing rules that use [\s\S] from being converted to .ra format.

Currently no existing .ra files use [\s\S], so this hasn't been an issue. However, several rules in the CRS use [\s\S] in their regex patterns (e.g., 941170) and cannot be converted to .ra format due to this limitation.

steps to reproduce

1. create a .ra file containing [\s\S] in a pattern (e.g., for rule 941170)
2. run crs-toolchain regex generate <RULEID>
3. observe [\x00-\x{10ffff}] in the output
4. run crs-toolchain regex update <RULEID>
5. restart ModSecurity v2/Apache — compilation fails

expected behavior

The toolchain should preserve [\s\S] as-is (or expand it to a PCRE-compatible equivalent like [\x00-\xff]) since [\s\S] is valid in both PCRE and RE2.

refs

• discovered while converting rule 941170 to .ra format for Move regexes to regex-assembly format before LTS coreruleset#4480