KubeVela CVE-2026-55108

Exploitation requires the attacker to hold Kubernetes RBAC create or update permission on core.oam.dev/v1beta1 ComponentDefinition objects in any namespace within the cluster - this is the sole authentication/authorization prerequisite, confirmed by the CVSS PR:L metric. The ComponentDefinition must specify schematic.terraform.type: remote with a configuration URL pointing to a git repository the attacker controls or has compromised; the repository must contain a relative symlink (e.g., variables.tf -> ../../../../../../dev/zero) that resolves to /dev/zero from the controller's clone cache path after checkout. No special network position is required: the controller initiates the git clone outbound to attacker-controlled infrastructure. Exploitation is limited by the ComponentDefinition RBAC prerequisite; in tightly controlled single-tenant clusters where only platform operators hold this permission, exposure is limited to insider threats. In permissive multi-tenant configurations where developer namespaces include ComponentDefinition rights - common in self-service platform setups - this restriction is effectively absent. The attack does not require the Terraform provider to be installed or functional: vela-core's reconciler reads the git-cloned file before any Terraform tooling is invoked.

The vendor-assigned CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H, score 8.5) accurately captures the primary risk dimensions: network-reachable via the controller's outbound git clone, no attack complexity, low-privilege RBAC prerequisite, and a scope change that elevates the availability impact to the cluster control plane. EPSS data is absent from the provided intelligence; given the detailed public PoC and the simple exploitation mechanics (a crafted git repository plus a single kubectl apply), real-world exploitation probability should be treated as elevated regardless. No CISA KEV listing has been confirmed. The C:L component reflects a plausible but unconfirmed secondary path-traversal confidentiality risk; the reporter explicitly states that exploiting confidentiality requires HCL parsing success, which the unbounded read physically prevents, so the pure-DoS scenario is the near-certain outcome. The scope change (S:C) is well-justified: the vela-core controller is a singleton managing cluster-wide OAM resources, so its OOMKill disrupts all application reconciliation for the entire cluster, not just the attacker's namespace. In multi-tenant clusters where developer roles hold ComponentDefinition create rights - a common configuration in platform-engineering setups - this is an immediate priority; even a mid-sized platform team operating across multiple namespaces should treat this as urgent, since a single API call converts a routine developer permission into a cluster-wide control-plane outage. The absence of a memory limit on vela-core (common in default Helm installations) widens the blast radius to node-level memory pressure affecting collocated workloads.

An application developer in a multi-tenant KubeVela cluster who holds create rights on ComponentDefinition pushes a git repository whose root contains a relative symlink variables.tf -> ../../../../../../dev/zero, then applies a ComponentDefinition manifest referencing that repository as a Terraform remote schematic with type: remote. The vela-core controller clones the repository outbound over HTTPS, resolves the symlink via os.Stat (which succeeds), and enters os.ReadFile which streams infinitely from /dev/zero - a complete proof-of-concept including the exact git commands and manifest is publicly available in GHSA-fmgp-q6jx-gg3x. Within seconds the controller pod is OOMKilled (exit code 137) and enters CrashLoopBackOff, halting all OAM application reconciliation cluster-wide until the pod recovers and the attacker removes the ComponentDefinition.