opentelemetry-collector-contrib: githubreceiver silently ignores configured required_headers authenticationGHSA-w5cv-pw74-4rxc
GHSA-w5cv-pw74-4rxc is a CWE-863 vulnerability in github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver. A fix is available for github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w5cv-pw74-4rxc.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver | all versions | 0.151.0go get github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver@v0.151.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver to 0.151.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w5cv-pw74-4rxc is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
To prevent unauthorized data injection, configure the `githubreceiver` with a robust secret for HMAC validation. Ensure that the `Secret` field is never left empty in the `githubreceiver` configuration. If the `githubreceiver` is not essential for your deployment, disable or remove the component to eliminate this attack vector. A restart of the OpenTelemetry Collector may be required for configuration changes to take effect.Source: Red Hat security advisory for GHSA-w5cv-pw74-4rxc (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | opentelemetry-collector-contrib-main-0.160.0-0.1.hum1 | RHSA-2026:63152 |
Frequently Asked Questions
Is GHSA-w5cv-pw74-4rxc in your dependencies?
Find it across Go, including transitive dependencies.