opentelemetry-collector-contrib: githubreceiver silently ignores configured required_headers authentication
Description
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"The githubreceiver webhook handler never enforces the configured required_headers on incoming requests."
Attack vector
An attacker sends arbitrary HTTP requests to the githubreceiver webhook endpoint. Because `handleReq()` never enforces the configured `required_headers`, the operator's authentication mechanism is bypassed. Additionally, if the `Secret` field is empty (the default), `github.ValidatePayload` skips HMAC validation entirely, leaving no authentication at all. This allows the attacker to inject fake CI/CD trace data into the observability pipeline.
Affected code
The vulnerability is in `receiver/githubreceiver/trace_receiver.go` in the `handleReq()` function (lines 131-185), which never checks the `RequiredHeaders` field defined in `receiver/githubreceiver/config.go` (line 45) and validated at startup (lines 93-101). The `Secret` field also defaults to empty with no validation requiring it to be set, so HMAC validation is skipped entirely when secret is empty.
What the fix does
The fix must add `RequiredHeaders` enforcement inside `handleReq()`, matching the pattern already used by the gitlabreceiver at `receiver/gitlabreceiver/traces_receiver.go:266-270`. That code iterates over the configured required headers and rejects the request if any header is missing or does not match the expected value. Without this check, the configuration is validated at startup but never applied at runtime. The advisory also notes that the `Secret` field defaults to empty with no validation, so operators relying solely on `required_headers` without setting a secret have zero authentication.
Preconditions
- configThe operator must have configured required_headers (and optionally left Secret empty) in the githubreceiver configuration.
- networkThe attacker must be able to reach the githubreceiver webhook endpoint over the network.
- authNo authentication check is performed on incoming requests due to the missing enforcement.
Generated on Jun 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.