Eclipse Che: authenticated SSRF in devfile URL fetching leaks the pod service-account token

Impact

Any authenticated Che user can make the Che server fetch a URL of their choosing and return the body, with no scheme or host allow-list. Via file:// that reads arbitrary files inside the Che server pod, including /var/run/secrets/kubernetes.io/serviceaccount/token - on a GPU cluster that token is a foothold into the same Kubernetes API that schedules every tenant's accelerator workloads. The same path reaches internal-only HTTP services and the cloud instance metadata endpoint at 169.254.169.254, so node-level cloud credentials are in range too. Che also attaches the caller's stored SCM personal access token as an Authorization header to the fetched host, and the same forwarding fires when a victim opens a workspace from a malicious devfile whose parent.uri points at an attacker server, so a developer's Git credentials can be exfiltrated without the attacker having API access at all. Affects 7.29.0 and later; the record states no fix is available.

Who can reach it

Any user with a Che account can call the two REST endpoints directly (authentication required, lowest privilege level is enough). The credential-forwarding variant needs only that a victim Che user opens a workspace built from an attacker-supplied devfile.

What to do

No fix is published. Mitigate: keep the Che/Dev Spaces route off any network an untrusted tenant can reach, restrict egress from the Che server pod so file-less targets like 169.254.169.254 and internal services are unreachable, and scope the Che server's service account down to the minimum it needs so a stolen token buys little. Rotate any SCM personal access tokens stored in Che if you suspect use, and watch the Red Hat tracker (CRW-11956) and the Eclipse vulnerability report for a patched release. No node drain or reboot is involved - this is a platform-level service, not a kernel or firmware change.

References

Related entries

• Gradio: CORS origin validation bypassCVE-2024-47084 · GradioHigh
• vLLM: --revision pin ignored for some FunAudioChat and Tarsier2 processor, tokenizer and config loadsCVE-2026-100653 · vLLM (revision pin not propagated to FunAudioChat and Tarsier2 Hugging Face artifact loads)High
• Dagster: Vulnerability in Dagster Core prior to 1.13.1CVE-2026-41490 · DagsterHigh
• Gitingest: prefix-only host validation lets crafted URLs leak GitHub tokens to attacker hostsCVE-2026-82289 · Gitingest (_validate_host git host allowlist)High
• TorchServe (gRPC 7070/7071): gRPC ports bound to all interfaces regardless of configCVE-2024-35199 · TorchServe (gRPC 7070/7071)High
• Ollama (GGUF parser): Malformed 4-byte GGUF file crashes the server (two HTTP requests)CVE-2024-39720 · Ollama (GGUF parser)High