Two Critical Bugs Put AI Coding Assistants Back on the File Boundary
A security alert about Cursor shows how an AI editor can turn a path-handling flaw into a dangerous filesystem integrity problem, even without confirmed exploitation.
An AI coding assistant is only as safe as the paths it is allowed to touch. That is why two critical vulnerabilities flagged in Cursor matter beyond the product itself: if a flaw lets an attacker influence where files are written, the risk shifts from a simple software bug to an integrity problem for code, configs, and developer workspaces.
Fast Facts
- ACN CSIRT Italia published an alert about two new critical vulnerabilities in Cursor.
- The reported impact is limited to a conditional risk: arbitrary file writes on affected systems may be possible if the bugs are exploited.
- Cursor is an AI-based code editor, which makes filesystem access a security boundary, not just a convenience feature.
- The described effect is consistent with the broader CWE-73 family of path and filename control weaknesses.
- Public information does not yet establish affected versions, active exploitation, or any confirmed downstream compromise.
Why a file-write bug is a big deal
The core issue is not merely that an editor has bugs. It is that modern AI-assisted development tools often operate on a large trust surface: they can inspect project files, generate edits, and in some workflows interact with multiple parts of a workspace. If a vulnerability breaks the intended file boundary, an attacker may be able to steer writes toward locations the user did not expect.
That is why the reported impact matters. Arbitrary or unexpected file writes can corrupt source code, alter configuration files, or tamper with automation artifacts. The exact consequence depends on what paths are reachable and what privileges the process has. In the worst-case pattern, a file-write issue can become a stepping stone to persistence or further compromise if sensitive startup or build files are touched, but that is a risk analysis, not a confirmed outcome here.
From a defensive perspective, this kind of bug is a reminder that AI tools need the same discipline as any other privileged software component. Path canonicalization, write scoping, low-privilege execution, and sandboxing all matter. So does human review: automated file changes should not be accepted blindly, especially in environments that handle secrets, build scripts, or deployment material.
At the time of writing, the available information supports a risk analysis, not a definitive statement about exploit method, remote reachability, or real-world abuse. That caution is important. The technical lesson is still clear: when an AI editor can touch files, the filesystem becomes part of the attack surface.
Conclusion
The broader lesson is simple. In AI-assisted development, convenience and privilege travel together. A vulnerability that affects file handling may look narrow on paper, but in practice it can undermine the trust model of an entire workspace. Security teams should treat these tools as high-value endpoints: constrain writes, review changes, and assume that path control is a boundary worth defending.
TECHCROOK
External backup drive: Keeping offline backups of code, configs, and workspace files makes recovery easier if an editor bug or bad automated change overwrites something important. A simple local backup also helps with version rollback and audit checks.
WIKICROOK
- CWE-73: A weakness class involving external control of file names or paths, which can lead to unexpected file operations.
- Filesystem integrity: The property that files and directories are modified only in intended, authorized ways.
- Path canonicalization: The process of resolving a path into its true normalized form to reduce ambiguity and traversal risk.
- Least privilege: A security principle that limits software to only the permissions it needs to function.
- Sandboxing: Running software in a restricted environment to limit the impact of bugs or malicious input.
