CVE-2026-73841: Broken Object Level Authorization (BOLA) in OpenChoreo Container Exec and Wirelogs Endpoints

OpenChoreo is an open-source developer platform designed for Kubernetes orchestration. Within its architecture, the openchoreo-api component exposes critical management endpoints. Among these, the exec endpoint allows interactive command execution within container terminals, and the wirelogs endpoint provides real-time access to inter-container communication data.

Because these endpoints manage low-level system interactions and sensitive diagnostic data, they represent a significant attack surface. In environments where multiple teams share a single Kubernetes namespace, strict boundary enforcement is required to maintain isolation between separate developer projects.

Prior to the patched versions, the authorization layer relied on client-supplied input rather than verifying the authoritative state of the targeted resource. This architectural oversight led to a critical Broken Object Level Authorization (BOLA) vulnerability, classified as CWE-639 and CWE-863. This flaw permitted users with minimal privileges in one project to escape their boundaries and compromise workloads in other projects.

The root cause of this vulnerability lies in the implementation of the authorization checking and pod resolution sequence within internal/openchoreo-api/api/handlers/exec.go and internal/openchoreo-api/api/handlers/wirelogs.go.

When a client issues a request to execute a command inside a component's container, the API server extracts the target component name from the request path and reads the project identifier from the project query parameter. This project value, directly controlled by the client, is passed to the Casbin Policy Decision Point (PDP) as part of the ResourceHierarchy struct to evaluate authorization.

If the client has valid permissions (such as component:exec) for the requested project name, Casbin approves the request. However, during the subsequent pod resolution step, the handler retrieves the target pod from the Kubernetes API using only the component name. It fails to verify if the resolved component is actually owned by the authorized project.

Additionally, the pre-patch logic failed to pass the specific component name to the Casbin context. Because the policy engine requires strict hierarchy matching, omitting the component name from the authorization path meant that component-specific role bindings were ignored, and authorization evaluations reverted to broader, project-level permissions. This structural omission facilitated the scope bypass.

The remediation introduces structured component lookup to retrieve the authoritative owning project prior to any authorization check. The following diff displays the core modifications made to the API handlers:

// Fragment from internal/openchoreo-api/api/handlers/exec.go
 
	componentName := parts[1]
 
 	query := r.URL.Query()
-	project := query.Get("project")
+	requestedProject := query.Get("project")
 	envName := query.Get("env")
 	container := query.Get("container")
 	commands := query["command"]
@@ -75,12 +76,31 @@ func (h *ExecHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
 	ctx := r.Context()
 	logger := h.logger.With("namespace", namespace, "component", componentName)
 
-	// Authorize: check that the caller has component:exec permission.
+	// Authorization must be configured before any access decision is made.
 	if h.authzChecker == nil {
 		logger.Error("Authorization checker not configured")
 		http.Error(w, "authorization not configured", http.StatusInternalServerError)
 		return
 	}
+
+	// Pin authorization and pod resolution to the component's real owning project
+	// rather than the caller-supplied `project`.
+	project, err := h.resolveComponentProject(ctx, namespace, componentName)
+	if err != nil {
+		logger.Warn("Failed to resolve component for exec", "error", err)
+		http.Error(w, fmt.Sprintf("failed to resolve component: %v", err), http.StatusBadRequest)
+		return
+	}
+	// Fail closed if the caller named a project that does not own the component.
+	if requestedProject != "" && requestedProject != project {
+		logger.Warn("requested project does not own the target component; denying exec",
+			"requestedProject", requestedProject, "ownerProject", project)
+		http.Error(w, "you do not have permission to exec into this component", http.StatusForbidden)
+		return
+	}

To support this check, the helper function resolveComponentProject queries the Kubernetes API server directly to fetch the Component resource and extract the authoritative owner:

func (h *ExecHandler) resolveComponentProject(ctx context.Context, namespace, componentName string) (string, error) {
	comp := &openchoreov1alpha1.Component{}
	if err := h.k8sClient.Get(ctx, client.ObjectKey{Namespace: namespace, Name: componentName}, comp); err != nil {
		if apierrors.IsNotFound(err) {
			return "", fmt.Errorf("component %q not found in namespace %q", componentName, namespace)
		}
		return "", fmt.Errorf("failed to look up component %q: %w", componentName, err)
	}
	if comp.Spec.Owner.ProjectName == "" {
		return "", fmt.Errorf("component %q has no owning project", componentName)
	}
	return comp.Spec.Owner.ProjectName, nil
}

This implementation prevents the authorization bypass by binding the Casbin decision strictly to the comp.Spec.Owner.ProjectName metadata. If the user-supplied project query parameter does not match the actual owning project of the target component, the request is denied immediately with a generic 403 Forbidden error.

An attacker with valid, low-privilege credentials belonging to a designated project (e.g., project-a) can compromise workloads belonging to a separate project (e.g., project-b) inside the same namespace.

The following sequence diagram details the exploitation flow:

To perform the attack, the adversary establishes a connection to the terminal endpoint, passing their authorized project ID in the query string while naming the targeted component in the path:

GET /exec/namespaces/default/components/sensitive-db-service?project=attacker-owned-project

If the connection is upgraded to a WebSocket, the API establishes an interactive SPDY stream directly into the container running sensitive-db-service. The attacker gains full command-line execution privileges as configured inside the target container's runtime security profile.

The impact of this vulnerability is significant, as it leads to multi-tenant isolation collapse within shared Kubernetes clusters managed by OpenChoreo. Successful exploitation yields remote command execution inside arbitrary container workloads, potentially exposing cluster service account tokens, database credentials, and application source code.

Although the core patch effectively resolves the primary execution path, security teams should evaluate the following residual risks:

1. Dynamic Metadata Mutations (TOCTOU): Because Kubernetes Custom Resources are evaluated dynamically, there is a minor race window between the component ownership lookup and the establishment of the SPDY tunnel. Mutating resource specifications rapidly could theoretically exploit synchronization delays.

2. The Wirelogs Parameter Validation Gap: In the live traffic streaming handler (wirelogs), if the component parameter is omitted, the project-lookup function is bypassed. System engineers must verify that the underlying logging backend (such as Hubble) enforces strict network-level security controls independently of OpenChoreo's API layer.

To detect exploitation attempts prior to patching, security administrators should audit API server logs for diagnostic mismatches. Look for requests where the supplied project query string diverges from the target component's actual namespace or known namespace mappings.

Following the patch, failed exploitation attempts generate explicit warnings in the API logs:

requested project does not own the target component; denying exec

To query these occurrences within centralized log aggregators, use the following search syntax:

"requested project does not own the target component" OR "you do not have permission to view wirelogs for this scope"

In addition, deployment integrity can be verified via the following programmatic test case, which checks that mismatching projects trigger an explicit 403 Forbidden response and bypass policy execution entirely:

func TestExecHandler_DeniesComponentProjectMismatch(t *testing.T) {
	pdp := testutil.AllowPDP()
	h := newExecHandler(t, pdp, execComponent("default", "victim-svc", "team-b"))
 
	rec := httptest.NewRecorder()
	h.ServeHTTP(rec, httptest.NewRequest(http.MethodGet,
		"/exec/namespaces/default/components/victim-svc?env=development&project=team-a",
		nil).WithContext(testutil.AuthzContext()))
 
	require.Equal(t, http.StatusForbidden, rec.Code)
	require.Empty(t, pdp.Captured, "authz must not run when requested project does not own the component")
}