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.