Description

The OpenTelemetry Operator is a Kubernetes Operator for the OpenTelemetry Collector. Prior to 0.152.0, cmd/otel-allocator TargetAllocator instances with targetAllocator.prometheusCR.enabled set to true preserve a selected ServiceMonitor endpoint's bearerTokenFile value as HTTPClientConfig.Authorization.CredentialsFile. A tenant who can create or update a ServiceMonitor matched by serviceMonitorSelector and serviceMonitorNamespaceSelector can point bearerTokenFile at a file in the Collector pod, including /var/run/secrets/kubernetes.io/serviceaccount/token, and direct scraping to a tenant-controlled endpoint. The Collector reads that file at scrape time and sends its contents as bearer authorization on every scrape interval. Exploitation also requires the Collector service-account token or another sensitive file to be mounted and the Collector to reach the chosen target. The DenyFSAccessThroughSMs control was absent, allowing disclosure of the Collector's service-account JWT or other mounted files, and resulting Kubernetes API impact is limited by the Collector service account's permissions. This issue is fixed in version 0.152.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-14T16:17:11.540Z",
  "pubdate": "2026-09-14T16:17:11.540Z",
  "executiveSummary": "The OpenTelemetry Operator, specifically the cmd/otel-allocator component, is susceptible to an arbitrary file disclosure vulnerability. The vulnerability arises from insecure handling of bearerTokenFile configurations within ServiceMonitor objects when prometheusCR.enabled is set to true.\nBy manipulating the bearerTokenFile parameter, a tenant with permissions to create or update ServiceMonitor objects can force the OpenTelemetry Collector to read sensitive files from the container's filesystem—including the Kubernetes service account token located at /var/run/secrets/kubernetes.io/serviceaccount/token—and transmit the contents to an attacker-controlled endpoint via HTTP Authorization headers.\nThis vulnerability allows unauthorized disclosure of sensitive credentials mounted within the Collector pod. The potential impact is limited by the RBAC permissions assigned to the Collector's service account. Exploitation requires the attacker to have the ability to create or modify ServiceMonitor resources matched by the allocator's selectors and ensures the Collector has network reachability to the attacker's designated target endpoint.\nThis issue affects all versions prior to 0.152.0. Upgrading to version 0.152.0 or later is necessary to introduce the DenyFSAccessThroughSMs control and mitigate the improper file access path.",
  "technicalDetails": "The vulnerability originates in the cmd/otel-allocator component of the OpenTelemetry Operator when the prometheusCR.enabled configuration is active. The allocator logic fails to validate or sanitize the bearerTokenFile field provided within ServiceMonitor custom resources. Specifically, the allocator passes the user-provided file path directly into the HTTPClientConfig.Authorization.CredentialsFile field used by the Prometheus scraping configuration.\nThe attack flow proceeds as follows: First, an attacker with authorization to manage ServiceMonitor resources creates or updates a ServiceMonitor that satisfies the serviceMonitorSelector and serviceMonitorNamespaceSelector criteria defined in the TargetAllocator configuration. Second, the attacker sets the bearerTokenFile field to an arbitrary sensitive file path existing within the Collector pod's filesystem, such as '/var/run/secrets/kubernetes.io/serviceaccount/token'. Third, the TargetAllocator synchronizes this configuration into the OpenTelemetry Collector's scraping targets. Finally, when the Collector performs a scrape operation against the attacker-specified endpoint, it reads the contents of the defined file and injects the raw data into the 'Authorization: Bearer <token>' HTTP header of the outgoing request.\nBecause the collector is responsible for the scrape, it inherently possesses the necessary filesystem permissions to access mounted secrets. The absence of the DenyFSAccessThroughSMs mechanism in versions prior to 0.152.0 meant there was no validation logic to prevent users from pointing the bearer token configuration to paths outside of expected credential directories.\nPost-exploitation, the attacker captures the contents of the sensitive file by listening on the destination endpoint. The impact is primarily the exfiltration of the Kubernetes service account JWT. If the Collector's service account possesses elevated privileges within the cluster, the attacker can leverage the disclosed token to impersonate the Collector and interact with the Kubernetes API server, potentially leading to privilege escalation or unauthorized cluster access depending on the configured RBAC roles. The vulnerability is effectively a Server-Side Request Forgery (SSRF) variant combined with an arbitrary local file read, triggered via legitimate monitoring configuration channels."
}