Apache Camel K CVE-2026-45760

The attacker must be an authenticated Kubernetes user who already holds RBAC permission to create a Build resource in at least one namespace of the cluster (PR:L). The concrete prerequisite is a multi-tenant or shared Camel K deployment where the operator watches/serves namespaces the attacker does not fully control; the attack works by setting the user-controlled target namespace of the Build to the operator (or another victim) namespace. Limiting factors: it requires the affected versions (2.0.0-2.8.0, 2.9.0-2.9.1, or 2.10.0), a valid cluster identity with Build-create rights, and yields no benefit in a single-tenant cluster where the attacker already owns every namespace. No user interaction is required (UI:N).

The CVSS vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:N) describes a network-reachable, low-complexity attack requiring only low privileges - i.e., any user already granted rights to create Build resources in some namespace - with high confidentiality and integrity impact but no availability impact. SSVC aligns on severity (Technical Impact: total) but tempers urgency: Exploitation is 'none' (no observed activity) and Automatable is 'no', consistent with the very low EPSS (0.02%, 5th percentile) and the absence of KEV listing or known POC. The realistic picture is a genuinely serious tenant-isolation/privilege-escalation flaw that is high-impact but not mass-exploitable: it presupposes an attacker who already holds a foothold (valid namespace RBAC) in a multi-tenant cluster, so it is a real priority for shared/multi-tenant Camel K clusters and a lower priority for single-tenant deployments. Note the official vector uses S:U; because the impact reaches the operator namespace (a different security sphere), a scope-change interpretation (S:C) is defensible - verify against the vendor advisory.

A developer with legitimate access to a single tenant namespace in a shared Kubernetes cluster crafts a Build custom resource that specifies the Camel K operator's namespace as the Pod target. The operator obligingly creates the attacker-controlled Pod in that privileged namespace, giving the attacker execution and resource access under the operator's elevated service account. No public exploit is identified at time of analysis, and the low attack complexity (AC:L) means no special timing or conditions are needed beyond the initial namespace foothold.