Summary
Terragrunt catalog predictable temp symlink clobber
Terragrunt's terragrunt catalog command clones each repository referenced in your catalog configuration into a temporary working directory. In affected versions, the clone path it derived was deterministic and sat under the shared system temporary directory, in the form <tmp>/catalog-<base64 sha1 of the repo URL>. Because that path was predictable and Terragrunt followed a symlink already present there instead of rejecting it, a local attacker could plant a symlink at that path and cause Terragrunt to delete a directory and re-clone into it outside the intended temporary root.
Affected Versions
- Terragrunt
< v1.1.1
Workarounds
If you cannot upgrade immediately, ensure that you do not allow untrusted parties to control the values of TMPDIR, TMP, and TEMP in environments where you run terragrunt catalog.
Technical Details
When you run terragrunt catalog, the catalog service iterates over the repositories in your configuration and prepares a local clone of each one. In affected versions, for a given repository URL it built a clone path by hashing the URL and joining the result under the shared system temporary directory:
<tmp>/catalog-<base64 sha1 of the repo URL>
This path was fully determined by the repository URL and the location of the system temporary directory, so anyone else on the machine who knew which repository a victim would catalog could compute it in advance. The catalog service passed this path into its clone preparation step.
As a result, an attacker who placed a symlink at <tmp>/catalog-<hash> pointing at a directory of their choosing caused both the removal and the re-clone to operate through that symlink. Both landed at <attacker-chosen-parent>/<repoName>, outside the intended temporary root.
Terragrunt v1.1.1 no longer derives a predictable clone path, so an attacker can no longer position a symlink at a location known in advance.
Credit
We would like to thank (@br0x2) for discovering and responsibly disclosing this vulnerability.
Impact
This affected users who ran terragrunt catalog on a host they shared with other local users or processes they did not fully trust, such as a multi-user server or a shared CI runner. The attack required a local attacker: a separate local user or process able to write to the shared system temporary directory. It was not remotely exploitable, and the victim had to run terragrunt catalog while the attacker's symlink was already in place.
Because the predictable path depended only on the repository URL being cataloged and the location of the system temporary directory, the attacker could compute it in advance and plant a symlink there before the victim ran the command. When the victim ran terragrunt catalog, Terragrunt followed the symlink out of the intended temporary root, deleted an existing <repoName> directory under the attacker-chosen parent, and repopulated that path with the cloned repository contents. All of this happened in the security context of the user running Terragrunt.
The attacker controlled the parent directory the symlink pointed to, but not the leaf name: the leaf was fixed to <repoName>, derived from the repository URL the victim cataloged. The primitive was deletion of an existing <repoName> directory outside the temporary root, followed by a re-clone into that same path. On a single-user machine with no hostile local processes, exposure was minimal.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
This vulnerability has been resolved in Terragrunt version v1.1.1.
All users are strongly advised to upgrade.
Frequently Asked Questions
- What is CVE-2026-64672? CVE-2026-64672 is a medium-severity security vulnerability in github.com/gruntwork-io/terragrunt (go), affecting versions < 1.1.1. It is fixed in 1.1.1.
- Which versions of github.com/gruntwork-io/terragrunt are affected by CVE-2026-64672? github.com/gruntwork-io/terragrunt (go) versions < 1.1.1 is affected.
- Is there a fix for CVE-2026-64672? Yes. CVE-2026-64672 is fixed in 1.1.1. Upgrade to this version or later.
- Is CVE-2026-64672 exploitable, and should I be worried? Whether CVE-2026-64672 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-64672 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-64672? Upgrade
github.com/gruntwork-io/terragruntto 1.1.1 or later.