Skip to main content

githubreceiver CVE-2026-55701

| EUVDEUVD-2026-78778 MEDIUM
Incorrect Authorization (CWE-863)
2026-06-18 https://github.com/open-telemetry/opentelemetry-collector-contrib GHSA-w5cv-pw74-4rxc
6.9
CVSS 4.0 · Vendor: https://github.com/open-telemetry/opentelemetry-collector-contrib
Share

Severity by source

Vendor (https://github.com/open-telemetry/opentelemetry-collector-contrib) PRIMARY
6.9 MEDIUM
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
vuln.today AI
8.2 HIGH

Network-reachable webhook, no auth or interaction required; high integrity impact from pipeline data injection, no confidentiality loss, limited availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/open-telemetry/opentelemetry-collector-contrib).

CVSS VectorVendor: https://github.com/open-telemetry/opentelemetry-collector-contrib

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

3
CVSS changed
Sep 15, 2026 - 16:22 NVD
6.9 (MEDIUM)
Source Code Evidence Fetched
Jun 18, 2026 - 16:03 vuln.today
Analysis Generated
Jun 18, 2026 - 16:03 vuln.today

DescriptionCVE.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.

Vendor 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

Share

CVE-2026-55701 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy