AIKIDO-2026-22107

TL;DR

The UI BFF exposes model-transfer-job routes that run a Kubernetes SubjectAccessReview bound to the namespace query parameter while the handlers operate on a different namespace taken from a separate jobNamespace parameter or the request body, with no reconciliation between the two. In the default internal auth mode every data-plane call runs as the BFF ServiceAccount and the caller identity is used only as the review subject, so the Kubernetes API does not re-enforce the caller's own permissions. A caller allowed to read the model-registry service in one namespace can read, create, and delete Jobs, Secrets, ConfigMaps, and Pods or Events in any other namespace the BFF ServiceAccount can reach, including reading another tenant's transfer-job spec and planting workloads. The fix binds the authorization check to the namespace the handler actually operates on.