## 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](https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/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.
## 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](https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/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.
Update github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver to 0.151.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanopentelemetry-collector-contrib: githubreceiver silently ignores configured required_headers authentication affects github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver (go). Severity is medium. ## 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](https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/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 coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceivergo | <=0.150.0 | 0.151.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver to 0.151.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanopentelemetry-collector-contrib: githubreceiver silently ignores configured required_headers authentication affects github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver (go). Severity is medium. ## 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](https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/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 coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceivergo | <=0.150.0 | 0.151.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard