Hello,

I find it abnormal that we don’t have a PL1 rule capable of catching these trivial SQL injections, except 942100 in most variants, where simply adding a comment is enough to bypass the rules that are supposed to detect them.

This payload is correctly detected by 942350 :

curl -H "x-format-output: txt-matched-rules" -H "x-crs-paranoia-level:2" "https://sandbox.coreruleset.org/" -d 'test=mod(1,2)%3BINSERT%20INTO%20category%28id%29%20VALUES%20%283%29-- -'

**942350** PL1 Detects MySQL UDF injection and other data/structure manipulation attempts

However, just inserting a simple comment like /*test*/ completely neutralizes rules 942350

curl -H "x-format-output: txt-matched-rules" -H "x-crs-paranoia-level:2" "https://sandbox.coreruleset.org/" -d 'test=mod(1,2)%3BINSERT%20%2F%2Atest%2A%2FINTO%20category%28id%29%20VALUES%20%283%29-- -'

While keeping in mind that this proposed change weakens the rule’s protection against this sneakier form of evasion : /*';INSERT INTO categoriy(id) VALUES (3)-- -*/

curl -H "x-format-output: txt-matched-rules" -H "x-crs-paranoia-level:2" "https://sandbox.coreruleset.org/" -d "test=%2F%2A%27%3BINSERT%20INTO%20categoriy%28id%29%20VALUES%20%283%29--%20-%2A%2F"

942100 does catch most of these variants (not all of them like you can seen of this POC). But this rule (942100) is difficult to keep in French environments, so many third parties have completely disabled it.

I didn’t find a working PoC for 942360 to demonstrate that we cannot rely solely on 942100, but I consider that this rule suffers from the same issue, so I propose updating it as well as 942350.

A possible solution to avoid relying exclusively on 942100 would be to strengthen the 942500 regex so that it captures all comments of the form /* … */, not just those specific to MySQL.

Rule 942440 does capture these types of comments, but its placement in PL2 is explained by the fact that it mixes multiple detections including --[\w]-.

--[\w]- triggers erratically on simple slugs or typos, which fully justifies its placement in PL2 - and, in my opinion, it might even deserve to be in PL3.

If we rewrite the regex in 942500 to capture /\*[\s\S]*?\*/ (instead of leaving it to 942440 - see #4328), we should keep in mind that the issue with 942440 doesn’t come from /**/, but rather from --[\w]-

In summary: we’d be moving from a rule that doesn’t detect these sequences at all in PL1 to one that detects them imperfectly. A better approach might be to aggressively block /* … */ comments at PL1 (an update to 942500 would be needed), rather than relying on a partly effective rule - this would provide a clear, minimal surface for evasion while keeping noise to a minimum.

What do you think?