Eclipse Che dashboard backend (POST /dashboard/api/data/resolver): The dashboard backend passes a user-supplied URL

CVSS 6.3CVE-2026-86590AI/ML frameworks & servingcurated

Impact

The dashboard backend passes a user-supplied URL straight into an outbound HTTP GET with no host filtering, so any authenticated Che user can read responses from the cloud instance metadata service at 169.254.169.254, loopback, RFC-1918 ranges and in-cluster Kubernetes services. On a cluster where the Che pod runs with an instance profile or workload identity, that is a direct path to cloud credentials for the whole node pool, and to unauthenticated internal APIs a developer workspace was never meant to reach. The operator-configured allowlist (spec.devEnvironments.allowedSources.urls) is not consulted, so a deployment that looks locked down is not. Che sits on the same clusters that host GPU workspaces, where the reachable internal surface includes the scheduler and registry.

Who can reach it

Any user who can authenticate to the Che dashboard - typically every developer with a workspace - reaching it over the normal HTTPS route. No cluster credentials or pod access required.

What to do

Upgrade to Eclipse Che 7.122.0, which blocks private addresses, prevents the IPv4-mapped IPv6 bypass, enforces the operator allowlist and disables redirects on the outbound request. This is a controller-driven rolling restart of the dashboard deployment - no node drain. Until then, restrict egress from the dashboard pod with a NetworkPolicy and require IMDSv2 or equivalent hop-limited metadata access on the nodes.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-86590 https://github.com/eclipse-che/che-dashboard/pull/1655 https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/617

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.