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

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.

Start by reproducing the chained SecRule example with SecAuditEngine RelevantOnly and the provided curl request. Trace the audit logging behavior for a chain containing a non-final multiMatch action; done means a partial chain match does not write to the audit log while a complete match retains the expected behavior.