CVE-2026-75889 in Alloy
Summary
by MITRE • 08/27/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability in Grafana Alloy's prometheus.operator.servicemonitors component represents a critical authorization bypass that leverages improper input validation within the Prometheus Operator integration layer. This flaw allows an attacker with the ability to create or modify ServiceMonitor resources in any namespace watched by the specific Alloy instance to inject malicious configuration parameters. Specifically, the vulnerability centers on the bearerTokenFile field, which is intended for specifying paths to files containing authentication tokens for scraping targets. Due to insufficient sanitization of this input parameter, a user can specify arbitrary local file system paths rather than valid token locations. When Alloy processes these configurations, it attempts to read the contents of the specified path and uses them as bearer tokens when communicating with scrape endpoints controlled by the attacker.
From an operational perspective, this misconfiguration leads directly to sensitive information disclosure and potential full cluster compromise. By directing Alloy to read arbitrary files such as /etc/kubernetes/serviceaccount/token or other projected service account credentials stored within the pod's filesystem, the attacker can extract high-privilege Kubernetes API tokens. These extracted tokens are then utilized by the attacker to authenticate against the Kubernetes API server using the permissions associated with the Grafana Alloy process itself. Since this attack vector requires only ServiceMonitor write access and operates under lower privileges than the Alloy service account, it effectively escalates an attacker's standing from a limited namespace-level user to one capable of performing actions at the cluster level, including reading secrets, modifying deployments, or establishing persistent backdoors within the Kubernetes environment.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-732 Incorrect Permission Assignment for Critical Resource, as it stems from failing to restrict file access paths based on expected constraints and allowing untrusted input to influence critical security configurations. In terms of attack tactics, this scenario maps closely to the ATT&CK technique T1552 Unsecured Credentials, specifically involving discovery or acquisition of cloud credentials through local file system access. The exploitation path also reflects aspects of T1078 Valid Accounts, where legitimate service account tokens are stolen and repurposed for unauthorized access.
Mitigation strategies must focus on restricting the capabilities of ServiceMonitor creators to prevent them from influencing authentication mechanisms that rely on host-level resources. Administrators should enforce strict Role-Based Access Control policies that limit who can create or modify Prometheus Operator custom resource definitions, particularly those involving bearer token configurations. Additionally, implementing network policies and pod security standards can help isolate Grafana Alloy processes, ensuring they do not have unnecessary access to the node's file system where service account tokens are projected. Upgrading to patched versions of Grafana Alloy that enforce strict path validation for the bearerTokenFile parameter is essential, as these updates typically include safeguards against arbitrary file reads and ensure that only whitelisted or dynamically generated token sources are accepted.