CodeQL flags r.Host reaching slog in the forward proxy's debug/warn lines #1612

Problem

CodeQL (go/log-injection, medium) flags r.Host reaching slog.* calls in core/listener/forwardproxy/server.go. The alert surfaced on #1599 (alert #323) but the flagged flow is pre-existing — the PR's changes shifted line numbers; the vulnerable statements are unchanged.

Call sites on main where r.Host is passed as a log attribute without sanitization:

• core/listener/forwardproxy/server.go:546 (buffered request body)
• :739 (client went away before the upstream answered)
• :742 (upstream request failed)
• :820 (text/event-stream responses will use the buffered path)
• :848 (text/event-stream response with a ReadsBody plugin that is not a StreamingResponder)
• :2045 (response body read error)
• :2049 (response body too large)
• :2099 (streaming response ended by client hangup)
• :2163 (ResponseWriter does not support flushing)
• :2261 (streaming write error)
• :2340 (streaming write error)

r.Host on an HTTP request is set from the Host header (or request-line authority for CONNECT), so a client can embed newlines or other control characters and inject forged log lines.

Status

CodeQL only reports flows that pass through PR-changed lines, so these alerts fire sporadically — any PR that edits code on a path to one of these log sites will raise them again. Same mechanic as #1533, different source and sink.

Fix

Either:

1. Sanitize at the source — a sanitizedHost(r) helper that strips \n/\r from r.Host, used at every log site. CodeQL recognises strings.ReplaceAll as a log-injection sanitizer (per CodeQL flags the session id's header-to-log flow on every PR that touches it #1533).
2. Add a path-scoped query-filters entry in .github/codeql/codeql-config.yml with a written reason, if the maintainers judge the sites low-risk enough to suppress.

Option 1 is the honest fix and keeps the alerts from recurring.

Found while reviewing CodeQL alert #323 on #1599.