Description

Grafana Alloy’s prometheus.operator.servicemonitors component allows a user who can create or modify ServiceMonitor resources in a watched namespace to specify an arbitrary local file through bearerTokenFile. Alloy reads the file and sends its contents as a bearer token to an attacker-controlled scrape endpoint. This may disclose files accessible to the Alloy process, including its projected Kubernetes service account token, potentially granting the attacker Alloy’s Kubernetes permissions. Exploitation requires ServiceMonitor write access and lower privileges than Alloy’s service account.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-08-27T20:18:37.980Z",
  "pubdate": "2026-08-27T20:18:37.980Z",
  "executiveSummary": "Grafana Alloy's prometheus.operator.servicemonitors component is susceptible to an arbitrary file disclosure vulnerability. The issue arises from insufficient validation of the bearerTokenFile configuration parameter, which allows an attacker to direct the Alloy process to read sensitive local files and exfiltrate their contents to an external, attacker-controlled endpoint.\nThe vulnerability type is an Arbitrary File Read, which can be leveraged to compromise sensitive system information, including Kubernetes service account tokens. The impact is significant, as successful exploitation may permit an attacker to escalate privileges by assuming the identity and permissions of the Alloy service account within the Kubernetes cluster.\nAffected systems include deployments of Grafana Alloy utilizing the prometheus.operator.servicemonitors component. Exploitation requires an attacker to possess the capability to create or modify ServiceMonitor resources within a namespace monitored by the Alloy instance. This necessitates lower privileges than those held by the Alloy service account itself, making this a viable privilege escalation vector for authenticated cluster users with namespace-scoped write permissions.",
  "technicalDetails": "The vulnerability resides within the prometheus.operator.servicemonitors component of Grafana Alloy. This component is designed to integrate with the Prometheus Operator by dynamically discovering and scraping targets defined in Kubernetes ServiceMonitor resources. A critical configuration option within these resources is the 'bearerTokenFile' field, intended to provide a path to a file containing a bearer token for authentication purposes when querying target endpoints.\nThe root cause is an improper validation of the file path provided via 'bearerTokenFile'. The Alloy process, which operates with its own filesystem permissions and service account identity, does not enforce restrictions on the file paths that may be referenced. Consequently, if a user with sufficient permissions to modify ServiceMonitor resources points this field to an arbitrary path on the local filesystem, the Alloy component will open the referenced file, read its contents, and include them in the Authorization header of HTTP requests dispatched to a user-specified scrape target.\nThe attack flow follows a structured sequence: First, the attacker identifies a namespace monitored by Grafana Alloy. Second, the attacker defines or modifies a ServiceMonitor resource to include an arbitrary 'bearerTokenFile' path (e.g., '/var/run/secrets/kubernetes.io/serviceaccount/token') and sets the scrape endpoint to an attacker-controlled listener. Third, upon discovery, the Alloy controller reads the specified file, treating the content as a bearer token. Finally, Alloy transmits this content over the network to the attacker's endpoint. By intercepting this request, the attacker gains access to the contents of the read file.\nThe post-exploitation impact is severe. If the attacker targets the Kubernetes service account token currently assigned to the Alloy process, they gain the ability to authenticate as the Alloy service account. This bypasses existing RBAC constraints, allowing the attacker to interact with the Kubernetes API server with the elevated permissions granted to the Alloy instance. This facilitates unauthorized access to cluster resources, secret extraction, or other malicious actions depending on the specific permissions assigned to the Alloy service account."
}