Grafana Mimir EUVD-2026-115357

Requires an authenticated tenant with permission to write/upload that tenant's Alertmanager configuration in a Grafana Mimir or GEM deployment that accepts tenant-supplied receiver configurations. The attacker must set the HTTP client fields http_headers.<name>.files or basic_auth.username_file (the two settings the local-file check failed to cover) to the path of a file readable by the Alertmanager process, and must direct the receiver at a server they control; disclosure occurs only when a notification is actually sent, at which point the file contents are placed in an outgoing request header. Limiting factors: exploitation is impossible without tenant config-write privilege, is confined to deployments that allow tenant-supplied Alertmanager configs, and is bounded by what the Alertmanager process user can read on the host; it yields confidentiality impact only (no integrity or availability effect). The complete fix is upgrading to Mimir 3.1.7/3.2.2 or GEM 2.17.20 (GEM 2.11-2.16 receive no fix).

The vendor-supplied CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, 7.7 High) is internally consistent with the described mechanism: a network-reachable configuration-upload API (AV:N), no special triggering complexity (AC:L), a low-privileged but authenticated tenant (PR:L), no user interaction (UI:N), a scope change reflecting that a tenant can cause the Alertmanager process to read host files outside its own tenant boundary (S:C), and confidentiality-only impact (C:H, I:N, A:N). The vuln.today decision label is 'this_week', indicating an elevated but non-emergency priority. KEV is not listed, so there is no confirmed active exploitation, and no EPSS score was provided, so widespread-exploitation probability cannot be quantified from this data. No proof-of-concept or exploit reference appears in the input - the only reference is the Grafana advisory - so this is 'no public exploit identified at time of analysis'. Net assessment: this is a genuine, well-characterized tenant-isolation / secret-disclosure flaw that matters specifically in multi-tenant GEM/Mimir deployments where tenants can supply their own Alertmanager receiver configurations; the PR:L requirement and the need for a tenant-supplied-config deployment model meaningfully constrain real-world exposure, so it is a real priority to patch but not a drop-everything emergency on current signals. EPSS and KEV data are absent rather than contradictory, so no conflicting signals were observed.

In a multi-tenant Grafana Mimir or GEM deployment, a tenant who is permitted to upload their own Alertmanager configuration sets http_headers.<name>.files or basic_auth.username_file to point at a sensitive file readable by the Alertmanager process (such as credentials or configuration) and configures the receiver to send notifications to a server the attacker controls. When a notification fires, Alertmanager reads the referenced file and places its contents into an outgoing request header, exfiltrating host secrets to the attacker. No public exploit code is identified in the provided sources.