Database/Control plane, storage & DevOps

Grafana Mimir Alertmanager: tenant receiver config reads arbitrary host files into notification headers

CVSS 7.7CVE-2026-81938Control plane, storage & DevOpscurated

Impact

Mimir is a common long-term metrics store for GPU fleets, and its Alertmanager is multi-tenant by design. The file-reference check missed http_headers.<name>.files and basic_auth.username_file, so a tenant allowed to write its own Alertmanager configuration can point those fields at any file the Alertmanager process can read. When a notification fires, the contents land in a header of an outgoing HTTP request to a receiver the tenant controls, which turns an alerting config into a file-read primitive against the shared Alertmanager host - credentials, tokens and configuration for the whole cluster, not just that tenant. Grafana Enterprise Metrics, built on Mimir, is affected the same way.

Who can reach it

An authenticated tenant with permission to write its own Alertmanager configuration in a shared Mimir or GEM installation. No access to the host or to the management network is needed - the config upload API is enough.

What to do

Upgrade Mimir to 3.1.7 or 3.2.2, or GEM to 2.17.20 or later, and restart the Alertmanager components; no node drain or reboot is involved. GEM 2.11 through 2.16 will not get a fix - those installations have to move to 2.17.20 or later. Until then, restrict who may write tenant Alertmanager configurations.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-81938 https://grafana.com/security/security-advisories/cve-2026-81938

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.