OSV 1.4.0 · github-reviewed · 修改于 2026-06-18 23:05
发布时间
2026-06-18 23:05
GitHub 审查时间
2026-06-18 23:05
NVD 发布时间
—
源文件
advisories/github-reviewed/2026/06/GHSA-w5cv-pw74-4rxc/GHSA-w5cv-pw74-4rxc.json
The githubreceiver webhook handler does not enforce the required_headers configuration. Headers are validated at startup (config rejects empty keys/values) but never checked on incoming requests. This follows the same pattern as GHSA-prf6-xjxh-p698 (awsfirehosereceiver auth bypass). Verified against current main.
In receiver/githubreceiver/config.go, the RequiredHeaders field is defined (line 45) and validated at startup (lines 93-101). But receiver/githubreceiver/trace_receiver.go in handleReq() (lines 131-185) never references RequiredHeaders.
The gitlabreceiver enforces the same config correctly at receiver/gitlabreceiver/traces_receiver.go:266-270:
for key, value := range gtr.cfg.WebHook.RequiredHeaders {
if r.Header.Get(key) != string(value) {
return "", fmt.Errorf("%w: %s", errInvalidHeader, key)
}
}
The Secret field defaults to empty and has no validation requiring it to be set. With an empty secret, github.ValidatePayload skips HMAC validation entirely. An operator who configures required_headers as their authentication mechanism (without setting secret) has zero authentication on the webhook endpoint.
An attacker can send arbitrary webhook payloads to the githubreceiver endpoint, bypassing the operator configured authentication. This allows injecting fake CI/CD trace data into the observability pipeline.
Add RequiredHeaders enforcement to handleReq(), matching the gitlabreceiver pattern.