Description

OpenTofu versions 1.8.0 through 1.8.2 do not properly restrict sensitive variables and locals when users have opted into static evaluation of module sources, versions, and backend configurations. As a result, values marked as sensitive may be exposed through these configuration elements instead of producing an error. This is fixed in OpenTofu 1.8.3, which adds explicit errors to prevent the use of sensitive values in these contexts.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-16T14:16:53.627Z",
  "pubdate": "2026-08-16T14:16:53.627Z",
  "executiveSummary": "A sensitive data exposure vulnerability exists in OpenTofu versions 1.8.0 through 1.8.2 when users opt into static evaluation of module sources, versions, and backend configurations. The vulnerability type is an information disclosure flaw stemming from improper restriction of sensitive variables and local values. The impact allows values explicitly marked as sensitive to be inadvertently exposed through configuration elements rather than triggering the expected validation error. The affected product is OpenTofu, specifically versions 1.8.0 up to and including 1.8.2. The risk implications include the potential leakage of credentials, API keys, or infrastructure secrets into execution plans, logs, or state data where they might be viewed by unauthorized personnel or systems. Attacker capabilities rely on the ability to define or manipulate infrastructure configurations or inspect the outputs resulting from static evaluation processes. Exploitation requirements mandate that the user has opted into the static evaluation feature for module sources, versions, and backend configurations, and that sensitive variables or local values are improperly referenced within those specific static evaluation contexts.",
  "technicalDetails": "The vulnerability resides in the configuration evaluation engine of OpenTofu, specifically within the subsystem responsible for handling static evaluation of module sources, version constraints, and backend configurations. The root cause is a deficiency in input validation and type restriction enforcement, which fails to recognize and block the interpolation or referencing of variables and local values designated as sensitive within these specific static contexts. Typically, OpenTofu enforces strict boundaries around sensitive data to prevent leakage into plaintext execution plans or logs, raising an explicit error when sensitive values are utilized in unauthorized contexts. However, in versions 1.8.0 through 1.8.2, this protective mechanism is bypassed during the static evaluation phase of module sources, version declarations, and backend settings. The attack flow begins when a user incorporates a sensitive variable or local value into a module source string, version specifier, or backend parameter while static evaluation is enabled. Instead of halting execution and returning a security error, the evaluation engine processes the sensitive value and resolves it. Consequently, the raw, unmasked sensitive data is processed and potentially persisted within execution telemetry, plan files, or diagnostic output streams accessible to operators or integrated CI/CD pipelines. This bypasses security boundaries designed to protect secrets at rest and in transit within the orchestration framework. The vulnerable components are the module loading, version resolution, and backend configuration parsers within OpenTofu versions 1.8.0, 1.8.1, and 1.8.2. Authentication, privilege requirements, and network exposure depend entirely on the execution environment where OpenTofu is run, such as local developer workstations or remote CI/CD automation runners. Post-exploitation impact is characterized by unauthorized access to sensitive material, potentially leading to privilege escalation or lateral movement if the exposed secrets grant access to external cloud providers, state storage backends, or artifact registries."
}