github / github/codeql

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

Đang mở
#21,770 1 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
CodeQL
Star
10.1k
Fork
2.1k
Merge trung bình
2 ngày 15 giờ
Pull request đã merge (30 ngày)
141

Mô tả

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.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

Bắt đầu tại go/email-injection và lần theo cách luồng từ source đến sink của nó xử lý các giá trị được truyền qua các struct tùy chỉnh, các trường sự kiện và các helper thông báo. So sánh điều này với đường đi được mô tả từ Forwarded/X-Forwarded-Host đến password-reset-link; được xem là hoàn tất khi query bao quát luồng gián tiếp và tránh false negative đã được báo cáo.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
go
Lĩnh vực
security
Loại issue
Lỗi
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
45/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.