EUVD-2026-92474
GHSA-c4vh-c3rq-3rgr
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege Che user
-
DeliverySubmit file:// or 169.254.169.254 URL to /api/factory/resolver
-
ExploitURLFetcher.fetch opens connection, returns body
-
ExecutionRead K8s service-account token and SCM PAT
-
ImpactPivot to cluster API and cloud metadata
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated Che account (any low-privilege user) able to reach the GET /api/scm/resolve or POST /api/factory/resolver endpoints, which accept an attacker-controlled URL with no scheme or host allow-list. The highest-impact outcomes depend on deployment context: reading the service-account token requires Che running in a Kubernetes pod with the token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, and cloud-metadata theft requires a cloud environment exposing 169.254.169.254 (AWS/GCP/Azure). The PAT-forwarding vector is limited to victims who have a stored SCM personal access token; the devfile variant additionally requires user interaction (the victim opening a workspace from a malicious parent.uri). No vendor fix is available, so mitigation is limited to network egress restrictions and endpoint/access controls. |
| Impact | High-priority, well-corroborated SSRF (CWE-918). The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows remote, low-complexity exploitation requiring only a low-privilege authenticated Che account, with high confidentiality impact on both the vulnerable system (VC:H) and subsequent systems (SC:H) plus subsequent-system integrity (SI:H) from credential forwarding. The real-world severity is amplified by context the raw score understates: the endpoints let an attacker read the pod's Kubernetes service-account token via file:// and reach cloud instance metadata (169.254.169.254), which can escalate into cluster-wide or cloud-account compromise. The devfile parent.uri vector additionally lets a malicious server harvest a victim's SCM PAT with only user interaction (opening a workspace), effectively lowering the auth barrier. Countervailing signals: no EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active exploitation - this is currently a high-impact but not-yet-exploited issue. Most concerning operationally, the vendor states no fix is available, so no patch-based mitigation exists. |
| Exploit ScenarioDerived | A low-privilege authenticated user calls GET /api/scm/resolve or POST /api/factory/resolver with a URL such as file:///var/run/secrets/kubernetes.io/serviceaccount/token, and Che's URLFetcher opens the connection and returns the service-account token in the response body. Alternatively, the attacker publishes a malicious devfile whose parent.uri points to their server and lures a victim into opening the workspace, causing Che to forward the victim's stored SCM personal access token in an Authorization header. No public exploit is identified at time of analysis, but with AV:N/AC:L the attack is mechanically simple. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Server-side request forgery in Eclipse Che 7.29.0 and later allows any authenticated low-privilege user to make the workspace server fetch attacker-chosen URLs through the GET /api/scm/resolve and POST /api/factory/resolver endpoints, which pass the URL to URLFetcher.fetch() without any scheme or host allow-list. Successful abuse yields high confidentiality loss: arbitrary local file reads inside the Che pod (notably the Kubernetes service-account token at file:///var/run/secrets/kubernetes.io/serviceaccount/token), access to internal HTTP services and cloud instance metadata at 169.254.169.254, and delivery of the victim's stored SCM personal access token as an Authorization header to a host of the attacker's choosing; integrity impact is more limited, largely the unauthorized use of forwarded credentials. No vendor-released patch was identified at time of analysis and no public exploit code was identified at time of analysis, though the affected code paths are reachable by any authenticated user. A second, interaction-dependent variant triggers the credential forwarding when a victim opens a workspace from a malicious devfile whose parent.uri points at an attacker-controlled server.
RemediationAI
No vendor-released patch was identified at time of analysis, so remediation must rely on compensating controls. The most effective single control is egress restriction on the Che pod: apply a Kubernetes NetworkPolicy that denies outbound traffic from Che to the link-local address 169.254.169.254 (blocking both the IMDS and any GCP/Azure metadata equivalent), to RFC1918 ranges, and to any host not on an explicit allow-list of required SCM and devfile hosts; the trade-off is that legitimate remote devfile parent.uri resolution and non-allow-listed SCM hosts will break, so the allow-list must be derived from actual workspace templates. Where the deployment runs on AWS, enforce IMDSv2 (token-required) so that simple SSRF GETs to the metadata service fail, though this does not mitigate GCP/Azure metadata or the file:// read. Restrict or disable the affected endpoints by blocking GET /api/scm/resolve and POST /api/factory/resolver at the ingress/reverse proxy for users who do not need them, accepting that this disables SCM URL resolution and factory-based workspace creation. Stop the credential-forwarding vector by removing stored SCM personal access tokens from Che where possible or replacing them with narrowly scoped, short-lived tokens, understanding that this degrades automated SCM integration. Harden the file:// path by setting automountServiceAccountToken: false on the Che service account so the token is not present at /var/run/secrets/kubernetes.io/serviceaccount/token, and grant that service account only the minimum RBAC it needs; the trade-off is that Che components relying on in-cluster API access must be given explicit credentials instead. Finally, restrict workspace creation from untrusted remote devfiles (or disable remote parent.uri resolution entirely) to close the user-interaction variant, and monitor upstream advisories at https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/620 and https://redhat.atlassian.net/browse/CRW-11956 for a patched Che release to replace these mitigations.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This is a classic CWE-918 server-side request forgery rooted in the Java URL handling stack: the vulnerable code calls new URL(url).openConnection() on a caller-supplied string, and because the java.net URL class dispatches on the scheme and the JVM ships handlers for file, http, https, ftp and jar, an attacker-controlled URL can select the file:// protocol and read local paths, or point at RFC1918 hosts and the link-local cloud metadata address 169.254.169.254. Two Che API surfaces are implicated: the SCM resolver (GET /api/scm/resolve) and the factory/devfile resolver (POST /api/factory/resolver), meaning the SSRF is not an isolated utility but part of Che's normal SCM and workspace-provisioning flows. The CPE cpe:2.3:a:eclipse_foundation:eclipse_che:*:*:*:*:*:*:*:* covers the Eclipse Che distribution as the affected product. The additional credential-forwarding behavior is a consequence of Che attaching a user's stored SCM personal access token as an Authorization header to outbound fetches, so an attacker who controls the destination host harvests the token regardless of whether the response body itself is returned. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N) and our independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) agree on network reachability, low-privilege authentication, no user interaction for the direct API path, and scope change with subsequent-system confidentiality impact; the practical severity is context-dependent, since token theft via file:// depends on the token being mounted in the Che pod, metadata theft depends on a cloud environment exposing the metadata service, and PAT exfiltration depends on the victim actually having a stored SCM token.
Know when Eclipse Che gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N
Remote, low-complexity, low-privilege authenticated SSRF (PR:L); reaching service-account tokens and internal/metadata services crosses a security boundary (S:C) with high confidentiality and limited integrity from credential forwarding.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
Lifecycle Timeline
2DescriptionCVE.org
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.
Executive ViewAI
Eclipse Che 7.29.0 and later contains a server-side request forgery flaw (CVE-2026-86671, CVSS 8.4) that lets any low-privilege Che user redirect workspace-side fetches to arbitrary destinations, including internal cluster services, cloud instance metadata, and local files inside the Che pod. Because the exposed data includes Kubernetes service-account tokens and stored SCM personal access tokens, a single compromised or malicious developer account could escalate into broader cloud and source-control access. No vendor patch is available, so leadership should treat this as an unmitigated exposure for as long as Che is running and should weigh that risk against continued developer platform availability.
No vendor-released patch identified at time of analysis. Interim mitigations: enforce egress firewall and Kubernetes NetworkPolicy restrictions on Che pods, block link-local 169.254.169.254 and metadata endpoints (require IMDSv2), restrict and rotate Kubernetes service-account tokens with minimal RBAC, reduce and rotate stored SCM personal access tokens, limit Che access to trusted users, and monitor/alert on anomalous outbound requests from Che workloads.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Exploit-DB