Camel Karavan: any authenticated user can apply arbitrary Kubernetes resources, including privileged pods

Impact

When a deployment was started, Karavan unmarshalled the project's kubernetes.yaml and applied every resource in it to the cluster without restricting resource kinds, rejecting security-sensitive pod options, or pinning the target namespace. Any authenticated user of any role could therefore have Karavan's own service account create pods with hostNetwork, hostPID, hostIPC, hostPath volumes, host ports, privileged containers, privilege escalation or added capabilities. On a shared GPU cluster that is a direct route off the pod and onto the node: a hostPath mount reaches the kubelet credentials and other tenants' data, and a privileged container reaches /dev/nvidia* and the host driver regardless of which GPUs the scheduler assigned. The namespace was not pinned, so the blast radius is everything Karavan's service account can touch, not the user's own project.

Who can reach it

Any authenticated Karavan user, any role, who can start a deployment for a project whose kubernetes.yaml they control. Authentication is required; no cluster-level privilege is.

What to do

Upgrade Apache Camel Karavan to 4.22.1 (affects 4.0.0 up to 4.22.1) and restart the Karavan deployment. Until then, cut the service account's RBAC to the namespaces and resource kinds Karavan actually needs and admit pods through a Pod Security admission policy at restricted or baseline, which blocks the host-namespace and privileged options this path would otherwise pass through. Audit existing pods created via Karavan for host mounts and privileged flags before assuming the cluster is clean.

References

Related entries

• insights-runtime-extractor: incomplete privilege drop lets any pod get host root via its own argv[0]CVE-2026-104795 · Red Hat insights-runtime-extractor (privileged DaemonSet on OpenShift)High
• ingress-nginx: Config injection via the auth-method annotationCVE-2026-1580 · ingress-nginxHigh
• Kata Containers: Malformed or layer-less container image breaks Kata's handlingCVE-2026-24054 · Kata ContainersHigh
• ingress-nginx: Config injection via rules.http.paths.pathCVE-2026-24512 · ingress-nginxHigh
• ingress-nginx: rewrite-target annotation injects nginx configCVE-2026-3288 · ingress-nginxHigh
• ingress-nginx: Comment-based nginx configuration injectionCVE-2026-4342 · ingress-nginxHigh