CVE-2026-60009 in Theia
Summary
by MITRE • 08/05/2026
In Eclipse Theia versions up to and including 1.73.1, the `@theia/filesystem` backend binds `POST /file-upload` in every filesystem-enabled deployment. The handler takes an attacker-supplied absolute path from the multipart `uri` field and calls `fs.move(tmp, target, { overwrite: true })` with no workspace confinement and no authentication. In browser (non-Electron) deployments the connection token is enforced only on WebSocket upgrades; the HTTP middleware in `@theia/core` re-issues the cookie and calls `next()` without rejecting tokenless HTTP requests. Because `multipart/form-data` is a CORS-safelisted request type, a cross-origin web page can trigger the write with no preflight and no credentials, resulting in an unauthenticated arbitrary file write outside the workspace to any absolute path the backend process can write. This can escalate to remote code execution, for example by overwriting a startup-executed file such as `~/.bashrc`. Electron mode uses a separate `ElectronSecurityToken` and is not affected via this path.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability identified in Eclipse Theia versions up to 1.73.1 represents a critical authentication bypass and arbitrary file write flaw within the filesystem backend component. This issue affects deployments that utilize the @theia/filesystem package, specifically exposing a POST endpoint at /file-upload that processes multipart form data without proper access controls or workspace boundaries. The flaw stems from the backend implementation's failure to validate or constrain file paths submitted through the uri field in the multipart request, allowing attackers to specify absolute paths outside of the intended workspace scope.
The technical execution of this vulnerability leverages the absence of proper authentication enforcement within the HTTP middleware layer of @theia/core. While WebSocket connections properly enforce connection tokens, the HTTP request handling does not reject requests lacking valid authentication credentials, instead re-issuing cookies and proceeding with request processing through next() calls. This creates a fundamental inconsistency in the security model where HTTP endpoints remain accessible without proper authentication while WebSocket endpoints maintain their protective measures.
The exploitation becomes possible due to the CORS-safelisted nature of multipart/form-data requests, which eliminates the need for preflight checks or credential requirements when originating from cross-origin contexts. This means that any web page hosted on a different origin can directly trigger the file upload endpoint without requiring additional authentication steps or credential handling. The lack of workspace confinement combined with the ability to specify absolute paths allows attackers to write files anywhere the backend process has write permissions, potentially extending to system-level directories and configuration files.
This vulnerability maps directly to CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-73 (External Control of File Name or Path) while aligning with ATT&CK technique T1059.007 (Command and Scripting Interpreter: Python) through potential exploitation paths involving startup script modifications. The impact extends beyond simple file modification to full remote code execution capabilities when attackers target system startup files such as ~/.bashrc, which would be executed during user sessions, providing persistent access.
Mitigation strategies should focus on implementing proper authentication enforcement for all HTTP endpoints, establishing strict path validation and workspace confinement for file operations, and ensuring that the HTTP middleware consistently enforces security tokens across all request types. The fix requires modifying the @theia/core middleware to reject tokenless HTTP requests, implementing absolute path validation that prevents writes outside of designated workspace boundaries, and ensuring that the filesystem backend performs proper access control checks before executing any file operations. Additionally, deployments should consider disabling the file upload endpoint entirely when not required, or restricting it to authenticated users with appropriate privileges within a controlled workspace environment.