Terragrunt CVE-2026-64672
MEDIUM
GHSA-wv6g-x823-wx9m
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local user access on shared host
-
DeliveryCompute predictable catalog temp path from repo URL
-
ExploitPlant symlink pointing outside temp root
-
ExecutionVictim runs terragrunt catalog
-
ImpactDelete and re-clone into attacker-chosen directory
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Symlink resolution safety
|
| Exploitation Conditions | Requires: (1) a multi-user or shared environment (e.g. shared server or CI runner) where a separate local user or process can write to the system temporary directory (TMPDIR/TMP/TEMP); (2) the attacker to know in advance which repository URL the victim will catalog, so they can pre-compute the deterministic path |
| Impact | No CVSS score or vector was provided (input shows N/A), and there is no EPSS probability, no CISA KEV listing, and no public exploit code - so the only strong signal is the vendor's own GitHub Security Advisory (GHSA-wv6g-x823-wx9m) and patch. Based on the description this is a CWE-59 symlink-following flaw that is explicitly local-only and NOT remotely exploitable, requiring a separate, already-present local attacker on a shared host plus the victim running |
| Exploit ScenarioDerived | On a shared CI runner, a low-privileged local attacker pre-computes the deterministic clone path |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 15, 2026
Symlink following in Terragrunt's terragrunt catalog command (versions before v1.1.1) lets a local attacker who can write to the shared system temporary directory have the victim's clone preparation operations follow a planted symlink, deleting an existing <repoName> directory outside the intended temp root and repopulating that path with the cloned catalog repository contents - all executed in the victim's own security context. The attacker must know in advance which repository URL the victim will catalog so they can pre-compute the deterministic path <tmp>/catalog-<base64 sha1 of repo URL> and plant the symlink before the run, and they control only the symlink's parent directory because the leaf name is fixed to <repoName>. The issue is not remotely exploitable, requires a shared multi-user or CI host plus a victim-initiated terragrunt catalog run, and no public exploit code has been identified at time of analysis; consistent with the independent assessment (CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:L), the impact is limited to low integrity and availability effects with no confidentiality impact, and exposure is minimal on single-user machines with no untrusted local processes.
RemediationAI
Vendor-released patch: upgrade to Terragrunt v1.1.1 or later, as documented in the vendor advisory at https://github.com/gruntwork-io/terragrunt/security/advisories/GHSA-wv6g-x823-wx9m; the fix is delivered by PR https://github.com/gruntwork-io/terragrunt/pull/6438 (commit https://github.com/gruntwork-io/terragrunt/commit/668891c5a2ad2996f134bb8b00098754674ea94a), which replaces the deterministic <tmp>/catalog-<base64 sha1 of repo URL> clone path with a randomly named directory created via vfs.MkdirTemp, rejects symlinked clone roots, and cleans up catalog clones when the TUI session exits. If immediate upgrade is not possible, the vendor's workaround is to ensure untrusted parties cannot control the TMPDIR, TMP, and TEMP values in any environment where terragrunt catalog is run - practical options are exporting TMPDIR to a per-user directory with permissions restricted to the running user (mode 0700) or running catalog operations in a container/ephemeral runner with an isolated, single-tenant temp filesystem. The trade-off is that private temp directories may surprise other tooling that expects the system-wide temp location and can change disk-usage expectations on long-lived CI runners, and container isolation adds build-time and orchestration overhead; neither mitigation removes the underlying link-following behavior, so upgrading to v1.1.1 remains the durable fix. Because exploitation is local-only and depends on pre-existing write access to the shared temp directory plus knowledge of the cataloged repository URL, prioritizing upgrade on multi-user servers and shared CI runners addresses the realistic exposure.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in go
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-59 (Improper Link Resolution Before File Access, i.e. link following) in the catalog subsystem of Terragrunt, a Go-based wrapper around OpenTofu/Terraform. When terragrunt catalog iterates the repositories in the catalog configuration, the affected code derived a clone destination with CatalogTempPath(repoURL), which resolved os.TempDir() through symlinks and then joined the result with fmt.Sprintf("catalog-%s", util.EncodeBase64Sha1(repoURL)), producing a fully deterministic, attacker-computable path of the form <tmp>/catalog-<base64 sha1 of the repo URL>. That path was passed into the clone-preparation step built on module.NewRepo; because the code neither created the directory atomically with an unpredictable name nor rejected a pre-existing symlink at that location, a symlink planted there caused the subsequent removal of <repoName> and the re-clone to operate through the link, landing at <attacker-chosen-parent>/<repoName> outside the intended temporary root. The upstream fix in v1.1.1 replaces the deterministic scheme: CreateCatalogTempPath now calls vfs.MkdirTemp with the prefix catalog-<base64 sha1>-, yielding a fresh random-suffixed directory per catalog load, rejects symlinked clone roots, tracks the directories in a tui.TempDirTracker for cleanup on TUI exit, and removes the temporary clone when a load fails or the session ends (PR #6438, commit 668891c5a2ad2996f134bb8b00098754674ea94a). Note that the supplied tag 'Information Disclosure' does not match the vendor advisory or the assessed vector, which describe file/directory deletion and unauthorized re-clone rather than data exfiltration.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Local-only with a pre-planted symlink and a required victim command run means AV:L, AC:H, PR:L and UI:R; impact is constrained directory deletion/re-clone, so C:N with I:L/A:L.
DescriptionCVE.org
Summary
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.
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
- Terragrunt
< v1.1.1
Patches
This vulnerability has been resolved in Terragrunt version v1.1.1.
All users are strongly advised to upgrade.
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.
Threat Intelligence Overview
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB