Atlantis CVE-2026-64679

Exploitation requires an authenticated user who can either commit an atlantis.yaml to a repository whose pull requests Atlantis is configured to process, or submit a crafted authenticated /api/plan HTTP request. The workspace value must contain path traversal segments (e.g., '../../../../tmp/target') to escape the ~/.atlantis/repos/ workspace root. Exploitation is bounded by the filesystem permissions of the Atlantis process user - only paths writable by that process are affected; the CVSS vector PR:L confirms at minimum low-privilege authentication is required and unauthenticated exploitation is not possible. Containerized deployments constrain host filesystem reach, but writable mounted volumes including Terraform state and plan artifact directories remain within scope. The vulnerability does not require a non-default configuration - accepting repository-level atlantis.yaml is a standard and commonly used Atlantis deployment mode.

The CVSS 8.1 score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H) reflects network-accessible exploitation requiring only low-privilege authentication, with high integrity and availability impact but no confidentiality loss. The PR:L prerequisite is the primary limiting factor - exploitation requires a user who can submit repository-level atlantis.yaml (a VCS repository collaborator) or make authenticated /api/plan requests. A working PoC is confirmed in the GHSA advisory with specific workspace values and log output, providing high confidence that exploitation is technically feasible with minimal skill. The vulnerability is absent from CISA KEV, indicating no confirmed widespread active exploitation at time of analysis. In containerized Atlantis deployments, host filesystem impact is constrained by container isolation, but writable mounted volumes - Terraform state directories, plan artifact paths, and persistent Atlantis data - remain fully exploitable. The dual I:H/A:H impact is particularly significant in CI/CD contexts where Terraform state corruption or working-directory deletion can directly disrupt infrastructure operations. Real-world risk is elevated for any organization where Atlantis accepts atlantis.yaml from contributor-level VCS users, which is a common and default-supported configuration.

A VCS repository collaborator with pull request access commits an atlantis.yaml containing a workspace value of '../../../../../../../../tmp/f1-canary' and opens a pull request. Atlantis processes the incoming webhook, resolves the traversal to /tmp/f1-canary, and invokes os.RemoveAll followed by os.MkdirAll on that out-of-bounds path before Terraform rejects the workspace name - deleting and recreating an arbitrary directory with Atlantis process privileges. A working PoC demonstrating this exact behavior, including Atlantis log output confirming the out-of-bounds directory creation, is documented in GHSA-26w5-6g95-gj28.