GHSA-5w5g-j6hw-6p8f

Impact

The console-proxy's RemoteConfigResolver parses kubeconfig data from Kubernetes Secrets using clientcmd.RESTConfigFromKubeConfig without sanitizing the resulting rest.Config. A kubeconfig containing an exec plugin stanza (under users[].user.exec) is faithfully preserved. When rest.TransportFor later builds the HTTP transport for the upstream WebSocket connection, client-go invokes the exec plugin — spawning an arbitrary process as the osac-console-proxy service account.

This allows remote code execution inside the console-proxy pod for any principal that can create or modify a Secret with the label osac.openshift.io/remote-cluster-kubeconfig: "true" in a namespace where the console-proxy has Secret read access (governed by its RoleBinding). A secondary vector exists via attacker-controlled clusters[].server, enabling server-side request forgery (SSRF) from within the proxy pod.

Affected configurations: any deployment using remote or auto VM cluster mode (the default). Deployments using local mode exclusively are not affected, as they do not read kubeconfig Secrets.

Patches

The fix is two lines in internal/consoleproxy/config_resolver.go, applied immediately after clientcmd.RESTConfigFromKubeConfig returns:

config.ExecProvider = nil config.AuthProvider = nil

This is patched in 0.0.4. Users should upgrade to the first release containing this patch once available.

Workarounds

• Restrict Secret creation in the namespace where the osac-console-proxy-secret-reader RoleBinding is deployed. Ensure only trusted principals (cluster admins, operator service accounts) can create or modify Secrets there.
• Switch to local VM cluster mode (--vm-cluster-mode=local) if the KubeVirt VMs run on the same cluster as the proxy. This bypasses the Secret-based kubeconfig lookup entirely.
• Use an admission webhook or OPA policy to reject Secrets containing exec: or auth-provider: stanzas in the kubeconfig data within the affected namespace.