Apache Camel Karavan EUVD-2026-95757

Exploitation requires (1) a running Apache Camel Karavan instance (4.0.0 up to before 4.22.1) with authentication enabled, and (2) any valid authenticated account regardless of role - the flaw explicitly does not enforce role restrictions. The concrete trigger is the deployment-start workflow, where Karavan unmarshals a project's kubernetes.yaml and applies every resource without restricting resource kinds, rejecting security-sensitive pod options (hostNetwork, hostPID, hostIPC, hostPath, host ports, privileged, allowPrivilegeEscalation, added capabilities), or pinning the target namespace. The effective blast radius is strictly limited by the RBAC permissions of Karavan's Kubernetes service account: if that service account cannot create pods/privileged workloads cluster-wide, impact is correspondingly reduced. Limiting factors: attacker must be authenticated (not anonymous); the service account's granted permissions cap what can be applied.

This is a credible, high-priority issue rather than a CVSS-inflated one, though the signals are not uniform. The provided CVSS:3.1/AV:N/AC:L/PR:L/UI:N vector indicates a network-reachable flaw exploitable with low attack complexity by an authenticated user holding only low privileges (PR:L), with high impact to confidentiality, integrity and availability (C:H/I:H/A:H), scoring 8.8. The description reinforces this: any authenticated user 'of any role' can cause Karavan to apply arbitrary Kubernetes resources - including privileged/hostPath/hostNetwork pods - which is effectively a cluster-level privilege-escalation and container-escape primitive bounded only by Karavan's service-account RBAC. That upgrades the real-world severity above a mere application bug. Counterbalancing signals: there is no EPSS score, no CISA KEV listing, and no public exploit in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation. Because exploitation requires a valid authenticated account on a Karavan instance, realistic risk is concentrated in multi-tenant or shared Karavan deployments where low-trust users exist. The official vector scores Scope:Unchanged, but the described impact clearly reaches the underlying nodes/cluster beyond Karavan itself - a point of tension worth noting, as a scope-changed reading would push severity even higher. Net: a real priority to patch for anyone running shared Karavan, but not an imminent mass-exploitation emergency absent POC/KEV evidence.

A low-privileged but authenticated Karavan user creates or edits a project whose kubernetes.yaml defines a privileged pod with a hostPath volume mounting the node filesystem, then starts a deployment. Karavan unmarshals the manifest and applies it unchanged using its service account, and the attacker uses the resulting privileged container to read node secrets or escape to the host. No public exploit is identified at time of analysis, but the technique requires no special tooling beyond a crafted manifest.