PT-2026-50743 · Go · Github.Com/Open-Telemetry/Opentelemetry-Collector-Contrib/Receiver/Githubreceiver
Published
2026-06-18
·
Updated
2026-06-18
·
CVE-2026-55701
CVSS v4.0
6.9
Medium
| Vector | AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N |
githubreceiver Silently Ignores Configured required headers Authentication
Summary
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.Details
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)
}
}
Amplifying factor
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.Impact
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.
Suggested Fix
Add RequiredHeaders enforcement to
handleReq(), matching the gitlabreceiver pattern.Fix
Incorrect Authorization
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Github.Com/Open-Telemetry/Opentelemetry-Collector-Contrib/Receiver/Githubreceiver