Grafana Alloy’s prometheus.operator.servicemonitors component permits a user who can create or modify ServiceMonitor resources in a watched namespace to specify an arbitrary local file path using the bearerTokenFile field. The component then reads the file and forwards its contents as a bearer token to the designated scrape endpoint. This behavior can expose any file readable by the Alloy process, including the projected Kubernetes service account token, thereby giving the attacker the same Kubernetes permissions as the Alloy service account. The flaw results in potential data leakage and an opportunity for privilege escalation within the cluster.

The vulnerability affects all Grafana Alloy instances that include the prometheus.operator.servicemonitors component, regardless of release version. Any configuration that allows users to create or modify ServiceMonitor objects in a namespace that Alloy watches is at risk. Attackers only need write access to ServiceMonitor resources in such a namespace; this permission scope is often lower than the privileges of the Alloy service account, making many cluster roles susceptible.

The CVSS score of 7.7 indicates high severity, while the EPSS score of < 1% shows a very low probability of exploitation in the wild. The vulnerability is not listed in the CISA KEV catalog. The attack requires internal cluster access to create or edit a ServiceMonitor in a namespace monitored by Alloy; once the attacker’s ServiceMonitor is processed, the arbitrary file content is sent to the target scrape endpoint. This can lead to exfiltration of sensitive files and escalation to the Alloy service account’s Kubernetes roles.