CVE-2026-55701
CVE-2026-55701 is a CWE-863 vulnerability in github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver. O3 Security confirms whether CVE-2026-55701 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
opentelemetry-collector-contrib: githubreceiver silently ignores configured required_headers authentication
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 CVE-2026-55701 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-55701 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-55701. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-55701 in your dependencies?
O3 detects CVE-2026-55701 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.