Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
#21,770 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
go
Domínio
security

Direção de pesquisa

Comece em go/email-injection e rastreie como seu fluxo de source a sink lida com valores movidos por meio de structs personalizados, campos de eventos e helpers de notificação. Compare isso com o caminho descrito de Forwarded/X-Forwarded-Host até password-reset-link; considera-se concluído quando a consulta cobre o fluxo indireto e evita o falso negativo relatado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
CodeQL
Estrelas
10.1k
Forks
2.1k
Merge médio
2d 16h
PRs com merge (30d)
143

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/codeql

Todas as issues de github/codeql

Issues semelhantes

Mais issues de Security

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.