Eclipse Theia CVE-2026-61891

Exploitation requires the target to be running Eclipse Theia in browser (non-Electron) deployment mode - this is the critical deployment condition, as Electron builds use a separate ElectronSecurityToken mechanism and are explicitly not affected. The Theia HTTP backend must be directly reachable from the attacker over the network; if the backend is bound to localhost only, sits behind a correctly configured reverse proxy that enforces authentication on all HTTP paths (not just WebSocket), or is firewalled from untrusted networks, exploitation is blocked. No authentication is required, no special configuration beyond a standard browser-mode deployment is needed, and no user interaction is involved - confirmed by the CVSS vector AV:N/AC:L/PR:N/UI:N. The sole limiting factor is deployment mode: Electron-mode operators are not exposed, and any deployment protected by a network-layer authentication control that covers plain HTTP will not be exploitable via this path.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, score 7.5) is well-calibrated to the browser-mode attack surface: network-reachable, no authentication, low complexity, high confidentiality impact, with no integrity or availability consequence. Real-world risk is highly deployment-topology-dependent. Browser-mode Theia instances exposed to untrusted networks - including cloud-hosted IDE platforms, shared CI/CD pipeline runners, and developer sandboxes - face serious risk of credential theft that could cascade into broader infrastructure compromise. Electron desktop installs are categorically unaffected and should not factor into prioritisation. EPSS data was not supplied; given the targeted IDE context and the absence of a KEV listing or public POC, widespread automated exploitation is not anticipated, but the zero-prerequisite unauthenticated HTTP path makes independent rediscovery and exploitation trivial for a motivated attacker with network access. Organisations running internet-facing or multi-tenant browser-mode Theia deployments should treat this as high priority. Private, localhost-only, or reverse-proxy-protected deployments face materially reduced exposure.

An attacker identifies an internet-facing Eclipse Theia browser-mode instance and issues a direct HTTP GET request to the /file endpoint with a URI parameter pointing to a sensitive file outside the workspace, such as file:///root/.ssh/id_rsa. The @theia/core middleware passes the request without token validation, and the @theia/filesystem backend resolves the path and streams the private key back to the attacker. The attacker then uses the harvested SSH key or cloud credential token to pivot into backend infrastructure.