PatchSiren cyber security CVE debrief
CVE-2024-58375 opentofu CVE debrief
OpenTofu versions 1.8.0 through 1.8.2 have a vulnerability where sensitive variables and locals may be exposed through static evaluation of module sources, versions, and backend configurations when users have opted into this feature. This issue is addressed in OpenTofu 1.8.3, which introduces explicit errors to prevent the use of sensitive values in these contexts.
- Vendor
- opentofu
- Product
- Unknown
- CVSS
- HIGH 8.7
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-08-16
- Original CVE updated
- 2026-09-08
- Advisory published
- 2026-08-16
- Advisory updated
- 2026-09-08
Who should care
Defenders and administrators using OpenTofu versions 1.8.0 through 1.8.2 should assess their exposure and prioritize remediation. This includes performing inventory checks, verifying system configurations, and reviewing compensating controls for exposed systems while remediation is scheduled and verified.
Why it matters
CVE-2024-58375 exposes sensitive variables in OpenTofu configurations. Defenders should prioritize remediation, perform inventory checks, and verify system configurations.
- Potential exposure of sensitive information
- Need for inventory checks and remediation prioritization
- Verification of system configurations and access controls
Technical summary
The vulnerability in OpenTofu allows sensitive variables and locals to be exposed through static evaluation of module sources, versions, and backend configurations. This issue is fixed in OpenTofu 1.8.3, which introduces explicit errors to prevent the use of sensitive values in these contexts. Affected versions include OpenTofu 1.8.0 through 1.8.2, and defenders should prioritize upgrading to OpenTofu 1.8.3 or applying compensating controls to restrict access to sensitive configurations. Inventory checks are necessary to identify potentially affected systems.
Defensive priority
Defenders should prioritize upgrading to OpenTofu 1.8.3 or applying compensating controls to restrict access to sensitive configurations. Inventory checks are necessary to identify potentially affected systems.
Recommended defensive actions
- Upgrade to OpenTofu 1.8.3 or later
- Restrict access to sensitive configurations
- Perform inventory checks for potentially affected systems
- Review compensating controls for exposed systems while remediation is scheduled and verified
- Check relevant monitoring, detection, and logs for exposed assets that need extra review
- Track exceptions, retest remediated assets, and close the item only after evidence is documented
- Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up
Evidence notes
The CVE record and NVD entry provide details on the vulnerability. However, additional information on exploitation or affected systems is limited. Defenders should verify system configurations, perform inventory checks, and assess potential exposure. The vulnerability affects OpenTofu versions 1.8.0 through 1.8.2, and explicit errors are introduced in OpenTofu 1.8.3 to prevent sensitive value exposure.
Sources and references
Verified primary and authoritative sources
-
CVE-2024-58375 CVE Program record
Publisher, destination, and source semantics verified
URL: https://www.cve.org/CVERecord?id=CVE-2024-58375
CVE Program - Official CVE Program record with source-provided CVE metadata.
-
CVE-2024-58375 NVD vulnerability detail
Publisher, destination, and source semantics verified
URL: https://nvd.nist.gov/vuln/detail/CVE-2024-58375
NIST National Vulnerability Database - Official NIST NVD detail page and source-specific vulnerability assessment.
Supplemental references
-
Source reference
Unverified legacy reference
URL: https://github.com/opentofu/opentofu/security/advisories/GHSA-wpr2-j6gr-pjw9
-
Source reference
Unverified legacy reference
URL: https://www.vulncheck.com/advisories/opentofu-before-secret-variable-leaking-via-static-evaluation
Methodology and review provenance
AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.