OpenTelemetry Operator CVE-2026-47701
HIGHSeverity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
Affected
Repository: github.com/open-telemetry/opentelemetry-operator Component: cmd/otel-allocator (TargetAllocator) Companion: Prometheus Operator API types (CRDs)
Summary
OpenTelemetry Operator's TargetAllocator watches ServiceMonitor resources via the Prometheus Operator CR watcher and converts each selected endpoint into a Prometheus scrape configuration entry. The endpoint field bearerTokenFile is preserved through the conversion as HTTPClientConfig.Authorization.CredentialsFile. The OpenTelemetry Collector, configured with the Prometheus receiver, then loads that scrape config and, at scrape time, reads the file from its own pod filesystem and sends the contents as Authorization: Bearer ... to the scrape endpoint.
A tenant who can create or update a ServiceMonitor selected by TargetAllocator can set bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token and a scrape target the tenant controls. The Collector then ships its mounted service account JWT to that target on every scrape interval.
The Prometheus Operator project addressed the same primitive via the ArbitraryFSAccessThroughSMs.Deny admission/runtime guard.
Preconditions
The OpenTelemetry Collector needs to be deployed with targetAllocator.prometheusCR.enabled: true and serviceMonitorSelector / serviceMonitorNamespaceSelector matching at least one namespace where the attacker can create or update ServiceMonitor (or paired with a TargetAllocator resource with the same respective settings). The Collector pod needs to have its service account token mounted. The Collector needs to be able to reach the scrape target chosen by the attacker.
Impact
Tenant ServiceMonitor write becomes equivalent to the OpenTelemetry Collector pod's service account against the Kubernetes API. Real impact depends on what the Collector service account is granted in a given deployment. Typical cluster monitoring setups grant pod, node, endpoint, namespace, and service list across the cluster, which is enough to enumerate and identify further targets. The same primitive can read any file the Collector pod has on disk including mounted certificates and other tokens.
Fix
https://github.com/open-telemetry/opentelemetry-operator/pull/5104 adds support to disable service and podmonitor endpoints that read arbitrary files. 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.
Articles & Coverage 1
AnalysisAI
Service account token disclosure in OpenTelemetry Operator's TargetAllocator (versions prior to 0.152.0) allows a tenant with ServiceMonitor write permissions in a watched namespace to exfiltrate the OpenTelemetry Collector pod's mounted Kubernetes service account JWT or any other file on the Collector's filesystem. By setting the bearerTokenFile field on a ServiceMonitor to an arbitrary path (such as /var/run/secrets/kubernetes.io/serviceaccount/token) and pointing the scrape target to an attacker-controlled endpoint, the Collector reads the file and ships its contents as an Authorization: Bearer header on every scrape interval. No public exploit is identified at the time of analysis, though the technique mirrors a well-known Prometheus Operator primitive (ArbitraryFSAccessThroughSMs).
Technical ContextAI
The OpenTelemetry Operator's TargetAllocator (cmd/otel-allocator) watches Prometheus Operator CRDs - specifically ServiceMonitor and PodMonitor resources - and translates each selected endpoint into a Prometheus scrape configuration entry consumed by the Collector's Prometheus receiver. During this conversion, the endpoint's bearerTokenFile field is faithfully preserved as HTTPClientConfig.Authorization.CredentialsFile, and at scrape time the Collector pod (not the tenant) opens that path on its own filesystem and transmits the contents as a bearer token. The root cause aligns with CWE-200 (Exposure of Sensitive Information): the operator treats the file path as trusted scrape config when it is actually attacker-controlled tenant input crossing a trust boundary. The affected Go module is github.com/open-telemetry/opentelemetry-operator (pkg:go/github.com_open-telemetry_opentelemetry-operator), and the Prometheus Operator project mitigated the equivalent primitive years ago via the ArbitraryFSAccessThroughSMs.Deny guard, which this fix ports as DenyFSAccessThroughSMs.
RemediationAI
Vendor-released patch: upgrade the OpenTelemetry Operator to version 0.152.0 or later, which introduces the DenyFSAccessThroughSMs field on both v1alpha1 OpenTelemetryCollector and v1beta1 TargetAllocator CRDs (see https://github.com/open-telemetry/opentelemetry-operator/pull/5104) - set targetAllocator.prometheusCR.denyFSAccessThroughSMs: true (mirroring Prometheus Operator's ArbitraryFSAccessThroughSMs.Deny) so the TargetAllocator drops any ServiceMonitor or PodMonitor endpoint referencing bearerTokenFile, tlsConfig.caFile, tlsConfig.certFile, or tlsConfig.keyFile while preserving the remaining endpoints. If immediate upgrade is not possible, narrow serviceMonitorSelector and serviceMonitorNamespaceSelector so that only operator-controlled namespaces (no tenant write access) are matched - trade-off: tenants lose self-service scrape configuration. Alternatively, restrict ServiceMonitor/PodMonitor create/update RBAC permissions to trusted operators only via Kubernetes RBAC or an admission controller (OPA/Kyverno) that rejects bearerTokenFile/tlsConfig.*File fields on tenant-submitted resources - trade-off: requires policy maintenance and may break legitimate workflows. As a defense-in-depth step, audit and minimize the Collector ServiceAccount's RBAC to the least privilege required for its receivers, since the bearer token disclosed by this flaw inherits exactly those rights. Full advisory and patch details: https://github.com/open-telemetry/opentelemetry-operator/security/advisories/GHSA-cxh2-4639-vmc5.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Kamaji is the Hosted Control Plane Manager for Kubernetes. Rated critical severity (CVSS 9.9), this vulnerability is rem
Jumpserver is a popular open source bastion host, and Koko is a Jumpserver component that is the Go version of coco, ref
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-cxh2-4639-vmc5