Prometheus-style scraping expects a bearer token, and the convention for supplying one is a file path. Alloy follows that convention. CVE-2026-75889 covers the version of it where the path was taken at face value, so a configuration that named a sensitive file caused the agent to read that file and send its contents to a remote endpoint as an authorization header.

Where the boundary broke

A service that reads a token from disk is doing something ordinary. The dangerous part is who chooses the path. In Alloy, the setting is part of a scraping configuration, which in many deployments is written by whoever can reach the configuration API or the config repository rather than by whoever administers the host.

Once the path is attacker-influenced, the primitive is arbitrary local file read with an exfiltration channel built in. The agent does not need to expose the file. It sends the contents to the target it is scraping, and the target is also attacker-chosen. Scored 7.7, in the same advisory wave as several higher-rated Grafana issues, which is probably why it received less attention than it deserved.

What sits on a host that runs an observability agent

The agent runs as a service with a stable identity, which makes its readable files interesting in a specific way:

  • cloud credential files and workload identity tokens, which convert into API access;

  • the Alloy configuration itself, holding remote-write endpoints, API keys for Grafana Cloud and credentials for any integration it scrapes;

  • Kubernetes service account tokens, when the agent runs as a DaemonSet with a mounted token;

  • TLS private keys, when the deployment terminates or originates mutual TLS;

  • environment files and compose definitions, which frequently carry database passwords for the very services being monitored.

The last item deserves emphasis. An observability agent is often the only workload with network access to every service, so its configuration is a map of every credential in the estate.

The configuration-injection path

A file-read bug alone is limited. The reason this one matters is the write path. Alloy supports a configuration API that, on some deployments, is reachable without authentication because it was assumed to be on an internal interface. Combined with a UI feature that renders configuration fragments or a repository that accepts contributions, the ability to name a file path becomes reachable from a lower position than administrator on the host.

This is the pattern to internalise. Telemetry agents are configured dynamically by design, so they accept instructions from somewhere. If that somewhere is reachable from the same network as the dashboards, the agent's privileges become the effective privileges of whoever can post a configuration fragment.

Verification and containment

  • Search configuration for bearer_token_file and related path settings, and confirm each names a path under a dedicated secrets directory rather than anywhere on disk.

  • Confirm the configuration API is authenticated and not bound to all interfaces. Treat it as an administrative interface.

  • Check outbound connections from the agent to endpoints that are not the intended scrape targets or remote-write destinations. The exfiltration channel is an outbound request that looks like scraping.

  • Rotate any credential readable by the agent process if an affected version ran with a reachable configuration path.

  • Run the agent with a read-only root filesystem, a projected token with a short lifetime, and a mount set that excludes the rest of the host.

None of that depends on the next CVE. It is the difference between an agent that can read one secret and an agent that can read the machine.

References

  • NVD record for CVE-2026-75889, Grafana Alloy bearerTokenFile arbitrary file read and credential transmission.

  • Grafana security advisory entry for the Alloy issue, including the fixed release and the CVSS score of 7.7.

  • Grafana Alloy documentation covering prometheus.scrape authentication settings and bearer token file handling.