Veille CVE

Recherche « Opentelemetry opentelemetry collector contrib »

4 CVE

Critique 0 Élevée 1 Moyenne 3 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « Opentelemetry opentelemetry collector contrib » ✕
  1. CVE-2026-55701 6.9 Moyenne

    open-telemetry opentelemetry-collector-contrib · open-telemetry github.com/open-telemetry/opentelemetry-collector-contrib/receiver/githubreceiver

    The OpenTelemetry Collector Contrib repository contains components for the OpenTelemetry Collector. Prior to 0.151.0, the githubreceiver validates the receiver/githubreceiver/config.go RequiredHeaders configuration at startup, but receiver/githubreceiver/trace_receiver.go handleReq() does not check those headers on incoming webhook requests. An unauthenticated sender can therefore bypass an operator's required_headers authentication control and submit arbitrary webhook payloads. When the Secret field is empty, github.ValidatePayload also skips HMAC validation, leaving the webhook endpoint without either configured authentication mechanism. Successful exploitation can inject fabricated CI/CD trace data into the observability pipeline. This issue is fixed in version 0.151.0.

  2. CVE-2026-47256 5.3 Moyenne

    open-telemetry opentelemetry-collector-contrib · open-telemetry github.com/open-telemetry/opentelemetry-collector-contrib/exporter/sentryexporter

    OpenTelemetry, also known as OTel, is a vendor-neutral open source Observability framework for instrumenting, generating, collecting, and exporting telemetry data such as traces, metrics, and logs. Prior to 0.154.0, the Sentry exporter reads the remote OTLP sender-controlled service.name resource attribute in exporter/sentryexporter/sentry_exporter.go through extractProjectSlug and getOrCreateProjectEndpoint, passes the raw project slug to GetOTLPEndpoints and GetProjectKeys in exporter/sentryexporter/sentry_client.go, and interpolates it into a Sentry API URL without applying projectSlugRegexp through validateRoutingConfig at runtime in exporter/sentryexporter/config.go. Special characters can turn the expected path suffix into query data in all deployments or introduce slash and dot segments that traverse paths when the Sentry deployment normalizes them, while the Collector attaches its operator-configured bearer token to the request. A successful request can reach token-authorized administrative, organization, member, or key endpoints within the configured Sentry organization, and an attacker-controlled project slug can redirect subsequently exported telemetry. Sentry token middleware prevents cross-organization access. This issue is fixed in version 0.154.0.

  3. CVE-2026-42602 8.1 Élevée

    open-telemetry opentelemetry-collector-contrib · Opentelemetry opentelemetry collector contrib

    azureauthextension is the Azure Authenticator Extension. From 0.124.0 to 0.150.0, a server-side authentication bypass in azureauthextension allows any party who holds a single valid Azure access token for any scope the collector's configured identity can mint for to authenticate to any OpenTelemetry receiver that uses auth: azure_auth. The extension's Authenticate method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality — and the scope for that server-side token request is taken from the client-supplied Host header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching Host. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens).

  4. CVE-2026-41484 5.9 Moyenne

    open-telemetry opentelemetry-dotnet-contrib · Opentelemetry opentelemetry.exporter.onecollector

    OpenTelemetry.Exporter.OneCollector is a .NET exporter that sends telemetry to a OneCollector back-end over HTTP. In versions 1.15.0 and earlier, when a request to the configured back-end or collector results in an unsuccessful HTTP 4xx or 5xx response, the HttpJsonPostTransport class reads the entire response body into memory with no upper bound on the number of bytes consumed in order to include the error response in operator logs. An attacker who controls the configured endpoint, or who can intercept traffic to it via a man-in-the-middle attack, can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. As a workaround, use network-level controls such as firewall rules, mTLS, or a service mesh to prevent man-in-the-middle attacks on the configured back-end or collector endpoint. This issue is fixed in version 1.15.1, which limits the number of bytes read from the response body in an error condition to 4 MiB.