CVE-2026-64679: 
Atlantis vulnerability analysis and mitigation

CVE-2026-64679 is a path traversal vulnerability in Atlantis, a self-hosted Go application for automating Terraform pull request workflows via webhooks. Affecting versions >= 0.19.8 and < 0.45.0, the flaw allows authenticated users to supply crafted workspace values containing traversal segments (e.g., ../../../../../../../../tmp/f1-canary) that escape the intended per-pull workspace directory. The vulnerability was reported by researcher shblue21, published to the GitHub Advisory Database on August 21, 2026, and carries a CVSS v3.1 base score of 8.1 (High) (Github Advisory, Feedly).

The root cause is insufficient input validation of user-controlled workspace values before they are joined into local filesystem paths, classified as CWE-22 (Path Traversal) and CWE-73 (External Control of File Name or Path). Workspace values can be supplied via repository-level atlantis.yaml configuration or through authenticated /api/plan API input; neither source was consistently sanitized before path construction. In vulnerable code paths within working_dir.go and project_command_runner.go, the resolved workspace path was used directly in os.RemoveAll, os.MkdirAll, and related filesystem operations — all executing with the privileges of the Atlantis process — before Terraform itself rejected the invalid workspace name. The fix introduced an EnsureSubPath utility function using filepath.Clean and prefix checking, applied at both parse time (rejecting .., /, and \ in workspace names) and at runtime across all six command runner functions (doPlan, doApply, doPolicyCheck, doVersion, doImport, doStateRm) (Github Advisory, Fix PR).

Successful exploitation allows an authenticated attacker to cause Atlantis to create, delete, or reuse arbitrary directories outside the intended workspace root with the privileges of the Atlantis process user, resulting in high integrity and availability impact with no confidentiality impact. Depending on deployment configuration and filesystem permissions, this can lead to deletion of critical Atlantis data directories, corruption of other projects' working directories, or denial of service by destroying state needed for legitimate operations. Containerized deployments may limit host-level impact, but writable mounted volumes and persistent Atlantis data paths (e.g., ~/.atlantis/repos/) remain at risk (Github Advisory).

A proof-of-concept was demonstrated by the reporter using a crafted atlantis.yaml with a traversal workspace value, and the PoC details are publicly documented in the security advisory. There is no evidence of in-the-wild exploitation at this time, and no attribution to specific threat actors has been made. The EPSS score is approximately 0.383% (32nd percentile), indicating a relatively low near-term exploitation probability. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory, Feedly).

1. Identify a vulnerable Atlantis instance: Confirm the target is running Atlantis >= 0.19.8 and < 0.45.0 by checking version banners, API responses, or repository metadata.
2. Gain repository access or API credentials: Obtain the ability to either push changes to a repository whose atlantis.yaml is accepted by the server, or acquire credentials for the authenticated /api/plan endpoint.
3. Craft a malicious workspace value: Construct an atlantis.yaml with a traversal payload in the workspace field, for example:

version: 3
projects:
  - dir: .
    workspace: ../../../../../../../../tmp/attacker-dir

4. Trigger Atlantis processing: Open or update a pull request in the target repository, or submit a crafted /api/plan request, causing Atlantis to parse the malicious configuration.
5. Observe out-of-bounds filesystem operations: Atlantis resolves the traversal path and calls os.RemoveAll and/or os.MkdirAll on the attacker-specified directory (e.g., /tmp/attacker-dir) with the privileges of the Atlantis process, before Terraform rejects the invalid workspace name.
6. Achieve impact: Depending on the target path and permissions, the attacker can delete critical directories (denial of service), create writable directories for later abuse, or corrupt other projects' working state (Github Advisory).

• Logs: Atlantis application logs showing workspace paths resolving outside ~/.atlantis/repos/ (e.g., /tmp/, /etc/, or other unexpected directories); log entries referencing os.RemoveAll or os.MkdirAll on out-of-bounds paths; Terraform invocations with working directories outside the expected Atlantis workspace root.
• File System: Unexpected directories created or deleted outside ~/.atlantis/repos/ or the configured Atlantis data directory; presence of directories matching traversal patterns (e.g., /tmp/f1-canary or similar attacker-chosen names) with timestamps correlating to Atlantis plan/apply activity.
• Network: Authenticated API requests to /api/plan with workspace values containing .., /, or \ characters in request bodies; pull request webhook events from repositories with suspicious atlantis.yaml changes introducing traversal workspace values.
• Configuration: Repository-level atlantis.yaml files containing workspace fields with path traversal sequences such as ../, ../../, or absolute paths (Github Advisory).

The primary remediation is to upgrade Atlantis to version 0.45.0 or later, which introduces EnsureSubPath validation and rejects workspace values containing .., /, or \ at both parse time and runtime (Atlantis Release). If immediate patching is not possible, restrict access to the atlantis.yaml configuration and the /api/plan API endpoint to trusted users only, and implement network-level controls to limit who can trigger Atlantis webhook processing. Containerized deployments should minimize writable volume mounts to reduce the blast radius of any exploitation.

The vulnerability was reported by researcher shblue21 and the fix was developed collaboratively using GitHub Copilot with detailed security review by maintainer jamengual, who identified several critical issues in the initial patch (including a missing lock release in doPlan that could cause a denial-of-service via orphaned locks) (Fix PR). The advisory was published to the GitHub Advisory Database on August 21, 2026, and picked up by automated vulnerability tracking services including VulnDB, OSV, and Tenable shortly after disclosure.