CVE-2026-86590 in Che
Summary
by MITRE • 09/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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The security flaw identified in Eclipse Che versions ranging from 7.79.0 through 7.121.0 constitutes a critical Server-Side Request Forgery vulnerability within the dashboard backend component. This issue specifically affects the POST /dashboard/api/data/resolver endpoint, which is designed to process user-supplied URLs for data resolution purposes. The core technical deficiency lies in the application's failure to implement adequate input validation or host filtering mechanisms before initiating outbound HTTP GET requests. When an authenticated user submits a URL via this endpoint, the backend directly forwards it without verifying whether the target address belongs to internal network ranges, loopback interfaces, or cloud provider metadata services. This lack of restriction allows attackers to manipulate the destination of server-side requests, effectively turning the application into a proxy for accessing resources that should be inaccessible from external networks.
The operational impact of this vulnerability is severe due to its ability to facilitate access to sensitive internal infrastructure components. Attackers can leverage this flaw to read responses from cloud instance metadata services located at addresses such as 169.254.169.254, which often contain authentication tokens and configuration details critical for maintaining the integrity of cloud environments. Furthermore, the vulnerability enables access to loopback interfaces and RFC-1918 private IP ranges, allowing adversaries to probe internal Kubernetes services that are not exposed publicly. This capability can lead to unauthorized data exfiltration, lateral movement within the cluster, or further exploitation of other vulnerabilities present on internal endpoints. The severity is compounded by the fact that existing security controls, specifically the operator-configured allowlist defined in spec.devEnvironments.allowedSources.urls, are completely ignored during this process. Consequently, even if administrators have attempted to restrict outbound traffic sources through configuration settings, these measures provide no protection against SSRF attacks targeting internal addresses via this specific endpoint.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery and is associated with MITRE ATT&CK technique T1502 which involves the use of cloud infrastructure services for lateral movement or data access. The failure to enforce allowlists also points to weaknesses in input validation logic typically categorized under CWE-20 Improper Input Validation. To mitigate this risk, organizations must upgrade immediately to Eclipse Che version 7.122.0 or later. This updated release addresses the root causes by implementing strict private-address blocking and preventing IPv4-mapped IPv6 bypass techniques that attackers might use to evade basic filters. Additionally, it enforces operator-configured allowlists as intended and disables HTTP redirects on outbound requests, thereby closing common evasion paths used in SSRF attacks. Until an upgrade is performed, administrators should consider network-level restrictions such as firewall rules or egress proxies to limit the dashboard backend's ability to reach internal IP ranges, although this serves only as a compensating control rather than a complete fix for the application logic flaw.