OpenTofu CVE-2026-74796 and 74797: when tofu init crosses a trust boundary

CVE-2026-74796 and CVE-2026-74797 for OpenTofu were published on 16 August 2026. The first describes a write outside the working directory through a pre-positioned symbolic link in the provider cache. The second covers excessive CPU use while processing a maliciously structured provider or module ZIP. CVE-2024-58375, also published that day, documents an older static-evaluation issue that could expose values marked sensitive in OpenTofu 1.8.0 through 1.8.2.

The dates need precision. Upstream advisories and fixes for some of these issues predate 16 August; publication of the CVE records was the development on that date. The sources do not establish a new incident or widespread OpenTofu exploitation. They do provide a valuable DevSecOps lesson: tofu init combines a local directory, dependency metadata, network-delivered archives and caches in a process that often runs with broad cloud access.

The CVE-2026-74796 advisory identifies fixes in 1.11.7 and 1.10.10. CVE-2026-74797 is fixed from 1.11.4, and the sensitive-value issue from 1.8.3. For the current 1.11 branch, 1.11.7 or later covers both newly recorded initialisation problems.

What tofu init does and why it matters

Initialisation prepares a working directory, resolves modules and providers, downloads packages, checks lock information and places content in .terraform. CI runs it before planning, while operators use it before changing an environment. This is not a passive configuration parser: the command performs network operations and writes files.

When infrastructure code comes from a pull request, customer template, recruitment exercise, incident-recovery repository or external module, its working directory should not automatically receive trust. Running init resembles dependency-package processing and belongs in a controlled environment.

The most dangerous operational mistake is combining analysis of an unknown repository with production credentials. Even when a particular CVE does not execute provider code, a file write or process degradation can contribute to a larger chain. A minimal token, isolated workspace and absence of secrets in the process environment reduce the consequences of an unexpected path.

CVE-2026-74796: a cache link leaves the tree

OpenTofu permits symbolic links in a local cache because a working-directory entry may refer to an identical package in a configured global cache. The affected installer did not sufficiently distinguish a safe, matching entry from a pre-existing link targeting another location. When installation was required, package content could be written to the link target outside the working directory.

Exploitation requires a specific condition: an operator must run tofu init in a directory whose content an attacker can control, and the process must be able to write to the destination. This is not an unauthenticated arbitrary write to any remote server. The risk is nevertheless practical in automated pipelines that inspect untrusted branches or project bundles.

Impact depends on the target path and process privileges. The flaw can violate the integrity of files writable by the runner, persist a change in its workspace or corrupt an artefact consumed by a later task. It should not automatically be labelled remote code execution; execution would require another component to load or run the written file.

Patched versions reject an existing cache entry when its content does not match the expected package. If the existing content already matches exactly, OpenTofu can use it without modification. Teams using TF_DATA_DIR must remember that it moves the sensitive area from .terraform to the configured directory.

CVE-2026-74797: an archive creates a CPU bill

The second problem concerns ZIP files retrieved during provider or module installation. A specially structured archive could demand excessive CPU, delaying or preventing completion of tofu init. The upstream advisory identifies 1.11.4 as the first fixed release.

This record receives a lower severity than the symlink write because the attacker needs influence over a package source and passive interaction from an operator or automation running initialisation. In CI, however, the cost is multiplied by runner count, retry policies and parallel branches. An apparently “stuck init” can occupy the executor pool and delay every deployment.

A job timeout is necessary but remains a final barrier. Trusted registries, reviewed lockfiles, checksum verification and module-source controls are more important. Runners need CPU and memory limits and should not share a writable cache across tasks with different trust levels.

CVE-2024-58375: sensitive does not mean invisible everywhere

The third record affects static evaluation of module sources, versions and backend configuration in the 1.8 line. A value marked sensitive could be used where it should have produced an error and then exposed through configuration output or diagnostics. The project advisory limits exposure to versions 1.8.0, 1.8.1 and 1.8.2; version 1.8.3 adds explicit rejection.

The issue is conceptually important. The sensitive marker controls presentation along specified tool paths, but it is not encryption or DLP. A secret used to construct a module address, backend path or identifier can leak into logs, resource names, errors or cache metadata.

Secrets should only enter interfaces designed to receive them. Pipelines must also filter debug logs and plan artefacts because correcting validation in one context does not eliminate every possible IaC data exposure.

An action plan for platform teams

Inventory the OpenTofu version in runner images, developer tools and standalone automation. Move the 1.11 line to 1.11.7 or later. Organisations staying on 1.10 should use 1.10.10 or a later supported correction. Remove images containing older binaries from private registries so pipelines cannot fall back to an affected version.

Treat an IaC pull request as untrusted input. A validation job should receive neither production credentials nor write access to a shared cache. Prefer ephemeral runners or a clean workspace, mount the repository with minimal permissions and separate caches used by trusted branches from those used by forks.

Review TF_DATA_DIR, .terraform, global plugin caches and every mechanism that retains them between jobs. Look for symbolic links, unexpected ownership, target changes and entries created by an untrusted branch. Do not automatically delete evidence when the review is part of incident response.

Enforce approved module and provider sources. Review lockfile changes and create a clear signal for a changed source, checksum or version. Restrict runner egress to required registries. That prevents compromise of an arbitrary download host from becoming an input to every environment.

Detection and testing

Alert on unusually long tofu init runs, high CPU, repeated downloads and sudden changes in cache file count. Record the OpenTofu version, lockfile digest, module source, runner and commit without recording sensitive variable values.

A symlink regression test should prove that initialisation rejects a mismatched existing entry without writing outside a controlled directory. An archive test belongs only in an isolated runner with strict time and resource limits. A sensitive-data test should expect an explicit error when a secret enters a statically evaluated module source or backend field.

Facts and Breachroad conclusions

It is a fact that the records published on 16 August describe three different issues: a symlink write, ZIP-driven CPU consumption and sensitive-value exposure in the older 1.8 line. Upstream fixes are 1.11.7/1.10.10, 1.11.4 and 1.8.3 respectively. The sources do not show widespread exploitation.

Breachroad’s conclusion is that IaC initialisation is a software-supply-chain operation, not an innocuous preparation step. A secure process combines a current tool with ephemeral runners, separated caches, source controls and least-privilege credentials.

Platform teams can build these habits through our cybersecurity training for organisations. Environment controls can also be validated through a cloud security assessment.