GHSA-6x6c-w9w9-hv4h
Fix: infracost/infracost#3590GHSA-6x6c-w9w9-hv4h is a CWE-522 vulnerability in github.com/infracost/infracost. O3 Security confirms whether GHSA-6x6c-w9w9-hv4h is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Infracost: Terraform Cloud and registry token disclosure via unvalidated hostname
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6x6c-w9w9-hv4h.
Real-World Exposure
github.com/infracost/infracostReal-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
Sensitive information exposure in the Infracost Terraform Cloud/Enterprise integration. Several code paths attached a configured secret token to a request whose host was taken straight from the scanned Terraform, with no check that the host was the trusted endpoint.
The condition that matters is whether a Terraform Cloud/Enterprise (or registry) token is present in the run: if one is, the injected hostname can disclose it. Impact therefore depends on the trigger. Under on: pull_request (the only configuration in Infracost's documentation) fork pull requests run without secrets, so no token is present. It only reaches token disclosure under pull_request_target, a same-repository pull request, or another CI setup that provides the token alongside untrusted Terraform, and exploiting an untrusted fork pull request also typically needs a maintainer to approve the workflow run. The patch scopes the token to the trusted host regardless of trigger.
Patches
Fixed in v0.10.45 (#3590) by attaching a token only when the destination host matches the configured trusted host; otherwise Infracost refuses to send it and skips remote variable loading
- Installed via the official script, a package manager, or the
latestDocker tag: upgrade tov0.10.45(or later) to receive the fix. - Pinned to a specific version or image digest: bump to
v0.10.45.
Workarounds
No full fix without upgrading. To limit exposure: use on: pull_request rather than pull_request_target, pin organization, workspace, and host in Infracost config so the .tf hostname is ignored, and keep Terraform Cloud and registry tokens out of runs that process untrusted pull request content.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/infracost/infracost | all versions | 0.10.45 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/infracost/infracost. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/infracost/infracost to 0.10.45 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6x6c-w9w9-hv4h is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6x6c-w9w9-hv4h is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6x6c-w9w9-hv4h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6x6c-w9w9-hv4h in your dependencies?
O3 detects GHSA-6x6c-w9w9-hv4h across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.