CVE-2026-64679: Directory Traversal via Workspace Parameter in Atlantis

Atlantis is a self-hosted, open-source application designed to automate Terraform workflows using VCS pull requests. The application processes user-configured settings through repository-level configuration files named atlantis.yaml or through authenticated API endpoints. The primary attack surface resides in the workflow execution environment where workspace parameters are handled.\n\nA path traversal vulnerability exists in the handling of these workspace names. The system fails to validate user-provided directory strings before running local directory operations. This oversight enables attackers to manipulate paths and perform arbitrary filesystem directory creations and deletions on the host operating system.\n\nThe vulnerability is classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-73 (External Control of File Name or Path). Unauthenticated or low-privilege users can trigger this vulnerability remotely by modifying configuration files within a pull request or interacting with specific API endpoints. The scope of impact is limited to the host filesystem, affecting integrity and availability.

The root cause of this vulnerability lies in the way Atlantis processes user-supplied workspace names when establishing execution directories. When setting up a workspace for Terraform operations, Atlantis joins a base directory with the workspace name. In Go, the filepath.Join function cleans path separators but does not prevent directory traversal sequences from resolving outside of the target base folder.\n\nIn vulnerable configurations, Atlantis accepts arbitrary string inputs for the workspace parameter. This parameter is fetched from the repository's atlantis.yaml file or from the /api/plan endpoint. If an input string contains directory traversal elements such as ../, the resulting combined path resolves to a location outside the designated sandbox.\n\nOnce the target directory path is established, the application passes the unvalidated path to operations like os.MkdirAll for creation and os.RemoveAll for cleanup. Because these operations run with the privileges of the Atlantis process, they can modify or delete files anywhere the process has write access. This behavior bypasses the directory isolation model of the application.

An analysis of the vulnerable path shows that the application constructs directory locations without asserting boundaries. The following code demonstrates the vulnerable pattern where the workspace string is concatenated directly:\n\ngo\n// Vulnerable pattern of directory creation\nrepoPullDir := filepath.Join(w.DataDir, workingDirPrefix, r.FullName, strconv.Itoa(p.Num))\ncloneDir := filepath.Join(repoPullDir, workspace)\n\n// Creates directory outside intended boundaries if workspace contains \"../\"\nerr := os.MkdirAll(cloneDir, 0700)\n\n\nThe remediation patch introduces several key validation files. In server/utils/filepath.go, a containment check ensures that any resolved child path is physically located within the parent directory. This helper functions by verifying prefix matches:\n\ngo\npackage utils\n\nimport (\n\t\"errors\"\n\t\"os\"\n\t\"path/filepath\"\n\t\"strings\"\n)\n\nvar ErrPathEscapesBase = errors.New(\"path escapes base directory\")\n\nfunc EnsureSubPath(base, path string) error {\n\tcleanBase := filepath.Clean(base)\n\tcleanPath := filepath.Clean(path)\n\tif cleanPath != cleanBase && !strings.HasPrefix(cleanPath, cleanBase+string(os.PathSeparator)) {\n\t\treturn ErrPathEscapesBase\n\t}\n\treturn nil\n}\n\n\nAdditionally, the patch integrates input validation constraints in server/core/config/raw/project.go to reject dangerous characters in workspace names. The validator blocks any values containing .., /, or \\. The project command runner then evaluates the directory paths before executing commands.\n\nThe complete patch mitigates the flaw by combining input sanitization with runtime boundary validation. This multi-layered strategy blocks traversal payloads at the parser level and ensures that even if a payload bypasses initial checks, the command execution engine prevents out-of-bounds filesystem operations.

Exploitation requires the ability to supply a malicious atlantis.yaml configuration file to a target repository or to authenticate to the /api/plan API endpoint. The attacker does not need high-level system administrative privileges if repository write permissions allow them to open pull requests with modified configuration files.\n\nTo trigger the path traversal, the attacker specifies a workspace name with traversal sequences inside the atlantis.yaml file. For example, setting the workspace parameter to ../../../../tmp/target_dir directs the backend to target the host's /tmp/target_dir path instead of the repository workspace directory.\n\nyaml\n# Example malicious configuration snippet\nversion: 3\nprojects:\n - name: exploit-project\n dir: .\n workspace: \"../../../../tmp/target_dir\"\n\n\nWhen Atlantis processes the pull request, it parses the configuration and attempts to clean or initialize the directory. This action triggers the deletion of /tmp/target_dir via internal os.RemoveAll cleanup routines or creates nested structures in writable system paths. No functional code execution is achieved directly through the traversal itself, but the filesystem integrity is compromised.\n\nmermaid\ngraph LR\n A[\"User / Pull Request\"] -->|\"Injects workspace: '../../tmp/target'\"| B[\"atlantis.yaml Parser\"]\n B -->|\"Unsanitized Path Concatenation\"| C[\"filepath.Join(Base, Workspace)\"]\n C -->|\"Resolved Path: /tmp/target\"| D[\"os.RemoveAll() or os.MkdirAll()\"]\n D -->|\"Arbitrary Filesystem Write/Delete\"| E[\"Host File System\"]\n

The security impact of this vulnerability is assessed with a CVSS v3.1 score of 8.1, representing high severity. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H. The vulnerability allows an attacker to manipulate file directories outside of the intended repository-level isolation boundaries.\n\nBecause the workspace name is evaluated inside directory-removal functions during clean-up steps, an attacker can delete arbitrary folders on the host filesystem. This action can lead to denial of service if critical configuration or data directories are deleted. It also impacts system integrity by allowing unauthorized directory creation in system-writable paths like /tmp or /var.\n\nThe impact is limited to the system permissions under which the Atlantis service is executing. If Atlantis runs with elevated host permissions (such as root or administrator), the potential damage extends to system-critical paths. If it runs in a containerized environment, the impact is confined to the container space unless host directories are mounted.

The recommended remediation is to upgrade Atlantis to version 0.45.0 or later. This version incorporates the complete patch set containing the input validation layer and the path containment assertion utilities. Upgrading addresses the root issue across both configuration-based and API-based injection vectors.\n\nIf an immediate upgrade is not possible, administrators should implement temporary mitigation strategies. Access controls should be configured to prevent untrusted contributors from merging or triggering Atlantis runs on pull requests with modified atlantis.yaml files. Enabling the allowed_regexp_images or strict repository policies can also minimize exploitation opportunities.\n\nFurthermore, security teams can audit log files for indicators of abuse. Look for error messages or access logs containing path traversal sequences or configuration schemas referencing unexpected directory paths. Restricting the host process permissions to a non-root, isolated user account limits the damage an attacker can inflict via directory manipulation.