CVE-2026-86671: SSRF
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.
Affected Software
Event History
Frequently Asked Questions
Does direct exploitation require administrator privileges?
No. Any authenticated Eclipse Che user can use the affected API endpoints to supply a URL; administrator privileges are not required.
What can an attacker access from the Che environment?
They can read local files using file:// URLs, including the pod's Kubernetes service-account token, and can reach internal HTTP services and cloud metadata endpoints such as 169.254.169.254. The response body is returned to the caller.
Can this expose SCM personal access tokens?
Yes. Che can attach a stored SCM personal access token as an Authorization header when fetching a URL controlled by the attacker. A malicious devfile parent.uri can also trigger this behavior when a victim opens the workspace, potentially exfiltrating that victim's SCM token.
Is a fix available?
No fix is available according to the provided vulnerability information.