Eclipse Theia CVE-2026-10055

Requires the Theia /services messaging endpoint (specifically the backend /services/request-service RPC) to be network-reachable by the attacker, and the attacker must hold a standard low-privilege connection to that service (CVSS PR:L, so authenticated at a low level per the vector). The decisive prerequisite is a deployment where the service connection is exposed to untrusted users - multi-tenant or publicly-reachable Theia installations. Exploitation is limited (not eliminated) by network isolation: single-user desktop or localhost-bound Theia instances, or deployments that firewall the /services port from untrusted clients, are not practically reachable. No user interaction is needed (UI:N), and no non-default feature toggle is required because request-service ships as a standard backend service; the URL is accepted without validation by default.

The vendor CVSS 3.1 score of 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) reflects a network-reachable, low-complexity attack requiring only low privilege (any connected /services client) with a changed scope, since the impact reaches backend resources beyond the vulnerable component. This is a credible, real risk specifically for exposed multi-tenant or internet-facing Theia deployments, where SSRF against cloud metadata (e.g. 169.254.169.254) can yield IAM credentials - a high-value pivot. However, the risk is conditional: single-user, localhost-only, or properly network-isolated Theia installs face little exposure because the attacker must first reach the service connection. No EPSS score, KEV entry, or POC is present in the provided data, so exploitation probability signals are absent rather than low - treat the network/metadata exposure as the dominant risk driver, not raw score. The C:H/I:L rating aligns with a read-oriented SSRF; without SSVC or EPSS inputs, prioritization should hinge on whether a given deployment is reachable by untrusted users.

An untrusted user on a shared, internet-facing Theia instance connects to the /services endpoint and invokes request-service with a URL of http://169.254.169.254/latest/meta-data/iam/security-credentials/, receiving the cloud instance's temporary IAM credentials in the response body. They then reuse those credentials to access cloud resources, or point the same request-service at http://localhost admin panels to read configuration otherwise hidden behind the network boundary. No public exploit is identified at time of analysis, but the attack requires only a standard service connection and a crafted URL.