CVE-2026-119566: 
Grafana vulnerability analysis and mitigation

CVE-2026-119566 is a credential leak vulnerability in Prometheus through version 3.15.1 that allows attackers to capture Azure AD or Google IAM bearer tokens by redirecting remote_write requests to an attacker-controlled host. When FollowRedirects is enabled, Prometheus's HTTP client forwards Authorization headers (including bearer tokens) to cross-host redirect targets without stripping credentials, enabling token theft and replay. The vulnerability was disclosed on October 30, 2026, and affects all Prometheus versions up to and including 3.15.1. It carries a CVSS v3.1 score of 4.8 (Medium) and a CVSS v4.0 score of 6.3 (Medium) (Github Advisory, VulnCheck).

The root cause is classified as CWE-522 (Insufficiently Protected Credentials). When Prometheus is configured with FollowRedirects: true for remote_write, its HTTP client — including the azureADRoundTripper in storage/remote/azuread/azuread.go (lines 326–333) and the write client in storage/remote/client.go (lines 205–216) — attaches bearer tokens (Azure AD or Google IAM) to outgoing requests without checking whether a redirect crosses host boundaries (Prometheus azuread.go, Prometheus client.go). An attacker controlling the configured remote-write endpoint or a man-in-the-middle position can return an HTTP 3xx redirect to an attacker-controlled host; Prometheus will follow the redirect and include the Authorization: Bearer <token> header in the redirected request, exposing the token. The fix, implemented in prometheus/common PR #901, detects cross-host redirects via isCrossHostRedirect() and strips credentials before forwarding the request (prometheus/common PR #901).

Successful exploitation allows an unauthenticated attacker to capture valid Azure AD or Google IAM bearer tokens from a Prometheus instance configured for cloud-authenticated remote_write. The stolen tokens can be replayed to write arbitrary metrics to the victim's monitoring backend (e.g., Azure Monitor, Google Cloud Monitoring), potentially corrupting observability data or masking malicious activity. While availability is not directly impacted, the confidentiality of cloud authentication credentials is compromised, and the integrity of the victim's metrics backend may be undermined through unauthorized writes (Github Advisory, VulnCheck).

No public proof-of-concept exploit code has been identified, and there is no evidence of active in-the-wild exploitation as of the disclosure date (VulnCheck). The EPSS score is 0.0, reflecting a currently low probability of exploitation in the near term (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity — the attacker must control the remote-write endpoint or be positioned to intercept and redirect HTTP traffic — and no privileges are required (Github Advisory).

1. Reconnaissance: Identify Prometheus instances configured with remote_write using Azure AD or Google IAM authentication and follow_redirects: true (the default). This can be done by scanning for exposed Prometheus configuration endpoints or /api/v1/status/config.
2. Position for redirect: Gain control of the configured remote_write URL endpoint (e.g., by compromising the target server, DNS hijacking, or BGP hijacking) or set up a server at a domain that the legitimate endpoint redirects to.
3. Return a 3xx redirect: When Prometheus sends a remote_write POST request with an Authorization: Bearer <token> header, respond with an HTTP 301/302/307 redirect pointing to an attacker-controlled host on a different domain.
4. Capture the bearer token: Prometheus follows the redirect and re-sends the request — including the Authorization header — to the attacker's host. Log the incoming request headers to extract the Azure AD or Google IAM bearer token.
5. Replay the token: Use the captured bearer token to authenticate against the victim's cloud monitoring backend (e.g., Azure Monitor Ingestion API or Google Cloud Monitoring API) and write arbitrary metrics, potentially corrupting dashboards or masking alerts (Github Advisory, prometheus/common PR #901).

• Network: Unexpected outbound HTTP POST requests from the Prometheus server to hosts not matching the configured remote_write URL, particularly following 3xx redirect responses; HTTP requests to cloud monitoring ingestion APIs (e.g., monitor.azure.com, monitoring.googleapis.com) originating from unexpected source IPs.
• Logs: Prometheus logs showing HTTP redirect responses (301/302/307) from the remote_write endpoint to a different host; access logs on the attacker-controlled server showing incoming POST requests with Authorization: Bearer headers from the Prometheus server's IP.
• Configuration: Prometheus configuration with follow_redirects: true (default) combined with azuread or google_iam authentication blocks in remote_write sections — this combination is the prerequisite for exploitation.

Upgrade prometheus/common to v0.69.0 or later, which contains the fix that strips credentials on cross-host redirects (PR #901); a patched Prometheus release incorporating this dependency update should be used (prometheus/common PR #901, Github Advisory). As an immediate workaround, set follow_redirects: false in the remote_write configuration to prevent Prometheus from following any redirects. Additionally, restrict remote_write endpoints to trusted, verified hosts using network egress controls, and implement monitoring for unexpected redirect responses in remote-write traffic (VulnCheck).

The fix was developed by Prometheus maintainer Julien Pivotto (roidelapluie) and reviewed and approved by Prometheus core maintainer bwplotka, indicating prompt internal response from the Prometheus project (prometheus/common PR #901). The vulnerability was assigned and disclosed by VulnCheck, and the issue was also noted in the Go vulnerability database (golang/vulndb#6887), suggesting broader ecosystem awareness. No significant public social media discussion or media coverage has been identified at this time.