CVE-2026-86671: Eclipse Che SSRF Vulnerability

CVE-2026-86671 Overview

CVE-2026-86671 is a Server-Side Request Forgery (SSRF) and arbitrary file read vulnerability in Eclipse Che versions 7.29.0 and later. The flaw resides in the GET /api/scm/resolve and POST /api/factory/resolver endpoints, which pass attacker-controlled URLs directly to URLFetcher.fetch(). The underlying new URL(url).openConnection() call enforces no scheme or host allow-list. Any authenticated Che user can read local files via the file:// scheme, reach internal services and cloud metadata endpoints, and have their stored Source Control Management (SCM) personal access token forwarded to attacker-controlled hosts. The weakness is tracked under [CWE-73: External Control of File Name or Path].

Critical Impact
Authenticated attackers can exfiltrate the pod's Kubernetes service-account token, pivot to cloud instance metadata at 169.254.169.254, and steal SCM personal access tokens without any patch available.

Affected Products

Eclipse Che 7.29.0 and later
Deployments exposing /api/scm/resolve and /api/factory/resolver endpoints
Red Hat CodeReady Workspaces (tracked internally as CRW-11956)

Discovery Timeline

2026-10-05 - CVE-2026-86671 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-86671

Vulnerability Analysis

The vulnerability stems from unsafe URL handling in Eclipse Che's workspace resolution APIs. Both GET /api/scm/resolve and POST /api/factory/resolver accept a URL parameter from authenticated users and forward it to URLFetcher.fetch(). That helper constructs a Java URL object and calls openConnection() without validating the scheme or the destination host. The raw response body is then returned to the caller.

Because Java's URL class natively supports file://, http://, https://, ftp://, and jar:// schemes, an attacker can direct the server to read arbitrary local resources. In a containerized deployment, the Kubernetes service-account token at file:///var/run/secrets/kubernetes.io/serviceaccount/token is exposed. Internal HTTP services and cloud instance metadata endpoints such as 169.254.169.254 on AWS, Azure, and GCP are also reachable.

A second exploitation path triggers when a victim opens a workspace from a malicious devfile whose parent.uri references an attacker server. Che attaches the user's stored SCM personal access token (PAT) as an Authorization header to the outbound request, leaking the credential without any direct API interaction by the attacker.

Root Cause

The root cause is missing input validation on the URL parameter passed to URLFetcher.fetch(). There is no scheme allow-list, no host allow-list, no redirect handling policy, and no stripping of credential headers when the request target differs from the configured SCM host.

Attack Vector

Exploitation requires network access to the Che API and valid user authentication. An attacker with low privileges issues a request to /api/scm/resolve or /api/factory/resolver supplying a crafted URL such as file:///var/run/secrets/kubernetes.io/serviceaccount/token or http://169.254.169.254/latest/meta-data/iam/security-credentials/. The response body is returned directly. For PAT exfiltration, the attacker hosts a malicious devfile referenced via parent.uri and waits for a victim to load the workspace.

// Vulnerability mechanism (prose description - no verified PoC published)
// The vulnerable call pattern inside URLFetcher.fetch():
//   URLConnection conn = new URL(userControlledUrl).openConnection();
//   // No scheme check, no host allow-list, no header scrubbing on redirect
//   return readBody(conn);

Detection Methods for CVE-2026-86671

Indicators of Compromise

Access log entries for /api/scm/resolve or /api/factory/resolver containing file://, 169.254.169.254, localhost, or RFC1918 addresses in query parameters or request bodies.
Outbound HTTP requests from Che pods to unexpected external hosts carrying an Authorization: Bearer or Authorization: token header.
Devfile parent.uri values pointing to domains outside the organization's approved SCM providers.
Unexpected reads of /var/run/secrets/kubernetes.io/serviceaccount/token initiated by the Che workspace controller process.

Detection Strategies

Instrument the Che reverse proxy or ingress to log the full URL parameter submitted to resolver endpoints and alert on non-HTTPS schemes.
Deploy egress network policies that log and alert when Che pods contact cloud metadata IPs or non-SCM external hosts.
Correlate authenticated Che user activity with outbound API calls to detect SSRF patterns originating from a specific session.

Monitoring Recommendations

Forward Che application logs, Kubernetes audit logs, and egress NetFlow into a centralized data lake for correlation.
Monitor for anomalous use of SCM PATs including authentication attempts from unexpected IP ranges.
Track devfile submissions and flag any parent.uri host that has not previously been observed in your environment.

How to Mitigate CVE-2026-86671

Immediate Actions Required

Restrict network access to the Eclipse Che API to trusted users and networks until a vendor patch is published.
Enforce Kubernetes NetworkPolicy rules preventing Che pods from reaching 169.254.169.254 and other internal management endpoints.
Rotate any SCM personal access tokens that may have been loaded by users on affected deployments.
Review Kubernetes service-account token scope and apply least privilege to the Che workspace service account.

Patch Information

No fix is currently available. Monitor the Eclipse GitLab Vulnerability Report and the Eclipse GitLab CVE Assignment for updates. Red Hat customers should track the Red Hat Issue Tracker Entry for CodeReady Workspaces guidance.

Workarounds

Place an authenticating reverse proxy in front of Che that blocks requests to /api/scm/resolve and /api/factory/resolver containing non-HTTPS URLs or private IP ranges.
Disable or restrict the factory and SCM resolver features for users who do not require them.
Use projected service-account tokens with short lifetimes and audience binding to reduce the value of a stolen token.
Instruct users to only open workspaces from trusted devfile sources and review parent.uri entries before loading.

bash

# Example Kubernetes NetworkPolicy blocking Che pods from cloud metadata
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: che-block-metadata
  namespace: eclipse-che
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/part-of: che.eclipse.org
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32
              - 169.254.170.2/32
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16