CVE-2026-47701: 
Wolfi vulnerability analysis and mitigation

CVE-2026-47701 is a sensitive information disclosure vulnerability in the OpenTelemetry Operator for Kubernetes, specifically in the TargetAllocator component (cmd/otel-allocator). It allows a tenant with ServiceMonitor write access to exfiltrate the OpenTelemetry Collector pod's Kubernetes service account JWT and arbitrary files from the Collector's filesystem. All versions of github.com/open-telemetry/opentelemetry-operator prior to 0.152.0 are affected. The advisory was published on June 10, 2026, with a patch merged on May 20, 2026. It carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory, OTel Security Advisory).

The root cause is CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor): the TargetAllocator converts ServiceMonitor endpoint fields — including bearerTokenFile — directly into Prometheus scrape configuration entries (HTTPClientConfig.Authorization.CredentialsFile) without sanitizing or restricting filesystem paths. At scrape time, the OpenTelemetry Collector reads the specified file from its own pod filesystem and transmits its contents as an Authorization: Bearer header to the attacker-controlled scrape target. An attacker with ServiceMonitor create/update permissions in a namespace matched by the TargetAllocator's serviceMonitorSelector can set bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token, causing the Collector to exfiltrate its service account JWT on every scrape interval. The same technique can target any file readable by the Collector pod, including TLS certificates and other mounted secrets. The Prometheus Operator project previously addressed the same class of issue via the ArbitraryFSAccessThroughSMs.Deny guard, which the OpenTelemetry Operator lacked (GitHub Advisory, OTel Security Advisory).

Successful exploitation gives the attacker possession of the OpenTelemetry Collector pod's Kubernetes service account JWT, effectively granting them the same API permissions as the Collector's service account. In typical cluster monitoring deployments, this service account has list/get access to pods, nodes, endpoints, namespaces, and services cluster-wide — sufficient for broad reconnaissance and identification of further attack targets. Beyond the service account token, the attacker can read any file mounted in the Collector pod, including TLS certificates and additional secrets, enabling potential lateral movement within the cluster (OTel Security Advisory).

1. Identify a vulnerable deployment: Confirm the target cluster runs OpenTelemetry Operator < 0.152.0 with targetAllocator.prometheusCR.enabled: true and that the attacker has ServiceMonitor create/update rights in a namespace matched by serviceMonitorSelector or serviceMonitorNamespaceSelector.
2. Set up a controlled scrape target: Deploy or control an HTTP server (e.g., a simple listener on a reachable IP/port) that logs all incoming HTTP headers, particularly the Authorization header.
3. Craft a malicious ServiceMonitor: Create or update a ServiceMonitor resource in the targeted namespace with an endpoint pointing to the attacker-controlled server and bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token (or another sensitive file path such as a TLS certificate).
4. Wait for the scrape interval: The TargetAllocator picks up the ServiceMonitor, converts bearerTokenFile to HTTPClientConfig.Authorization.CredentialsFile, and distributes the scrape config to the Collector.
5. Collect the exfiltrated token: On the next scrape cycle, the Collector reads the specified file and sends its contents as Authorization: Bearer <token> to the attacker's server. The attacker captures the JWT from the logged request headers.
6. Abuse the stolen token: Use the captured service account JWT to authenticate to the Kubernetes API (kubectl --token=<jwt>) and enumerate cluster resources (pods, nodes, secrets, endpoints) or escalate privileges further (OTel Security Advisory, GitHub Advisory).

• Network: Outbound HTTP/HTTPS requests from the OpenTelemetry Collector pod to unexpected or external endpoints carrying an Authorization: Bearer header containing a Kubernetes service account JWT; scrape traffic to IPs/hostnames not in the legitimate monitoring target list.
• Kubernetes Resources: Presence of ServiceMonitor resources with bearerTokenFile set to sensitive paths (e.g., /var/run/secrets/kubernetes.io/serviceaccount/token, /etc/ssl/certs/, or other filesystem paths); ServiceMonitor resources created or modified by non-administrative tenants in monitored namespaces.
• Logs: OpenTelemetry Collector logs showing scrape attempts to unexpected targets; TargetAllocator logs reflecting newly added or modified ServiceMonitor endpoints referencing filesystem paths.
• Kubernetes Audit Logs: create or update events on ServiceMonitor resources by low-privileged service accounts, especially in namespaces matched by the TargetAllocator's selector configuration (OTel Security Advisory).

Upgrade github.com/open-telemetry/opentelemetry-operator to version 0.152.0 or later, which introduces the DenyFSAccessThroughSMs flag. When enabled, the TargetAllocator drops any ServiceMonitor or PodMonitor endpoints that reference arbitrary filesystem paths via bearerTokenFile, tlsConfig.caFile, tlsConfig.certFile, or tlsConfig.keyFile, while preserving other endpoints. As an interim workaround for unpatched deployments, restrict ServiceMonitor create/update RBAC permissions to trusted administrators only, and use serviceMonitorNamespaceSelector to limit the namespaces the TargetAllocator watches. Additionally, consider disabling service account token auto-mounting on the Collector pod if not required (GitHub Advisory, Fix PR #5104).