Rules with both chain and multiMatch may produce excess writes to audit log

[martinhsv]

If a chained rule has at least one rule that includes the multiMatch action and the rule with the multiMatch action is not the final rule in the chain, then writes to the audit log may occur even if not all rules within the chain resulted in a match.

For example, with SecAuditEngine RelevantOnly and the following chained rule:

SecRule ARGS "@contains y0" "id:1001,phase:2,t:urlDecode,t:lowercase,multimatch,log,deny,status:403,chain"
SecRule ARGS "@contains y1" "t:none"

In this case, if only the first rule of the two-rule chain matches, as in this request

and with this request: curl http://localhost/testget.php?a=y0

... then a write to the audit log can still occur.

The transaction is (correctly) not denied, and no other ill effects have been observed.

This has been confirmed to be longstanding behaviour in ModSecurity v3 (at least as far back as v3.0.3) rather than a regression.

[ssigwart]

I think this issue affects rule 942131 of the OWASP CRS: https://github.com/coreruleset/coreruleset/blob/9875b44c0b9d91144d02df78af8e056d96ce0ffb/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf#L722-L746

1 is not 1 triggers the first rule, but not the second. However, it still gets logged (if using blocking_paranoia_level 2).