False negative in go/email-injection for password reset links built from Forwarded / X-Forwarded-Host

從 go/email-injection 開始，追蹤其 source-to-sink 流程如何處理透過自訂 struct、事件欄位和通知 helper 傳遞的值。將其與所描述的從 Forwarded/X-Forwarded-Host 到 password-reset-link 的路徑進行比較；完成的標準是查詢涵蓋間接流程，並避免報告中的 false negative。

Hi team,

I think I found a false negative in go/email-injection.

I ran into this while looking at ZITADEL's CVE-2025-64101 / GHSA-mwmh-7px9-4c23. The vulnerable flow is:

• host data comes from Forwarded / X-Forwarded-Host
• it is stored in a request/domain context object
• that value is later carried through an event / notification path
• and eventually used to build a password reset link that gets emailed to the user

Very roughly, it looks like this:

hostFromHeader = r.Header.Get(header)

if host == "" {
    host = hostFromHeader
}

TriggeredAtOrigin: http.DomainContext(ctx).Origin()

url = login.InitPasswordLink(http_utils.DomainContext(ctx).Origin(), user.ID, code, user.ResourceOwner, authRequestID)

The upstream fix sanitizes the host before storing it in the domain context, so this seems like a real missed case, not just a noisy benchmark result.

My guess is that the source side is already covered well enough, since net/http.Request.Header is modeled as remote input. The gap seems to be later in the flow, once the value moves through custom structs / event fields / notification helpers before it becomes part of email content.

I think this pattern is fairly common in real Go code. Password reset and verification links are often built indirectly through app-specific context and mailer abstractions, not directly inside a modeled mail API call.

For comparison, Semgrep did flag this codebase, but only with a broader rule about request-derived origin/host usage. It was not precise, but the general idea may still be useful here: request-header-derived host/origin values that later become user-facing links in emails probably deserve better coverage.

A reasonable fix might be improving go/email-injection so flow is preserved better through custom carrier objects and “build link first, send email later” patterns.