CVE-2026-45099 — terragrunt
Fix: gruntwork-io/terragrunt@3d6f10dCVE-2026-45099 is a Path Traversal vulnerability in github.com/gruntwork-io/terragrunt. A fix is available for github.com/gruntwork-io/terragrunt — see the affected versions and patch details below.
Terragrunt: Arbitrary File Deletion via Malicious Module Manifest
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-45099.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/gruntwork-io/terragruntReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Terragrunt is vulnerable to an arbitrary file deletion flaw when downloading external modules. If a remote module contains a maliciously crafted .terragrunt-module-manifest file, Terragrunt can be tricked into deleting files anywhere on the local filesystem that the Terragrunt process has access to.
Impact
This vulnerability impacts users who download and run untrusted or compromised OpenTofu/Terraform modules. The file deletion occurs during the module download and initialization phase, meaning it happens before OpenTofu or Terraform executes.
In a CI/CD environment or automated runner, an attacker-controlled module could delete arbitrary files, causing denial of service in the deployment pipeline. In a local environment, it could lead to the loss of local source code or configuration files.
This vulnerability is a deletion-only primitive; it does not directly allow for arbitrary code execution (RCE) or data exfiltration.
Affected Versions
- Terragrunt <
v1.0.4
Patches
This vulnerability has been resolved in Terragrunt version v1.0.4.
All users are strongly advised to upgrade.
Workarounds
If users cannot upgrade immediately, they can mitigate this risk by:
- Strictly auditing the source URLs of all remote modules used in their Terragrunt configurations.
- Only consuming modules from trusted, internally vetted sources or verified registries.
- Pinning module versions to specific, known-safe Git commit SHAs rather than mutable tags or branches.
Technical Details
Terragrunt tracks files copied into a downloaded module's working directory using a .terragrunt-module-manifest file. During the directory cleanup process, Terragrunt decodes the entries in this manifest and removes the listed files to prepare a fresh directory for OpenTofu/Terraform runs.
Previously, Terragrunt trusted the manifest provided by the downloaded module without verifying that the paths scheduled for deletion remained within the boundaries of the module's destination directory. An attacker could forge a manifest containing directory traversal paths, causing the cleanup function to target files outside the cache. The patch introduces a secure boundary check to ensure all cleaned paths remain safely isolated inside the intended manifest folder.
Credit
Terragrunt would like to thank Francesco Sabiu (@fsabiu) for discovering and responsibly disclosing this vulnerability.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gruntwork-io/terragrunt | all versions | 1.0.4go get github.com/gruntwork-io/terragrunt@v1.0.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gruntwork-io/terragrunt, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/gruntwork-io/terragrunt to 1.0.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-45099 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Frequently Asked Questions
Is CVE-2026-45099 in your dependencies?
Find it across Go, including transitive dependencies.