The flaw allows an authorized user to create a Build resource that causes the Camel K operator to generate a pod in any namespace of their choice, including the operator's own namespace. This bypasses normal namespace boundaries and can be used to run arbitrary code with elevated privileges, effectively providing a local privilege escalation within the Kubernetes cluster. The vulnerability is rooted in externally controlled reference to a resource in another sphere and in authorization bypass through a user‑controlled key, corresponding to CWE‑610 and CWE‑639.

Apache Camel K versions from 2.0.0 up to but not including 2.8.1, from 2.9.0 up to but not including 2.9.2, and from 2.10.0 up to but not including 2.10.1 are vulnerable. In all affected releases, users can create Build objects without namespace restrictions, enabling the described attack.

The vulnerability is serious because it does not require any additional permissions beyond those needed to create a Build resource; an authenticated user who can create Builds can control pod deployments in any namespace. The EPSS score of < 1% indicates a very low but nonzero probability of exploitation, and the lack of a listing in the CISA KEV catalog suggests no publicly known active exploitation. However, the potential for privilege escalation is high. The attack path is straightforward: create a Build specifying an arbitrary target namespace, causing the operator to spin up a pod there.