Prometheus CVE-2026-119566

Exploitation requires a Prometheus instance (≤3.15.1) whose remote_write is configured with Azure AD or Google IAM (OAuth2/bearer-token) authentication AND with redirects followed, which is the default. The attacker must control the configured remote-write endpoint, or be positioned to return/inject an HTTP 3xx redirect to a host of their choosing in that path - this is the AT:P attack requirement and the main limiter. It does NOT apply to remote_write setups that do not use these bearer-token credential types, nor where the endpoint and its redirect path cannot be attacker-influenced; the AC:H/AT:P metrics reflect that the attacker must already control a server in the remote-write flow rather than attacking Prometheus directly.

This is a medium-severity information-disclosure flaw (CVSS 4.0 base 6.3) whose signals are internally consistent and point to conditional, not opportunistic, risk. The vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L) shows a network-reachable issue requiring no privileges on Prometheus and no user interaction, but with high attack complexity and a specific attack requirement (AT:P) - the attacker must control a server in the remote-write path to inject a 3xx redirect, which is the limiting factor, not a weakness in Prometheus's own exposure. There is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a patchable, condition-dependent issue rather than a drop-everything emergency. A public research writeup (abraxaslabs.tech) and a VulnCheck advisory exist, so exploitation technique is documented, but the input does not confirm working weaponized exploit code. Net: a genuine credential-exposure concern for the specific population that uses remote_write with Azure AD or Google IAM authentication, but not a high-real-risk mass-exploitation scenario for the general Prometheus install base. Missing signals to note explicitly: EPSS probability is not supplied and KEV status is absent (treated as not exploited), so prioritization rests on the SSVC-style 'this_month' label plus the documented technique.

A victim runs Prometheus with remote_write configured to use Azure AD or Google IAM bearer-token authentication and follows redirects (the default). An attacker who controls the configured remote-write endpoint, or who can inject a redirect into that path, returns an HTTP 3xx response pointing to a host they control; Prometheus follows it and re-sends the bearer token to the attacker, who captures it and can replay it - for example to write metrics into the victim's monitoring backend. A public PoC reference exists; it is not verified as working exploit code, and the high complexity (AC:H/AT:P) reflects that the attacker must already control a server in the remote-write path.