CVE-2026-47701: OpenTelemetry Operator Information Disclosure

CVE-2026-47701 Overview

CVE-2026-47701 affects the OpenTelemetry Operator, a Kubernetes Operator for the OpenTelemetry Collector. Versions prior to 0.152.0 preserve a ServiceMonitor endpoint's bearerTokenFile value when targetAllocator.prometheusCR.enabled is set to true. A tenant who can create or update a matched ServiceMonitor can point bearerTokenFile at any file inside the Collector pod, including /var/run/secrets/kubernetes.io/serviceaccount/token, and redirect scraping to a tenant-controlled endpoint. The Collector reads that file every scrape interval and transmits its contents as bearer authorization. The vulnerability is tracked under [CWE-200] Information Exposure and fixed in version 0.152.0.

Critical Impact
Tenants with ServiceMonitor create or update privileges can exfiltrate the Collector's service account JWT, enabling subsequent Kubernetes API abuse bounded by that account's RBAC permissions.

Affected Products

OpenTelemetry Operator cmd/otel-allocator (TargetAllocator) prior to 0.152.0
Deployments with targetAllocator.prometheusCR.enabled set to true
Collector pods mounting service account tokens or other sensitive files

Discovery Timeline

2026-09-14 - CVE-2026-47701 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-47701

Vulnerability Analysis

The TargetAllocator component of the OpenTelemetry Operator translates Prometheus Operator Custom Resources (ServiceMonitor and PodMonitor) into scrape configurations for the Collector. When prometheusCR.enabled is true, the allocator preserves the bearerTokenFile field from a selected ServiceMonitor endpoint and passes it into the Collector's HTTPClientConfig.Authorization.CredentialsFile.

At every scrape interval, the Collector reads the referenced file and sends its contents in the Authorization: Bearer header of the outbound HTTP request. Because the allocator did not enforce an equivalent of the Prometheus Operator's ArbitraryFSAccessThroughSMs.Deny control, tenants could reference arbitrary paths inside the Collector filesystem.

Root Cause

The root cause is the absence of a DenyFSAccessThroughSMs toggle. The allocator accepted any file path submitted through bearerTokenFile, tlsConfig.caFile, tlsConfig.certFile, or tlsConfig.keyFile without validating that the path belonged to a tenant-owned secret. The Collector service account token at /var/run/secrets/kubernetes.io/serviceaccount/token is the highest-value target, but any mounted secret is reachable.

Attack Vector

Exploitation requires a tenant with permissions to create or update a ServiceMonitor matched by serviceMonitorSelector and serviceMonitorNamespaceSelector. The attacker sets bearerTokenFile to the Collector's service account token path and configures the endpoint to point at an attacker-controlled HTTP server. The Collector then submits the JWT to that server on the next scrape. Kubernetes API impact after token capture is limited by the Collector service account's RBAC.

// Security patch in apis/v1beta1/targetallocator_types.go
// DenyFSAccessThroughSMs causes the Target Allocator to drop ServiceMonitor and
// PodMonitor endpoints that reference arbitrary files on the file system. When
// enabled, endpoints with bearerTokenFile, tlsConfig.caFile, tlsConfig.certFile,
// or tlsConfig.keyFile are dropped from the produced scrape configuration while
// the remaining endpoints are kept. This prevents tenants from stealing the
// Collector's service account token via ServiceMonitor bearerTokenFile
// references. This is the equivalent of ArbitraryFSAccessThroughSMs.Deny from
// the Prometheus Operator.
// +optional
DenyFSAccessThroughSMs bool `json:"denyFSAccessThroughSMs,omitempty"`

Source: GitHub Commit 95a8c2a3

Detection Methods for CVE-2026-47701

Indicators of Compromise

ServiceMonitor or PodMonitor resources containing bearerTokenFile values pointing to paths under /var/run/secrets/ or other Collector-mounted directories.
Outbound HTTP requests from Collector pods to unexpected external endpoints carrying an Authorization: Bearer header.
Kubernetes API audit entries showing the Collector service account authenticating from unusual source IPs or performing unexpected actions.

Detection Strategies

Inspect all ServiceMonitor and PodMonitor manifests admitted into namespaces selected by the TargetAllocator and flag any bearerTokenFile, tlsConfig.caFile, tlsConfig.certFile, or tlsConfig.keyFile entries.
Deploy an admission controller policy (OPA Gatekeeper or Kyverno) that rejects tenant-authored monitors referencing filesystem paths outside approved tenant secrets.
Correlate Collector egress traffic with declared scrape targets to identify redirection to tenant-controlled endpoints.

Monitoring Recommendations

Enable Kubernetes audit logging for ServiceMonitor and PodMonitor create and update operations and alert on bearerTokenFile fields.
Monitor Collector pod network flows for connections to destinations not present in the operator-managed scrape configuration.
Track service account token usage through Kubernetes API audit logs and alert on activity originating outside the Collector pod network range.

How to Mitigate CVE-2026-47701

Immediate Actions Required

Upgrade the OpenTelemetry Operator to version 0.152.0 or later.
Enable the new denyFSAccessThroughSMs field on affected OpenTelemetryCollector and TargetAllocator resources.
Rotate the Collector service account token and any other secrets mounted into Collector pods if exposure is suspected.
Review RBAC bindings on the Collector service account and reduce permissions to the minimum required.

Patch Information

The fix is delivered in GitHub Release v0.152.0 via Pull Request #5104. The patch introduces a DenyFSAccessThroughSMs boolean on both apis/v1alpha1/opentelemetrycollector_types.go and apis/v1beta1/targetallocator_types.go. When enabled, the TargetAllocator drops any ServiceMonitor or PodMonitor endpoint that references filesystem paths through bearerTokenFile, tlsConfig.caFile, tlsConfig.certFile, or tlsConfig.keyFile. See GHSA-cxh2-4639-vmc5 for the full advisory.

Workarounds

Restrict tenant RBAC so untrusted users cannot create or update ServiceMonitor or PodMonitor resources in namespaces matched by the allocator selectors.
Narrow serviceMonitorSelector and serviceMonitorNamespaceSelector to only trusted namespaces until the operator is upgraded.
Remove the automatic mount of the Collector service account token with automountServiceAccountToken: false where the token is not required.

bash

# Enable DenyFSAccessThroughSMs after upgrading to 0.152.0
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: otel
spec:
  targetAllocator:
    enabled: true
    prometheusCR:
      enabled: true
    denyFSAccessThroughSMs: true