Grafana Alloy CVE-2026-75889

Exploitation requires a Kubernetes RBAC binding that grants the attacker create or update rights on ServiceMonitor custom resources (monitoring.coreos.com/servicemonitors) in at least one namespace actively watched by Alloy's prometheus.operator.servicemonitors component. This permission level is equivalent to a developer or namespace-admin role in many clusters, not an anonymous or unauthenticated position. The prometheus.operator.servicemonitors Alloy component must be explicitly configured and running - Alloy deployments that do not use this component are not affected. The attacker must also be able to specify or control a scrape endpoint (the target host in the ServiceMonitor) that they can observe incoming HTTP requests on, which requires either an internet-reachable server or an in-cluster service they control. Exploitation is bounded by: (1) the requirement for valid Kubernetes cluster credentials and namespace access, excluding purely external threat actors; (2) the need for ServiceMonitor write access specifically, which is not automatically granted with general namespace access; (3) the sensitivity of the stolen material being capped by Alloy's own service account RBAC rights, which vary by deployment.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N is well-calibrated for this vulnerability. The Scope:Changed flag is the most important signal: the exploitable namespace boundary is breached because the stolen service account token operates at the cluster level. Real-world risk is strongly conditioned on Alloy's own RBAC footprint - in many Grafana stack deployments Alloy holds cluster-wide read or even write rights, which makes the stolen token far more dangerous than the PR:L prerequisite implies. EPSS data is not available in the provided intelligence, so exploitation probability cannot be quantified numerically. No CISA KEV listing and no public POC are present, indicating no confirmed widespread exploitation at time of analysis; however, the attack surface is entirely accessible to any developer-level Kubernetes user granted ServiceMonitor write access, which is common in multi-tenant clusters with GitOps workflows. The primary limiting factor is that this vulnerability sits in a Kubernetes-native deployment context rather than being internet-facing in the traditional sense: a would-be attacker must already have Kubernetes API access and namespace-level RBAC rights, which meaningfully narrows the threat actor pool. Teams running Alloy with tightly scoped RBAC and namespace isolation face lower residual risk than those granting broad ServiceMonitor permissions to application developers.

An attacker with ServiceMonitor write access in a namespace watched by Alloy deploys a ServiceMonitor resource whose bearerTokenFile field points to /var/run/secrets/kubernetes.io/serviceaccount/token, with the scrape endpoint (targets field) set to an internet-accessible server the attacker controls. On Alloy's next reconciliation cycle - which occurs automatically - Alloy reads the service account token file and issues an HTTP scrape request to the attacker's server with Authorization: Bearer <token>, delivering Alloy's Kubernetes identity directly. The attacker then uses that token with kubectl or the Kubernetes REST API to impersonate Alloy's service account and interact with the Kubernetes API at whatever permission level Alloy holds, potentially reading secrets across all namespaces if Alloy has cluster-read RBAC.