This CVE exposes three unauthenticated endpoints in OpenChoreo's internal cluster gateway—specifically in internal/cluster-gateway/server.go. The vulnerability was a configuration error: the server likely bound to 0.0.0.0 instead of 127.0.0.1, or authentication middleware was simply omitted for these routes. Either way, any workload on the cluster network could reach these endpoints without credentials.
The real issue is not the CVSS 9, which mathematically reflects the severity of secrets exfiltration and command execution if exploited. The real issue is the assumption that 'internal' equals 'protected.' In Kubernetes, an internal listener is not an enclave. Every pod on the cluster network can reach every other pod's internal listeners unless NetworkPolicy explicitly restricts this. Service mesh sidecars, node-level compromise, cross-tenant residual access, and misconfigured hostPath mounts can all reach these listeners. The label 'internal' created organizational immunity to scrutiny—nobody audited the internal directory because the name itself was the audit.
The fix being confined to a single file suggests this was a routing or authentication configuration error, not a deeper code flaw. That's concerning because it means the underlying mental model—treating network designation as a security boundary—may still be present elsewhere in the codebase.
Verify your OpenChoreo deployment: check whether internal/cluster-gateway/server.go is binding to 0.0.0.0 or to a loopback/internal interface. Determine whether the patch enforces certificate or token authentication on these endpoints, or merely changes the binding address—and recognize that binding changes alone don't close the vector in multi-tenant Kubernetes environments. Audit other endpoints in the internal/ directory for the same pattern. Treat internal listeners as untrusted by default—require mTLS for all internal service communication, and assume that any pod can reach any other pod unless NetworkPolicy explicitly denies it.