CVE-2026-47701

In the OpenTelemetry Operator's Target Allocator, versions prior to 0.152.0 with targetAllocator.prometheusCR.enabled set to true preserve a selected ServiceMonitor endpoint's bearerTokenFile value as the Collector scrape client's Authorization CredentialsFile. A tenant who can create or update a ServiceMonitor matched by serviceMonitorSelector and serviceMonitorNamespaceSelector can point bearerTokenFile at any file readable in the Collector pod — including /var/run/secrets/kubernetes.io/serviceaccount/token — and direct scraping at an endpoint they control, causing the Collector to send that file's contents as a bearer token on every scrape interval. Successful exploitation discloses the Collector's service-account JWT or other mounted files, and the resulting Kubernetes API impact is bounded by the Collector service account's permissions; the missing DenyFSAccessThroughSMs control allowed this behavior. Deployments running the Target Allocator with Prometheus CR discovery on Operator versions before 0.152.0 are affected, and the issue is fixed in 0.152.0. No public proof of concept exists, the flaw is not in the CISA KEV catalog, and no active exploitation is known.

What to do: Upgrade the OpenTelemetry Operator (and its Target Allocator) to 0.152.0 or later, which introduces the DenyFSAccessThroughSMs control that blocks this behavior. Restrict RBAC so untrusted tenants cannot create or update ServiceMonitors matched by your serviceMonitorSelector/serviceMonitorNamespaceSelector, and audit existing ServiceMonitors for bearerTokenFile values pointing at sensitive pod paths. Reduce blast radius by scoping down the Collector service account's permissions and disabling automountServiceAccountToken where unnecessary, and rotate the Collector service-account token if any suspicious tenant-directed scrape targets are found.