Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable webhook, no auth or interaction required; high integrity impact from pipeline data injection, no confidentiality loss, limited availability impact.
Primary rating from Vendor (https://github.com/open-telemetry/opentelemetry-collector-contrib).
CVSS VectorVendor: https://github.com/open-telemetry/opentelemetry-collector-contrib
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Authentication bypass in the githubreceiver component of opentelemetry-collector-contrib (versions ≤ 0.150.0) allows unauthenticated attackers to inject arbitrary webhook payloads into the OpenTelemetry observability pipeline. The required_headers configuration field is validated at startup but never enforced by handleReq() at request time, meaning any HTTP POST to the webhook endpoint is accepted regardless of header values. The risk is compounded when the Secret field is left at its empty default, which causes github.ValidatePayload to skip HMAC verification entirely - leaving deployments that rely solely on required_headers for auth with zero effective authentication. No public exploit code exists at time of analysis, but the advisory provides sufficient implementation detail to trivially reproduce the bypass.
Technical ContextAI
The githubreceiver is a Go module within the OpenTelemetry Collector Contrib project (CPE: pkg:go/github.com_open-telemetry_opentelemetry-collector-contrib_receiver_githubreceiver) that ingests GitHub webhook events and converts them into OpenTelemetry trace spans. The root cause is CWE-863 (Incorrect Authorization): the RequiredHeaders configuration field is defined in receiver/githubreceiver/config.go (line 45) and syntactically validated at startup (lines 93-101 reject empty keys/values), but the HTTP request handler handleReq() in receiver/githubreceiver/trace_receiver.go (lines 131-185) contains no reference to RequiredHeaders whatsoever. The sibling gitlabreceiver component implements the same feature correctly with an explicit header-comparison loop at receiver/gitlabreceiver/traces_receiver.go:266-270. This is structurally identical to GHSA-prf6-xjxh-p698 (awsfirehosereceiver auth bypass), which affected the same project. The secondary amplifying factor is that the Go github.ValidatePayload function, used for HMAC-SHA256 signature verification, silently skips validation when the secret is an empty string - matching the Secret field's default value.
RemediationAI
Upgrade opentelemetry-collector-contrib to version 0.151.0 or later, which adds required_headers enforcement inside handleReq() matching the gitlabreceiver implementation pattern documented in the advisory at https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/GHSA-w5cv-pw74-4rxc. If an immediate upgrade is not possible, configure a non-empty Secret value in the githubreceiver config and ensure the corresponding GitHub webhook delivery is signed with the same secret; this re-enables HMAC-SHA256 validation via github.ValidatePayload as a compensating authentication layer independent of the broken required_headers path - note this requires updating the GitHub repository webhook settings to include the secret. As an additional network-layer control, restrict the webhook endpoint to GitHub's published webhook source IP ranges (available at https://api.github.com/meta under the hooks key) via firewall rules or reverse proxy allowlisting; this limits the attack surface to GitHub infrastructure but does not address the auth bypass itself. Do not treat required_headers as providing any authentication protection until version 0.151.0 is deployed.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-78778
GHSA-w5cv-pw74-4rxc