SecRuleUpdateActionById does not actually replace actions

[blotus]

Description

When using SecRuleUpdateActionById, the new actions are simply appended to the list of existing actions for the rule, which prevents it from being used to disable specific rules.

Steps to reproduce

SecRule ARGS:id "@eq 0" "id:1, phase:1,deny,status:403,msg:'Invalid id',log,auditlog"
SecRuleUpdateActionById 1 "log,pass"

The first rule uses a deny action to block a request if the id parameter is equals to 0.
But there's a SecRuleUpdateActionById to change the action to pass which should allow the request.

Expected result

Request blocked.

I've tested those rules with modsecurity, and the behaviour is the expected one: the request is allowed.

Actual result

The request is not blocked:

~/git/coraza/examples/http-server (main ✘)✹ ᐅ go run main.go
2025/08/28 14:47:44 [DEBUG] Parsing directive line="SecRule ARGS:id \"@eq 0\" \"id:1, phase:1,deny,status:403,msg:'Invalid id',log,auditlog\""
2025/08/28 14:47:44 [DEBUG] Parsing directive line="SecRuleUpdateActionById 1 \"log,pass\""
Server is running. Listening port: 8090
2025/08/28 14:47:56 [DEBUG] Transaction started tx_id="QyVhEtdOAzffqKwkdpM"
2025/08/28 14:47:56 [DEBUG] Evaluating phase tx_id="QyVhEtdOAzffqKwkdpM" phase=1
2025/08/28 14:47:56 [DEBUG] Evaluating rule tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1
2025/08/28 14:47:56 [DEBUG] Expanding arguments for rule tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1 variable="ARGS"
2025/08/28 14:47:56 [DEBUG] Matching rule tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1 variable_name="ARGS" key="id"
2025/08/28 14:47:56 [DEBUG] Evaluating action tx_id="QyVhEtdOAzffqKwkdpM" action="log"
2025/08/28 14:47:56 [DEBUG] Evaluating action tx_id="QyVhEtdOAzffqKwkdpM" action="auditlog"
2025/08/28 14:47:56 [DEBUG] Evaluating action tx_id="QyVhEtdOAzffqKwkdpM" action="log"
2025/08/28 14:47:56 [DEBUG] Evaluating operator: MATCH tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1 variable="ARGS" operator_function="@eq" operator_data="0" arg="0"
2025/08/28 14:47:56 [DEBUG] Executing disruptive action for rule tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1 action="deny"
2025/08/28 14:47:56 [DEBUG] Executing disruptive action for rule tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1 action="pass"
2025/08/28 14:47:56 [DEBUG] Rule matched tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1
[logError][emergency] [client "[::1]"] Coraza: Access denied (phase 1). Invalid id [file "default.conf"] [line "4"] [id "1"] [rev ""] [msg "Invalid id"] [data ""] [severity "emergency"] [ver ""] [maturity "0"] [accuracy "0"] [hostname ""] [uri "/?id=0"] [unique_id "QyVhEtdOAzffqKwkdpM"]
2025/08/28 14:47:56 [DEBUG] Finished rule evaluation tx_id="QyVhEtdOAzffqKwkdpM" rule_id=1
2025/08/28 14:47:56 [DEBUG] Finished phase tx_id="QyVhEtdOAzffqKwkdpM" phase=1
2025/08/28 14:47:56 [DEBUG] Evaluating phase tx_id="QyVhEtdOAzffqKwkdpM" phase=5
2025/08/28 14:47:56 [DEBUG] Finished phase tx_id="QyVhEtdOAzffqKwkdpM" phase=5
2025/08/28 14:47:56 [DEBUG] Transaction marked for audit logging tx_id="QyVhEtdOAzffqKwkdpM"
2025/08/28 14:47:56 [DEBUG] Transaction finished tx_id="QyVhEtdOAzffqKwkdpM" is_interrupted=true status=403 rule_id=1

As we can see in the logs, both deny and pass actions are specified for the rule (and log twice), and because pass is a noop, the interruption set by deny is returned, which blocks the request.

[fusiontechstrategies]

Please make the following changes to the logLegacyStopwatch struct in corazawaf/coraza/coraza-f441571263ade7dbd1f0290c2a1202215a97eef6/internal/auditlog/legacy.go. Capitalize the field names to make them exported and add JSON tags to control the field names in the JSON output. This corrected code should hopefully do the trick:

type logLegacyStopwatch struct {
Combined int64 json:"combined" // Combined processing time
P1 int64 json:"p1" // Processing time for the Request Headers phase
P2 int64 json:"p2" // Processing time for the Request Body phase
P3 int64 json:"p3" // Processing time for the Response Headers phase
P4 int64 json:"p4" // Processing time for the Response Body phase
P5 int64 json:"p5" // Processing time for the Logging phase
Sr int64 json:"sr" // Time spent reading from persistent storage
Sw int64 json:"sw" // Time spent writing to persistent storage
L int64 json:"l" // Time spent on audit logging
Gc int64 json:"gc" // Time spent on garbage collection
}

By changing the field names from lowercase to uppercase, it makes them exported fields that Go's JSON marshaler can properly access. The change above will allow the stopwatch data to be properly marshaled as a JSON object with individual fields instead of a string, making it more structured and easier to parse. After applying the fix, the stopwatch field in the JSON audit logs should change from a string format to a properly structured JSON object.