OpenTofu v1.12.7 Fixes a Provisioner Deadlock With Attacker Controlled SSH Servers

OpenTofu v1.12.7 shipped on October 1 2026. It is a small patch release with one substantive change: a security fix for the remote-exec and file provisioners that prevents a malicious SSH server from deadlocking the connection.

The full release notes and downloads are on the GitHub release page.

The release carries a single advisory, and it is worth understanding the shape of it.

When a provisioner is used against an SSH endpoint, OpenTofu opens an SSH client session and negotiates with the remote host. The advisory covers the case where that host is attacker controlled. A hostile SSH server could send unexpected packet types during the session and previously deadlock the client connection as a result. The fix, merged as PR #4551, closes that path.

Two upstream Go advisories sit behind this:

Because OpenTofu bundles the Go crypto and SSH stack, patches in golang.org/x/crypto and friends surface here as toolchain releases. v1.12.7 is OpenTofu picking up the corrected code.

The blast radius depends on how you use provisioners.

If your modules apply remote-exec or file provisioners only against hosts your own Terraform code just created, within a controlled network, the practical risk is low. Attacker controlled SSH servers are not part of that threat model, and Terraform provisioning runs already require credentials on the target host.

The exposure grows when provisioners point at endpoints you do not fully control. Bootstrap flows that target shared bastions, bastion hosts reachable from less trusted networks, lab or workshop setups where students point provisioners at arbitrary addresses, and any pipeline that applies provisioners to third party network appliances all fit. In those cases an adversary who controls the SSH listener gains a cheap way to hang an apply, rather than a path to remote code execution. A hung apply is an availability problem, not a compromise, but a wedged CI runner or a locked state lock is still an incident when it happens mid release.

Operators with no provisioners on their infrastructure at all can treat this release as a routine dependency pickup and schedule it with the next maintenance window.

No state format changes and no configuration changes are mentioned in the release notes. An upgrade from any earlier v1.12.x patch is a binary swap. Pin the new version in your tooling, rerun one plan to confirm no drift, and move on.

Teams pinned to the v1.12 series should take this in their next rollout. Teams running provisioners against untrusted network paths should prioritize it accordingly.