CVE-2026-62284

OSAC operator is a Kubernetes operator. In the affected revision identified as 8220502, the console-proxy RemoteConfigResolver parses Kubernetes Secret kubeconfig data with clientcmd.RESTConfigFromKubeConfig without sanitizing the resulting rest.Config. An attacker who can create or modify a Secret labeled osac.openshift.io/remote-cluster-kubeconfig: "true" in a namespace where the proxy's RoleBinding grants Secret read access can supply users[].user.exec. When rest.TransportFor builds the HTTP transport for an upstream WebSocket connection, client-go invokes that exec credential plugin, spawning an arbitrary process as the osac-console-proxy service account inside the pod. Attacker-controlled clusters[].server also enables server-side request forgery from the proxy pod. Remote and auto VM cluster modes are affected, with auto the default; exclusively local mode does not read kubeconfig Secrets and is unaffected. The credential-plugin execution path is patched in commit 7e4222b; that patch does not address the described server-address SSRF path.

OSAC operator: Kubeconfig credential-plugin execution and SSRF in console proxy

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.

OSAC operator is a Kubernetes operator. In the affected revision identified as 8220502, the console-proxy RemoteConfigResolver parses Kubernetes Secret kubeconfig data with clientcmd.RESTConfigFromKubeConfig without sanitizing the resulting rest.Config. An attacker who can create or modify a Secret labeled osac.openshift.io/remote-cluster-kubeconfig: "true" in a namespace where the proxy's RoleBinding grants Secret read access can supply users[].user.exec. When rest.TransportFor builds the HTTP transport for an upstream WebSocket connection, client-go invokes that exec credential plugin, spawning an arbitrary process as the osac-console-proxy service account inside the pod. Attacker-controlled clusters[].server also enables server-side request forgery from the proxy pod. Remote and auto VM cluster modes are affected, with auto the default; exclusively local mode does not read kubeconfig Secrets and is unaffected. The credential-plugin execution path is patched in commit 7e4222b; that patch does not address the described server-address SSRF path.

OSAC operator is a Kubernetes operator. In the affected revision identified as 8220502, the console-proxy RemoteConfigResolver parses Kubernetes Secret kubeconfig data with clientcmd.RESTConfigFromKubeConfig without sanitizing the resulting rest.Config. An attacker who can create or modify a Secret labeled osac.openshift.io/remote-cluster-kubeconfig: "true" in a namespace where the proxy's RoleBinding grants Secret read access can supply users[].user.exec. When rest.TransportFor builds the HTTP transport for an upstream WebSocket connection, client-go invokes that exec credential plugin, spawning an arbitrary process as the osac-console-proxy service account inside the pod. Attacker-controlled clusters[].server also enables server-side request forgery from the proxy pod. Remote and auto VM cluster modes are affected, with auto the default; exclusively local mode does not read kubeconfig Secrets and is unaffected. The credential-plugin execution path is patched in commit 7e4222b; that patch does not address the described server-address SSRF path.

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.