GHSA-6x6c-w9w9-hv4h: Go/github.com/infracost/infracost vulnerability
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: pullrequest (the only configuration in Infracost's documentation) fork pull requests run without secrets, so no token is present. It only reaches token disclosure under pullrequesttarget, 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 latest Docker tag: upgrade to v0.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: pullrequest rather than pullrequesttarget, 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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/infracost/infracostto a version that resolves this vulnerability.Fixed in 0.10.45 - Upgrade
Upgrade
infracostto a version that resolves this vulnerability.Fixed in v0.10.45 - Configuration
Configure the workflow to use `on: pull_request` rather than `pull_request_target` to avoid exposing Terraform Cloud/Enterprise (or registry) tokens during runs that process untrusted pull request content.
GitHub Actions workflow on = pull_request (instead of pull_request_target) - Configuration
In the Infracost configuration, pin `organization`, `workspace`, and `host` so that the `.tf` hostname is ignored during runs that process untrusted pull request content.
Infracost config organization, workspace, host = pinned to specific values - Configuration
Ensure Terraform Cloud/Enterprise and registry tokens are not available in runs that process untrusted pull request content (so no token is injected even if an untrusted Terraform host is scanned).
Infracost Terraform Cloud/Enterprise integration Terraform Cloud/Enterprise and registry tokens availability = kept out of untrusted pull request runs
Event History
Frequently Asked Questions
Which CI workflows are realistically exposed to token disclosure?
Exposure requires both untrusted Terraform input that can control a request hostname and a Terraform Cloud/Enterprise or registry token available to the run. The documented on: pull_request setup does not expose secrets to fork pull requests, while pull_request_target, same-repository pull requests, or other CI configurations that provide tokens with untrusted Terraform can be affected.
What must an attacker do to obtain a token?
They must cause Infracost to process Terraform that injects an attacker-controlled host while a relevant token is present in the workflow. For an untrusted fork pull request, a maintainer typically must also approve the workflow run.
Are default documented configurations affected?
The documented on: pull_request configuration does not disclose tokens from fork pull requests because secrets are not present. Risk changes if the workflow trigger or CI setup makes a token available while processing untrusted Terraform.
What version contains the fix?
The issue is fixed in v0.10.45. The fix sends a token only when the destination host matches the configured trusted host, and otherwise refuses to send it.