GHSA-prpw-wwv7-xjjr — Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields

Affected: Go: github.com/corazawaf/coraza/v3

## Root Cause

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

```go // 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 visual…

Most recent entries from all

GHSA-prpw-wwv7-xjjr — Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields