CVE-2026-64679 is a path traversal in Atlantis's workspace handling that warrants more concern than its CVSS 8.1 suggests. The core issue: Atlantis constructs and operates on filesystem paths using user-controlled workspace values before validating those values. This temporal gap means an attacker doesn't just probe for the vulnerability—they cause real filesystem changes with Atlantis's privileges that persist through validation failure.
The critical detail is "reuse writable paths." Atlantis treats workspace directories as persistent resources across operations, not ephemeral per-run contexts. This design choice, reasonable for performance, means a single exploitation plants state that subsequent runs—potentially from different users or repositories—will trust and operate against. If Atlantis serves multiple repositories, an attacker can poison paths that other users' operations will traverse. This elevates the blast radius from single-user impact to multi-tenant integrity compromise.
Post-patch, a significant gap remains unaddressed: the fix closes the vulnerability but doesn't cleanse filesystem artifacts planted during the vulnerable window. Directories or symlinks created via traversal before upgrading to 0.45.0 will exist in trusted workspace paths with no distinguishing marker. Standard upgrade procedures won't catch this. Operators who ran vulnerable versions (0.19.8 through 0.44.x) should audit workspace directories against legitimate repository/branch/workspace combinations rather than assuming the patch erases prior exploitation.
The auditability problem compounds this. Because filesystem operations occur before rejection, there's no error log entry for the rejected workspace name in the success path. An attacker exploiting this leaves minimal forensic trace—you cannot prove a negative about prior exploitation. Organizations that processed pull requests from untrusted or semi-trusted repositories during the vulnerable window should treat the filesystem as potentially compromised and conduct explicit workspace cleanup, not merely upgrade and move on.
On authentication: the /api/plan endpoint and repository-level atlantis.yaml both accept input that drives workspace names. The practical exploit barrier depends on your Atlantis configuration—whether /api/plan requires token authentication and whether repository configuration is limited to trusted committers. Treat any repo configuration path as potentially exploitable if untrusted contributors can open pull requests.