CVE-2026-10055: Eclipse Theia SSRF Vulnerability

CVE-2026-10055 Overview

CVE-2026-10055 is a Server-Side Request Forgery (SSRF) vulnerability in Eclipse Theia starting from version 1.26.0. The backend /services/request-service RPC endpoint accepts attacker-controlled URLs from any client connected to the standard /services messaging endpoint. Theia performs the HTTP request server-side and returns the full response body to the caller. Because the destination URL is neither validated nor allowlisted, remote attackers with access to the Theia service connection can reach localhost or other backend-reachable hosts. This exposes internal administrative endpoints, cloud instance metadata services, and other resources that live behind the browser network boundary.

Critical Impact
Attackers with access to the Theia service connection can issue arbitrary server-side HTTP requests, exfiltrate cloud metadata credentials, and probe internal networks that are otherwise unreachable from the browser.

Affected Products

Eclipse Theia version 1.26.0 and later
Multi-tenant Theia deployments where the service connection is reachable by untrusted users
Publicly-reachable Theia IDE instances exposing the /services endpoint

Discovery Timeline

2026-07-03 - CVE-2026-10055 published to NVD
2026-07-06 - Last updated in NVD database

Technical Details for CVE-2026-10055

Vulnerability Analysis

Eclipse Theia exposes a WebSocket-style RPC channel at /services that connects browser clients to backend services. One of these services, request-service, accepts a URL parameter and performs an HTTP request on behalf of the client. The backend then returns the raw response body, headers, and status to the caller.

The design assumes that only trusted browser clients can reach this endpoint. In multi-tenant or publicly-exposed Theia deployments, that assumption fails. Any client that can open the /services connection can invoke request-service and coerce the server into fetching arbitrary URLs. This weakness is classified as [CWE-200] Exposure of Sensitive Information to an Unauthorized Actor.

Root Cause

The root cause is missing URL validation and lack of an allowlist on the request-service RPC handler. The backend treats the client-supplied URL as trusted input. No filtering is applied for loopback addresses, private IP ranges (RFC 1918), link-local addresses such as 169.254.169.254, or internal DNS names. The service also returns full response bodies, giving attackers direct read access to fetched content.

Attack Vector

An authenticated attacker connects to the /services messaging endpoint over the network. The attacker invokes the request-service RPC with a URL pointing to an internal target. Common targets include:

Cloud instance metadata services such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS or the equivalent endpoints on Azure and GCP
Localhost administrative interfaces bound to 127.0.0.1 on the Theia host
Internal microservices and databases reachable from the backend network segment

The backend performs the request with its own network identity and returns the response body to the attacker. See the GitHub Security Advisory GHSA-2m57-xxmh-v696 for coordinated disclosure details and the GitLab Vulnerability Report #446 for the Eclipse Foundation record.

Detection Methods for CVE-2026-10055

Indicators of Compromise

Outbound HTTP requests originating from the Theia backend process to 169.254.169.254, 127.0.0.1, or RFC 1918 addresses that do not match normal IDE workflows
Access log entries on internal admin services showing the Theia backend as the source of unexpected requests
WebSocket frames on /services invoking request-service with non-standard URL parameters

Detection Strategies

Instrument the Theia backend to log every request-service invocation with the requesting user, target URL, and response size
Deploy egress monitoring that alerts when the Theia host process contacts cloud metadata endpoints or internal management interfaces
Correlate /services RPC traffic with authenticated user sessions to identify anonymous or unexpected callers

Monitoring Recommendations

Forward Theia backend logs and network flow data to a central SIEM for retention and correlation
Alert on any DNS resolution or TCP connection from the Theia backend to metadata service IP ranges
Track baseline traffic patterns for request-service and flag sudden increases in request volume or destination diversity

How to Mitigate CVE-2026-10055

Immediate Actions Required

Restrict network access to the Theia /services endpoint so only authenticated, trusted users can connect
Block egress from the Theia backend to cloud metadata IPs and internal management subnets at the host or network firewall
Audit existing Theia deployments for exposure and rotate any credentials that may have been reachable via SSRF

Patch Information

Refer to the GitHub Security Advisory GHSA-2m57-xxmh-v696 for the fixed version and upgrade instructions. Apply the vendor-supplied patch that enforces URL validation and an allowlist on the request-service handler.

Workarounds

Place Theia behind a reverse proxy that enforces authentication and blocks unauthorized clients from reaching /services
Run the Theia backend with IMDSv2 enforced on AWS or equivalent metadata protections on other clouds to require session tokens
Deploy the Theia backend in a network segment with strict egress filtering that denies traffic to loopback proxies, RFC 1918 ranges, and metadata endpoints

bash

# Example iptables egress restriction for the Theia backend host
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner theia -j DROP