Eclipse Theia CVE-2026-60009

Exploitation requires the victim to visit an attacker-controlled web page while their browser has network connectivity to a running Eclipse Theia backend in browser-mode (non-Electron) deployment - for example, a Theia instance exposed on a company intranet or a cloud development environment accessible over HTTP/HTTPS. The Theia backend must be a browser-mode deployment: Electron deployments are not affected because they enforce a separate ElectronSecurityToken on a different code path. No authentication credentials, session tokens, or prior access to the Theia instance are required - the HTTP middleware bug causes the server to process tokenless multipart POST requests without rejection. No non-default configuration is needed; the vulnerability is present in any default browser-mode Theia ≤1.73.1 deployment with the filesystem backend active. Exploitation is limited by: (1) UI:R - the victim must actively navigate to the attacker's page, making mass exploitation contingent on a phishing or redirect campaign; (2) the backend process must have OS-level write permission to the target path; and (3) RCE escalation via startup-file overwrite (e.g., ~/.bashrc) additionally requires the victim to open a new interactive shell session after the write occurs - the write itself does not achieve immediate code execution.

The CVSS 3.1 score of 8.8 (High) with vector AV:N/AC:L/PR:N/UI:R is well-calibrated for this vulnerability. The sole complexity-reducing factor is UI:R - a victim must actively visit an attacker-controlled page - which is a genuine but modest prerequisite; phishing or malicious ad delivery can satisfy it at scale. No EPSS score was provided in the input data, so exploitation probability cannot be quantified through that signal. No CISA KEV listing is present in the available data, and no public POC code is referenced. Despite the absence of confirmed active exploitation, the attack technique (CORS-safelisted type + HTTP middleware bypass + path traversal) is well-understood and low-complexity; anyone familiar with CORS mechanics can reproduce it. The RCE escalation path via startup-file overwrite (e.g., ~/.bashrc) is realistic but introduces a timing dependency: execution occurs only when the victim opens a subsequent interactive shell session. The S:U (Unchanged scope) designation is appropriate since the file write operates entirely within the backend process's existing privilege boundary. The primary risk-reducing factor for most environments is whether the Theia backend is reachable from untrusted browser contexts; instances bound only to localhost or behind a VPN have substantially reduced exposure. Electron-mode deployments are structurally not vulnerable through this attack path.

An attacker hosts a webpage containing a few lines of JavaScript that auto-submit a multipart/form-data POST to the victim's Theia backend at POST /file-upload, setting the uri field to /home/developer/.bashrc and the file body to a reverse shell one-liner. Because the content type is CORS-safelisted, the victim's browser sends the request the moment the page loads - no preflight, no credentials, no user click beyond visiting the URL. The Theia HTTP middleware passes the request through without token validation, fs.move overwrites ~/.bashrc, and the next time the developer opens a terminal the attacker's payload executes in their shell session.