GHSA-9c4x-5hgq-q3wh is a medium-severity (CVSS 6.5) Information Exposure vulnerability in github.com/grafana/agent. A fix is available for github.com/grafana/agent — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-9c4x-5hgq-q3wh by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/grafana/agentReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Some inline secrets are exposed in plaintext over the Grafana Agent HTTP server:
- Inline secrets for metrics instance configs in the base YAML file are exposed at
/-/config - Inline secrets for integrations are exposed at
/-/config - Inline secrets for Consul ACL tokens and ETCD basic auth when configured for the scraping service at
/-/config. - Inline secrets for the Kafka receiver for OpenTelemetry-Collector tracing at
/-/config. - Inline secrets for metrics instance configs loaded from the scraping service are exposed at
/agent/api/v1/configs/{name}.
Inline secrets will be exposed to anyone being able to reach these endpoints.
Secrets found in these sections are used for:
- Delivering metrics to a Prometheus Remote Write system
- Authenticating against a system for discovering Prometheus targets
- Authenticating against a system for collecting metrics (scrape_configs and integrations)
- Authenticating against a Consul or ETCD for storing configurations to distribute in scraping service mode
- Authenticating against Kafka for receiving traces
Non-inlined secrets, such as *_file-based secrets, are not impacted by this vulnerability.
Patches
Download v0.20.1 or any version past v0.21.2 to patch Grafana Agent. These patches obfuscate the listed impacted secrets from the vulnerable endpoints.
The patches also disable the endpoints by default. Pass the command-line flag --config.enable-read-api to opt-in and re-enable the endpoints.
Workarounds
If for some reason you cannot upgrade, use non-inline secrets where possible. Not all configuration options may have a non-inline equivalent.
You also may desire to restrict API access to Grafana Agent, with some combination of:
- Restrict network interfaces Grafana Agent listens on through
http_listen_addressin theserverblock.127.0.0.1is the most restrictive,0.0.0.0is the default. - Configure Grafana Agent to use HTTPS with client authentication.
- Use firewall rules to restrict external access to Grafana Agent's API.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/grafana/agent | ≥ 0.14.0&&< 0.21.2 | 0.21.2go get github.com/grafana/agent@v0.21.2 |
Affected Products
agentgrafanaDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/grafana/agent, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/grafana/agent to 0.21.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9c4x-5hgq-q3wh is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is GHSA-9c4x-5hgq-q3wh in your dependencies?
Find it across Go, including transitive dependencies.