CVE-2026-73843: Critical Missing Authentication and Privilege Escalation in OpenChoreo Cluster Gateway

OpenChoreo is a developer platform for Kubernetes that coordinates remote tenant workloads. The platform establishes secure communication channels using remote agents deployed in target data-plane clusters. These agents initiate persistent WebSocket links to a centralized cluster-gateway component. The gateway must expose a public TCP port to allow inbound traffic from geographically separated Kubernetes clusters.

The primary architectural flaw in OpenChoreo prior to versions 1.0.2 and 1.1.2 is the concentration of multi-sphere routes on a single public-facing socket. The cluster-gateway initialized a unified TCP listener to serve both agent connectivity and administrative operations. By exposing this gateway port to the network to facilitate agent connections, administrative control-plane endpoints were exposed to the same network audience.

This Exposure of Resource to Wrong Sphere (CWE-668) results in complete authentication bypass for critical operations (CWE-306). Remote unauthenticated network actors situated on adjacent network paths can leverage these administrative paths to interact with the managed data-plane clusters. The vulnerability manifests primarily on TCP port 8443, exposing the cluster gateway to complete unauthorized takeover.

The root cause of CVE-2026-73843 lies in the unified HTTP routing multiplexer implementation inside the cluster-gateway subsystem. The Go application utilized a single http.ServeMux to handle incoming HTTP requests on the designated public gateway port (defaulting to 8443). The multiplexer registered public-facing WebSocket routes (/ws) alongside highly privileged control plane and proxy endpoints (/api/*) on the same listener configuration.

The platform's logical boundaries dictate that data-plane agents connect to /ws, while administrative services query the /api/* endpoints. Because the multiplexer evaluated all request paths against the same socket, there was no logical separation at the network layer. Consequently, any network interface permitted to send WebSocket initiation packets could also issue HTTP requests targeting the /api/ routing paths.

Furthermore, the internal handlers for /api/proxy/ and /api/exec/ lacked any software-level authentication checks, cryptographic handshakes, or role-based access validation. This structural omission assumed that any traffic reaching these paths originated from within a trusted perimeter. When multi-cluster deployments forced the exposure of port 8443 to the wider network, this trust assumption failed, leading to direct access to high-privilege execution vectors.

Prior to the application of the remediation patch, the initialization of the HTTP server inside internal/cluster-gateway/server.go was configured to use a single router instance. Review of the vulnerable codebase shows that the Go HTTP handler routed traffic to /ws, /api/proxy/, /api/exec/, and /api/wirelogs/ through a single server instance. The registration of routes on the unified multiplexer did not implement any middleware validation or authorization filters.

// VULNERABLE CODE - internal/cluster-gateway/server.go
mux := http.NewServeMux()
mux.HandleFunc("/ws", s.handleWebSocket)          // Public agent endpoint
mux.HandleFunc("/api/proxy/", s.handleHTTPProxy)   // Unauthenticated HTTP proxy to Kubernetes API
mux.HandleFunc("/api/exec/", s.handleExec)         // Unauthenticated WebSocket remote command execution
mux.HandleFunc("/api/wirelogs/", s.handleWirelogs) // Unauthenticated network monitoring flow stream

The fix introduced in Pull Request #4122 establishes strict boundary isolation by instantiating two discrete Go http.Server instances running on separate sockets. The public-facing port (default 8443) is mapped strictly to a public multiplexer serving the /ws agent endpoint. A secondary, private socket (default 8444) is bound exclusively to the internal control-plane network to serve the administrative API endpoints.

// PATCHED CODE - internal/cluster-gateway/server.go
// Public listener: restricted exclusively to remote agent WebSockets
publicMux := http.NewServeMux()
publicMux.HandleFunc("/ws", s.handleWebSocket)
 
// Private internal listener: hosts caller-facing administrative endpoints
internalMux := http.NewServeMux()
internalMux.HandleFunc("/api/proxy/", s.handleHTTPProxy)
internalMux.HandleFunc("/api/exec/", s.handleExec)
internalMux.HandleFunc("/api/wirelogs/", s.handleWirelogs)
 
// Parallel goroutines are initialized to spin up both servers independently
s.httpServer = &http.Server{
    Addr:    fmt.Sprintf(":%d", s.config.Port),
    Handler: publicMux,
}
s.internalServer = &http.Server{
    Addr:    fmt.Sprintf(":%d", s.config.InternalPort), // Defaults to 8444
    Handler: internalMux,
}

By ensuring that the internal port 8444 is never exposed to external traffic, this architectural change mitigates the vulnerability. Any attempt to reach /api/proxy/ or /api/exec/ on the public-facing port 8443 now results in a 404 Not Found response, as the public multiplexer contains no routing rules for those paths.

Exploitation of CVE-2026-73843 is straightforward and does not require complex payloads or multi-stage bypasses. An attacker with network access to the exposed gateway port (typically 8443) first validates the presence of the endpoint by checking the TLS certificate or path behavior. Because the administrative routing paths are fully exposed on the same port, the attacker can interact with the data-plane's Kubernetes API.

To proxy arbitrary HTTP commands directly to target Kubernetes services, the attacker issues standard HTTP requests targeting the /api/proxy/ prefix. The gateway transparently proxies the incoming request to the target cluster API using the service account credentials of the control plane. This enables the unauthenticated attacker to list, create, modify, or delete Kubernetes resources across all tenant namespaces.

POST /api/proxy/namespaces/default/services HTTP/1.1
Host: target-gateway.example.com:8443
Content-Type: application/json
Connection: close
 
{
  "apiVersion": "v1",
  "kind": "Service",
  "metadata": {
    "name": "attacker-controlled-service"
  },
  "spec": {
    "ports": [{"port": 80, "targetPort": 80}],
    "selector": {"app": "vulnerable-app"}
  }
}

Additionally, the /api/exec/ endpoint allows the establishing of a raw terminal session inside running workload containers. An attacker initiates a standard WebSocket handshake targeting the vulnerable endpoint, appending target namespace, pod, and container parameters to the query string. The gateway upgrades the connection, allowing the attacker to send stdin frames and capture stdout/stderr, establishing direct command execution capabilities inside workload pods.

The impact of successful exploitation is critical, leading to complete control-plane and data-plane compromise. By utilizing the /api/proxy/ endpoint, attackers inherit the service account permissions of the cluster-gateway. This often translates to cluster-admin or near cluster-admin privileges within the target Kubernetes environments, enabling the manipulation of deployments, secrets, and configurations.

Through the /api/exec/ endpoint, attackers achieve remote execution inside running workload pods. This execution vector bypasses traditional authentication logs and audit trails on the Kubernetes API server, as the gateway processes and routes the execution stream directly. Attackers can leverage this foothold to retrieve secrets, run malware, or pivot laterally within the cluster network.

Despite the effectiveness of the port-separation patch, administrators must evaluate the re-exploitation potential stemming from misconfigurations. If an Ingress controller, service mesh, or Kubernetes Service object exposes port 8444 to the public internet, the unauthenticated endpoints will become exposed again. Furthermore, the internal endpoints still lack application-level authentication, meaning any compromised container within the cluster network can communicate with port 8444 of the gateway to execute operations.

Mitigation of CVE-2026-73843 requires upgrading OpenChoreo to versions 1.0.2, 1.1.2, or later. These releases separate the public agent-facing port (8443) from the internal administrative port (8444). Operators must verify that internal network interfaces do not map public-facing Ingress controllers or LoadBalancers to target port 8444 of the cluster-gateway deployment.

If immediate upgrading is not feasible, operators must implement network-level access control lists. A strict Kubernetes NetworkPolicy must be applied to prevent external or unauthorized in-cluster pods from reaching the gateway pods on port 8443 (or port 8444 after upgrading). Access to the gateway's internal ports should be restricted exclusively to verified control-plane components like openchoreo-api and controller-manager.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-gateway-internal
  namespace: openchoreo-control-plane
spec:
  podSelector:
    matchLabels:
      app: cluster-gateway
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: openchoreo-api
    - podSelector:
        matchLabels:
          app: controller-manager
    ports:
    - protocol: TCP
      port: 8444

To detect exploitation attempts on legacy systems, security teams should configure Intrusion Detection Systems (IDS) to monitor network traffic for HTTP request strings containing administrative endpoints on public interfaces. Network signatures must flag any request targeting /api/exec/ or /api/proxy/ over the public gateway port.