Inconsistent Error Log Format of ModSecurity depending on Apache's ErrorLogFormat directive

There is a funny behavior in the 2.9.x release line that I discovered yesterday.

ModSec 2.9.x has a habit of writing a prefix into the error log: [client <IP Address>] ModSecurity: ...

Starting 2.9.8 and following a merge of a bugfix by Marc Stern (https://github.com/owasp-modsecurity/ModSecurity/pull/3192), this prefix in square brackets disappears when you configure ErrorLogFormat in Apache. If you do not configure said directive, the [client ...] prefix remains, but the IP is accompanied by a colon and the client port number.

Up to 2.9.7, the Apache error log format would not change the behavior of ModSecurity. It would simply allow you to define the Apache prefix (e.g. format of the timestamp, severity etc.).

But now suddenly ModSecurity reacts to this as well. I am not sure this can be considered a bug. But it's certainly undocumented behavior.

Example ModSec 2.9.7 with ErrorLogFormat (-> ErrorLogFormat "[%{cu}t] [%-m:%-l] %-a %-L %M"):

[2025-12-02 11:46:39.609045] [security2:error] 127.0.0.1:48024 aS7Djwp_d4rQSzSzUpsP1wAAAAE [client 127.0.0.1] ModSecurity: Warning. Matched phrase "etc/passwd" at ARGS:test. [file "/home/dune73/crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "118"] [id "930120"] [msg "OS File Access Attempt"] [data "Matched Data: etc/passwd found within ARGS:test: /etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.21.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/ATTACK-LFI"] [tag "capec/1000/255/153/126"] [hostname "localhost"] [uri "/index.html"] [unique_id "aS7Djwp_d4rQSzSzUpsP1wAAAAE"]

Example ModSec 2.9.8 with ErrorLogFormat:

[2025-12-02 11:47:02.523759] [security2:error] 127.0.0.1:43714 aS7DpilIiJN1A-ostwkEZQAAAAA ModSecurity: Warning. Matched phrase "etc/passwd" at ARGS:test. [file "/home/dune73/crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "118"] [id "930120"] [msg "OS File Access Attempt"] [data "Matched Data: etc/passwd found within ARGS:test: /etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.21.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/ATTACK-LFI"] [tag "capec/1000/255/153/126"] [hostname "localhost"] [uri "/index.html"] [unique_id "aS7DpilIiJN1A-ostwkEZQAAAAA"]

Example ModSec 2.9.8 without ErrorLogFormat:

[Tue Dec 02 11:47:30.996655 2025] [security2:error] [pid 2150210:tid 2150239] [client 127.0.0.1:38370] ModSecurity: Warning. Matched phrase "etc/passwd" at ARGS:test. [file "/home/dune73/crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "118"] [id "930120"] [msg "OS File Access Attempt"] [data "Matched Data: etc/passwd found within ARGS:test: /etc/passwd"] [severity "CRITICAL"] [ver "OWASP_CRS/4.21.0-dev"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/ATTACK-LFI"] [tag "capec/1000/255/153/126"] [hostname "localhost"] [uri "/index.html"] [unique_id "aS7DwtEn2rWqwBtW5o1hlQAAAAA"]

Start by reproducing the three reported ModSecurity 2.9.7 and 2.9.8 cases with and without Apache's ErrorLogFormat directive. Read the behavior change from the bugfix merge in pull request 3192, then determine whether the expected result is restored compatibility or documented behavior; done means the chosen behavior is consistent and covered by an appropriate regression check.