Rule 932200 from https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf creating false positives for GraphQL query

Description

For certain GraphQL queries the rule 932200 is creating false positives. For example, for the following GraphQL query, the rule is tracing $f and blocking it even though its a valid request:

query HeroComparison($first: Int = 3) {
  leftComparison: hero(episode: EMPIRE) {
    ...comparisonFields
  }
  rightComparison: hero(episode: JEDI) {
    ...comparisonFields
  }
}

fragment comparisonFields on Character {
  name
  friendsConnection(first: $first) {
    totalCount
    edges {
      node {
        name
      }
    }
  }
}

Audit Logs / Triggered Rule Numbers

POC: https://regex101.com/r/Y1F1ko/1

Rule 932200 of shell injection URL: https://github.com/coreruleset/coreruleset/blob/v4.0/dev/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf

Confirmation

[x] I have removed any personal data (email addresses, IP addresses, passwords, domain names) from any logs posted.

[dune73]

Unfortunately yes, @fuomag9. And there is very little we can do with CRS alone. The problem is the lack of parser in ModSec (compare with XML and JSON …).

[fzipi]

An example GraphQL query could be this:

curl --location --request POST 'https://echo.hoppscotch.io/graphql' \
--header 'Content-Type: application/json' \
--data-raw '{"query":"query Request {\n  method\n  url\n  headers {\n    key\n    value\n  }\n}\n","variables":{}}'