CVE-2026-71494 in Infracost
Summary
by MITRE • 08/21/2026
Infracost provides cloud cost intelligence for engineers, AI coding agents, and CI/CD. Prior to 0.10.45, internal/hcl/remote_variables_loader.go and related Terraform Cloud, remote-plan, and Terragrunt registry request paths can attach a configured Terraform Cloud or registry token to a destination hostname derived from untrusted Terraform input without confirming that it is the configured trusted host. When a CI run provides a token while scanning attacker-controlled Terraform, including pull_request_target or a same-repository pull request, an attacker can direct the request to an attacker-controlled host and disclose the token. Standard fork pull_request workflows without secrets are not exposed. This issue is fixed in version 0.10.45.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Infracost prior to version 0.10.45 represents a critical security flaw within its cloud cost intelligence processing engine, specifically affecting the handling of remote state and variable loading mechanisms. This issue stems from an improper validation of destination hostnames when constructing requests for Terraform Cloud or Terragrunt registry interactions. The core technical failure lies in the function located at internal/hcl/remote_variables_loader.go, which is responsible for managing connections to external infrastructure-as-code registries. When processing input derived from untrusted sources, such as user-provided Terraform configurations, the software fails to verify that the target hostname matches a pre-configured list of trusted domains before attaching sensitive authentication credentials. This lack of strict host validation allows an attacker who controls or influences the Terraform configuration file being scanned to manipulate the destination address used for API requests.
The operational impact of this vulnerability is significant in environments where Infracost is integrated into continuous integration and deployment pipelines, particularly those utilizing GitHub Actions with pull_request_target workflows or same-repository pull request triggers that have access to secrets. In these scenarios, if an attacker can inject malicious Terraform code into the repository being scanned, they can configure the input to specify a remote backend or module source pointing to a server under their control. Because the application blindly attaches any configured Terraform Cloud token or registry API key to this unverified hostname, the credentials are transmitted directly to the attacker's infrastructure upon execution of the scan. This results in the complete disclosure of sensitive authentication tokens, which can then be used by the adversary to access private repositories, modify cloud resources, or escalate privileges within the affected organization’s cloud environment.
This flaw aligns with CWE-209, which describes the generation of error messages containing sensitive information that could aid an attacker, although in this specific case, it is more accurately categorized under CWE-749, where a system exposes a dangerous operation to an unauthorized actor without proper validation. From a tactical perspective, as defined by MITRE ATT&CK, this vulnerability facilitates Credential Access through techniques such as OS Command Injection or Data from Information Repositories if the attacker leverages other vectors to execute the malicious configuration. The attack vector is primarily remote and requires initial access to inject code into the CI/CD pipeline context that has elevated permissions, making it a high-risk issue for organizations relying on automated infrastructure scanning with secret exposure capabilities.
Mitigation strategies must prioritize immediate upgrading of Infracost to version 0.10.45 or later, where this hostname validation logic has been corrected to ensure tokens are only sent to explicitly trusted hosts. For environments that cannot immediately upgrade, defensive measures should include restricting the permissions of CI/CD secrets so they are not available in pull_request workflows unless specifically approved for forked repositories. Additionally, implementing strict allowlists for external module sources and remote backends within Terraform configurations can provide an additional layer of defense against host manipulation attacks. Security teams should also audit their CI/CD pipelines to ensure that untrusted code is never executed with elevated privileges or access to sensitive credentials during automated scanning processes.