Eclipse Theia EUVD-2026-41529

Exploitation requires that the victim have a running Eclipse Theia browser-backend (1.8.1+) reachable from their browser AND that they visit an attacker-controlled web page while it is running - that user interaction (UI:R) is the primary prerequisite and the main limiting factor. No authentication is needed (PR:N/unauthenticated) and the default configuration is vulnerable because no THEIA_HOSTS allowlist is set, so the fail-open Origin check accepts connections with a missing Origin, and the Socket.IO fix-origin header lets an attacker override any real Origin value. What limits exploitation: the attacker must know or guess the Theia backend address/port and the victim must be actively running an instance; deployments that already set a strict THEIA_HOSTS allowlist AND sit behind authentication that the /services namespace enforces are not exposed in the same drive-by manner. There are no exotic feature flags required - the vulnerable path is the standard shell-terminal service in a default install.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8) is internally consistent with the description: network-reachable, low complexity, no authentication (PR:N, so unauthenticated), but requiring the victim to visit an attacker-controlled page (UI:R) with full RCE impact across confidentiality, integrity, and availability. The dominant limiting signal is UI:R - this is a drive-by / social-engineering attack, not a self-propagating remote exploit, which is why it lands at 8.8 rather than a 9.8 pre-auth RCE. No EPSS score, KEV listing, or POC was provided: it is not on CISA KEV and no public exploit was identified at time of analysis, so exploitation is plausible-but-unproven. An SSVC read would be roughly Exploitation:none, Automatable:no (needs a victim to visit a page), Technical Impact:total - supporting a serious-but-not-emergency prioritization. The realistic risk is genuine because the default configuration is vulnerable (no THEIA_HOSTS allowlist) and the class of bug is well understood and reliably exploitable once a victim is lured; this is a real priority for anyone running Theia-based tooling, not an inflated high-CVSS-but-low-real-risk finding, though the absence of a shipped patch tempers immediate options.

An attacker hosts a malicious web page containing JavaScript that opens a WebSocket to a developer's locally running Theia backend (e.g. ws://localhost:3000/services), omitting or spoofing the Origin/fix-origin header to pass the fail-open check. When a developer with a live Theia instance visits the page, the script invokes shell-terminal creation, attaches to the terminal data channel, runs arbitrary OS commands, and exfiltrates their output back to the attacker. No public exploit code was identified at time of analysis, but the attack is low-complexity and requires only that the victim load the page (UI:R).