CVE-2026-73842: Missing Authentication and Authorization on Internal Management Listener in OpenChoreo cluster-gateway

The OpenChoreo control-plane architecture utilizes the cluster-gateway component to tunnel operational traffic and orchestrate communication across multiple managed Kubernetes data planes. This component exposes a dedicated internal management port designed to process instructions from authorized control-plane elements like openchoreo-api and controller-manager. In vulnerable installations, this internal network listener exposes administrative routes without enforcing verification controls.\n\nThe affected endpoints include /api/proxy/ for tunneling Kubernetes API requests, /api/exec/ for executing commands inside remote container environments, and /api/wirelogs/ for tracking raw log transmissions. Because the software handles inbound calls to these endpoints with high privilege levels, the absence of verification allows caller traffic to execute with the credentials assigned to the gateway. This creates a direct attack surface for unauthorized cluster-wide administrative actions.\n\nThe vulnerability is classified under CWE-306 (Missing Authentication for Critical Function). Because the architecture relies on network perimeter trust rather than cryptographic identity verification, any endpoint-adjacent endpoint can bypass the external identity verification stack. This structural flaw exposes internal cluster mechanics directly to adjacent network assets.

The core flaw is located in the initialization logic of the internal HTTP server within internal/cluster-gateway/server.go. When setting up the network listener on port 8444, the configuration code cloned the basic TLS configuration used for public-facing connections. However, the routine failed to configure client certificate parameters on this specific listener instance, leaving the ClientAuth setting at its default state of tls.NoClientCert.\n\nWithout mutual TLS (mTLS) enforcement, the TLS handshake successfully completes with any requesting client, even if no client certificate is presented. This design assumes that the physical or logical network separation of the control plane provides sufficient protection. This assumption violates zero-trust network principles by treating the local network namespace as an implicit trust domain.\n\nAdditionally, the gateway does not restrict the HTTP verbs processed by the /api/proxy/ handler, leading to a CWE-862 (Missing Authorization) condition. Although the routing logic was designed for read-only tracking, it processes and forwards arbitrary HTTP verbs including POST, PUT, and DELETE. Consequently, unauthenticated callers can execute write operations and state changes directly on downstream clusters.

Before the remediation, the server setup logic in internal/cluster-gateway/server.go initialized the internal management server without specifying client certificate verification controls. The relevant vulnerable block cloned the standard TLS configuration but made no modifications to enforce mTLS requirements:\n\ngo\n// Vulnerable Server Initialization\ns.internalServer = &http.Server{\n Addr: fmt.Sprintf(\":%d\", s.config.InternalPort),\n Handler: internalMux,\n TLSConfig: tlsConfig.Clone(), // ClientAuth is unconfigured, allowing anonymous access\n ReadTimeout: s.config.ReadTimeout,\n WriteTimeout: s.config.WriteTimeout,\n IdleTimeout: s.config.IdleTimeout,\n}\n\n\nThe patch implemented in the security update resolves the vulnerability by introducing the helper function buildInternalTLSConfig. This function alters the cloned TLS configuration to enforce mutual certificate verification, using a dedicated Certificate Authority separate from the standard cluster infrastructure:\n\ngo\nfunc buildInternalTLSConfig(base *tls.Config, cfg *Config) (*tls.Config, error) {\n\ttlsConfig := base.Clone()\n\tif !cfg.InternalMTLSEnabled {\n\t\treturn tlsConfig, nil\n\t}\n\n\tif cfg.InternalClientCAPath == \"\" {\n\t\treturn nil, fmt.Errorf(\"internal mTLS is enabled but no client CA is configured\")\n\t}\n\n\tcaData, err := os.ReadFile(cfg.InternalClientCAPath)\n\tif err != nil {\n\t\treturn nil, fmt.Errorf(\"failed to read internal client CA: %w\", err)\n\t}\n\n\tcaPool := x509.NewCertPool()\n\tif !caPool.AppendCertsFromPEM(caData) {\n\t\treturn nil, fmt.Errorf(\"failed to parse internal client CA\")\n\t}\n\n\t// Require and verify client certificates from the isolated trust domain\n\ttlsConfig.ClientAuth = tls.RequireAndVerifyClientCert\n\ttlsConfig.ClientCAs = caPool\n\treturn tlsConfig, nil\n}\n\n\nBy implementing this validation step, the gateway stops unauthenticated requests at the TLS handshake phase, long before the HTTP multiplexer routes the traffic. Using a dedicated Certificate Authority is critical because it ensures that compromised data-plane agents holding standard client certificates cannot connect to the internal control-plane listener.

Exploiting this vulnerability requires the attacker to have adjacent network access to port 8444 of the cluster-gateway pod. This access is typically obtained by compromising a less-privileged container running within the same Kubernetes cluster or through shared network namespaces. Because authentication is not required, the attacker can establish a TLS connection directly using command-line utilities or HTTP client libraries.\n\nOnce the connection is established, the attacker issues direct requests to the /api/proxy/ API endpoint, targeting a connected data plane cluster. Because the gateway possesses administrative Service Account privileges, the downstream cluster accepts the forwarded request as a fully authorized administrative call. The following request illustrates an anonymous query retrieving sensitive Kubernetes secrets from a production namespace:\n\nhttp\nGET /api/proxy/planes/dataplane-prod/api/v1/namespaces/tenant-prod/secrets HTTP/1.1\nHost: cluster-gateway.openchoreo-control-plane.svc.cluster.local:8444\n\n\n\nThe response returns the raw secrets, allowing the attacker to retrieve credentials, database tokens, and private keys. The attacker can then transition to the /api/exec/ endpoint, using websocket upgrades to spawn high-privilege shell environments in target containers. This enables complete control-plane bypass and arbitrary command execution without leaving standard Kubernetes audit log trails linked to the attacker's identity.

The potential consequences of exploiting CVE-2026-73842 are critical, carrying a CVSS base score of 9.0. An adjacent attacker can perform unauthorized read, write, and delete operations across all connected data-plane clusters. This compromise completely breaks isolation boundaries in multi-tenant environments, exposing all tenant data.\n\nBecause the gateway handles commands with high-privilege cluster roles, attackers can modify running container specifications, mount host-level filesystems, and delete critical infrastructure resources. The CVSS Scope metric is classified as Changed (S:C) because compromising the internal gateway listener in the control plane directly leads to administrative control over separate downstream tenant clusters.\n\nThis vulnerability is not currently associated with active campaigns in the wild, nor is it included in the CISA KEV catalog. The EPSS score is currently evaluated at 0.0018, which reflects a low current threat profile. However, due to the ease of exploitation once adjacent network access is achieved, patching remains an urgent priority.

The definitive solution is upgrading the OpenChoreo control plane to versions 1.0.3, 1.1.3, or 1.2.0-rc.2. These versions introduce the --internal-mtls command-line flag and require a dedicated CA certificate bundle for client verification. The associated Helm charts have been modified to generate and distribute these certificates automatically using cert-manager resource declarations.\n\nIf an immediate upgrade is not feasible, administrators must implement strict network security controls to isolate the vulnerable port. A Kubernetes NetworkPolicy should be deployed to allow ingress traffic on port 8444 exclusively from verified control-plane components like openchoreo-api and controller-manager. This reduces the exposure to adjacent pods within the cluster network.\n\nyaml\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n name: restrict-cluster-gateway-internal\n namespace: openchoreo-control-plane\nspec:\n podSelector:\n matchLabels:\n app.kubernetes.io/component: cluster-gateway\n policyTypes:\n - Ingress\n ingress:\n - from:\n - podSelector:\n matchLabels:\n app.kubernetes.io/component: openchoreo-api\n - podSelector:\n matchLabels:\n app.kubernetes.io/component: controller-manager\n ports:\n - protocol: TCP\n port: 8444\n\n\nAdditionally, security teams should inspect cluster-gateway deployment logs for the absence of the mTLS configuration warning. The presence of the string 'internal API mTLS disabled' indicates a vulnerable state. Enabling mTLS and auditing control-plane audit logs for unexpected requests to the /api/ paths on port 8444 are vital steps to verify the integrity of the environment.