Eclipse Che

Eclipse Che 7.29+ Local File Read & Credential Leak via /api/scm/resolve
CVE-2026-86671 8.4 - High - October 05, 2026

In Eclipse Che versions 7.29.0 and later, the GET `/api/scm/resolve` and `POST /api/factory/resolver` endpoints pass an attacker-controlled URL to `URLFetcher.fetch()`, which calls `new URL(url).openConnection()` with no scheme or host allow-list and returns the response body to the caller. Any authenticated Che user can read arbitrary local files via the file:// scheme (including the pod's Kubernetes service-account token at `file:///var/run/secrets/kubernetes.io/serviceaccount/token`), reach internal HTTP services and cloud instance metadata endpoints (169.254.169.254), and have their stored SCM personal access token attached as an `Authorization` header to a host of their choosing. The same credential-forwarding behavior also fires when a victim opens a workspace from a malicious devfile whose `parent.uri` points to an attacker-controlled server, enabling exfiltration of the victim's SCM PAT without direct API access. No fix is available.

SSRF

Eclipse Che 7.797.122 SSRF /dashboard/api/data/resolver (fixed 7.122)
CVE-2026-86590 6.3 - Medium - September 08, 2026

In Eclipse Che versions 7.79.0 through 7.121.0, the dashboard backend's POST /dashboard/api/data/resolver endpoint passes a caller-supplied URL directly to an outbound HTTP GET request with no host filtering. An authenticated user can exploit this server-side request forgery (SSRF) to read responses from internal network addresses, including the cloud instance metadata service (169.254.169.254), loopback interfaces, RFC-1918 private ranges, and in-cluster Kubernetes services. The operator-configured allowlist (spec.devEnvironments.allowedSources.urls) is not consulted. The vulnerability is fixed in version 7.122.0, which adds private-address blocking, IPv4-mapped IPv6 bypass prevention, operator allowlist enforcement, and disables HTTP redirects on the outbound request.

SSRF

The build of some language stacks of Eclipse Che version 6 includes pulling some binaries from an unsecured HTTP endpoint
CVE-2021-41034 8.1 - High - September 29, 2021

The build of some language stacks of Eclipse Che version 6 includes pulling some binaries from an unsecured HTTP endpoint. As a consequence the builds of such stacks are vulnerable to MITM attacks that allow the replacement of the original binaries with arbitrary ones. The stacks involved are Java 8 (alpine and centos), Android and PHP. The vulnerability is not exploitable at runtime but only when building Che.

Improper Enforcement of Message Integrity During Transmission in a Communication Channel

A flaw was found in Eclipse Che in versions prior to 7.14.0 that impacts CodeReady Workspaces
CVE-2020-14368 7.1 - High - December 14, 2020

A flaw was found in Eclipse Che in versions prior to 7.14.0 that impacts CodeReady Workspaces. When configured with cookies authentication, Theia IDE doesn't properly set the SameSite value, allowing a Cross-Site Request Forgery (CSRF) and consequently allowing a cross-site WebSocket hijack on Theia IDE. This flaw allows an attacker to gain full access to the victim's workspace through the /services endpoint. To perform a successful attack, the attacker conducts a Man-in-the-middle attack (MITM) and tricks the victim into executing a request via an untrusted link, which performs the CSRF and the Socket hijack. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

Session Riding

A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods
CVE-2020-10689 6.8 - Medium - April 03, 2020

A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod.

For Eclipse Che versions 6.16 to 7.3.0
CVE-2019-17633 - December 19, 2019

For Eclipse Che versions 6.16 to 7.3.0, with both authentication and TLS disabled, visiting a malicious web site could trigger the start of an arbitrary Che workspace. Che with no authentication and no TLS is not usually deployed on a public network but is often used for local installations (e.g. on personal laptops). In that case, even if the Che API is not exposed externally, some javascript running in the local browser is able to send requests to it.

Session Riding