Proposed changes

This PR introduces a new detection rule targeting a parsing ambiguity where an ampersand (&) appears in the URI path before the beginning of a valid query string (?).

While this pattern is not compliant with standard URI syntax, it is observed in real-world deployments where backend rewrite rules (e.g. ?url=$1) may reinterpret path segments as query parameters. In such cases, characters like & embedded in the path can be promoted to query delimiters after rewriting.

More concretely, if an .htaccess or vhost contains the following rule:

^api(?:/(.*))?$ index.php?url=$1

Then, if the following request is sent:

GET /api/test&payload=my_payload

The WAF does not interpret payload as a parameter.

However, since the rewrite rule transforms the URI into:

GET /index.php?url=api/test&payload=my_payload

The backend application does receive the payload parameter with the value my_payload.

This also introduces additional side effects - including the neutralization of potential sanitiseMatched instructions, effectively exposing parameters that should be obfuscated in clear text within the frontend access logs.

This behavior creates a discrepancy between how the WAF (CRS) and the backend application interpret the request. Since CRS relies on normalized query parsing to populate ARGS collections, parameters injected via the path are not analyzed during rule evaluation. As a result, this can effectively neutralize detection logic relying on ARGS and enable parameter smuggling.

You will likely point out that most rules do not only analyze ARGS but also inspect REQUEST_URI, which mitigates the severity of this bypass; however, it still seems important to take this behavior into account.

The proposed rule detects any occurrence of & in the URI before a ?, which is a strong indicator of such ambiguity and a potential bypass vector.

This rule will inherently generate false positives, as the & character can be a perfectly legitimate character in filenames or path segments depending on the application context. For this reason, it has been placed at Paranoia Level 3 (PL3), although placement at PL4 could also be considered.

This addition strengthens CRS coverage against parser confusion and rewrite-assisted parameter smuggling techniques, which are currently not explicitly addressed.

What do you think ?

P.S. PrestaShop is very likely not the only application affected by this kind of behavior in .htaccess rewrite rules.

PR Checklist

• I have read the CONTRIBUTING doc
• I have added positive tests proving my fix/feature works as intended.
• I have added negative tests that prove my fix/feature considers common cases that might end in false positives
• In case you changed a regular expression, you are not adding a ReDOS for pcre. You can check this using regexploit
• My test use the comment field to write the expected behavior
• I have added documentation for the rule or change (when appropriate)

Further comments

For the reviewer

• Positive and negative tests were added
• Tests cover the intended fix/feature properly
• No usage of dangerous constructs like ctl:requestBodyAccess=Off were used in the rule
• In case a regular expression was changed, there is no ReDOS
• Documentation is clear for the rule/change