The loadSecret function in odh-model-controller accepts a namespace directly from user-supplied input and uses it to scope Secret lookups without verifying the caller has permission to read Secrets in that namespace. This is a namespace boundary confusion vulnerability: the controller assumes that because a user is authorized to create a CustomResource, their requested namespace is implicitly legitimate. Kubernetes RBAC doesn't work this way — a user can be authorized to create a CR in namespace A while having no Secret read access, or access restricted to specific namespaces. The controller never checks this alignment; it trusts the namespace parameter as a valid scope.
The blast radius of this pattern is routinely underestimated. odh-model-controller operates in ML/AI deployments where controllers often run with elevated permissions to orchestrate model serving across namespaces. The Secrets being read typically contain cloud credentials, registry tokens, or inference endpoint keys. One cross-namespace Secret read in this context isn't just information disclosure — it's a pivot point for lateral movement into every service those credentials touch. The CVSS 6.5 rating reflects the immediate function behavior, not the downstream cascade potential.
This vulnerability is not exotic — it's the natural output of a development culture that optimizes for functionality over boundary enforcement. Controller SDKs provide namespace parameters as first-class inputs without requiring developers to reason about their security implications. The mental model defaults to "namespace is just data routing" rather than "namespace is a security boundary I must enforce." The same pattern has surfaced in early admission controllers, multi-tenant operators, and now ML/AI tooling — each wave following the same sequence: functionality pressure, implicit trust of namespace as routing metadata, then a CVE forcing retrospective RBAC auditing.
To remediate, you have two options. First, eliminate the user-controlled namespace parameter entirely and restrict Secret reads to the same namespace as the CustomResource being processed — this removes the attack surface but may break legitimate cross-namespace patterns. Second, explicitly validate caller permissions before honoring a cross-namespace request, requiring an explicit permission check rather than passive trust. Either approach requires abandoning the passive trust model.
Audit your own controllers: any component accepting namespace parameters from user input without permission checks likely harbors similar flaws. The fix for this CVE is straightforward in principle, but the durable solution is treating namespace parameters as security boundaries rather than routing metadata — and ensuring your utility functions reflect that assumption.