github / github/codeql

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

Open
#21,770 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
CodeQL
Stars
10.1k
Forks
2.1k
Avg merge
2d 15h
Merged PRs (30d)
141

Description

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:

```go
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.

Contributor guide

Open the contributing guide

Research direction

Start at go/email-injection and trace how its source-to-sink flow handles values moved through custom structs, event fields, and notification helpers. Compare this with the described Forwarded/X-Forwarded-Host to password-reset-link path; done means the query covers the indirect flow and avoids the reported false negative.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.