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

Commencez par go/email-injection et suivez la manière dont son flux de la source au sink traite les valeurs qui transitent par des structs personnalisées, des champs d’événement et des helpers de notification. Comparez cela au chemin décrit de Forwarded/X-Forwarded-Host vers password-reset-link ; le travail est terminé lorsque la requête couvre le flux indirect et évite le faux négatif signalé.

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.