GPU VulnDB

Database/Container, Kubernetes & orchestration

OpenShift Console: tenant-planted Helm repository makes the console pod fetch arbitrary URLs server-side

CVE-2026-50237Container, Kubernetes & orchestrationcurated

Impact

A tenant who can create a ProjectHelmChartRepository in their own namespace supplies an arbitrary URL that the console pod then fetches on their behalf. The request leaves from the console pod's network position rather than the tenant's, which bypasses tenant egress restrictions and reaches internal endpoints a workload pod cannot — cluster services, metadata endpoints, anything the console can route to. The catalog metadata that comes back is attacker-controlled, so if an administrator later installs a chart from that poisoned catalog the tenant gains privileges they were never granted. CVSS scopes it as Changed for exactly that reason. On a multi-tenant GPU cluster the console typically runs in the control-plane network, which is the part tenants are supposed to be kept out of.

Who can reach it

Any authenticated user with namespace-level rights to create a ProjectHelmChartRepository. The SSRF and egress bypass need only that; the privilege-escalation step additionally requires an administrator to install a chart from the poisoned catalog.

What to do

Apply the OpenShift errata for your minor release (RHSA-2026:54206 and the follow-on advisories cover 4.12 and 4.18 through 4.22). The console operator rolls out replacement console pods — no node drain or reboot. Until patched, restrict who can create ProjectHelmChartRepository objects in tenant namespaces.

References

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.