Vela-Core (>= 1.11.0-Alpha.1, < 1.11.0-Alpha.4) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/vela-core--1.11.0-alpha.1--1.11.0-alpha.4/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 28 Aug 2026 21:19:20 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgKubeVela Terraform Remote Loader Denial of Service via Unbounded File Readhttps://feed.craftedsignal.io/briefs/2026-08-kubevela-dos/Fri, 28 Aug 2026 21:19:20 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-08-kubevela-dos/An attacker with ComponentDefinition management permissions can trigger a control-plane denial of service in KubeVela by injecting a symlink to /dev/zero within a remote Terraform repository, causing an OOM-induced controller crash.KubeVela versions 1.9.14, 1.10.9, and 1.11.0-alpha.4 are vulnerable to a denial-of-service (DoS) condition (CVE-2026-55108) within the vela-core controller. The vulnerability exists in the Terraform remote configuration loader, specifically within pkg/controller/utils/capability.go. The controller improperly validates file paths when processing remote git repositories defined in ComponentDefinition resources. By crafting a repository that includes a symlink (e.g., variables.tf pointing to /dev/zero), an attacker can force the vela-core controller to perform an unbounded read via os.ReadFile. Because the controller follows symlinks and does not verify file size or target location before reading, the process memory usage grows until the controller is terminated by the kernel OOM killer. This vulnerability affects the core control plane and can cause persistent crash loops if the malicious definition remains in the cluster.

Attack Chain

  1. Attacker gains authorization to create or update core.oam.dev/v1beta1 ComponentDefinition resources in a target namespace.
  2. Attacker initializes a git repository and creates a relative symbolic link named variables.tf or main.tf that resolves to /dev/zero (e.g., ln -s ../../../../../../dev/zero variables.tf).
  3. Attacker pushes the repository to a location accessible by the KubeVela controller.
  4. Attacker creates or updates a ComponentDefinition resource, setting spec.schematic.terraform.type to remote and providing the URL to the malicious repository.
  5. The vela-core controller initiates a reconcile loop and clones the repository into its local cache.
  6. The GetTerraformConfigurationFromRemote function executes os.Stat and os.ReadFile on the attacker-controlled symlink path.
  7. The controller consumes system memory indefinitely while reading from the /dev/zero stream.
  8. The vela-core controller process reaches the container memory limit and is terminated with an OOMKilled status, resulting in a denial-of-service for the KubeVela control plane.

Impact

Successful exploitation results in a denial-of-service of the KubeVela control plane. The vela-core controller Pod enters a CrashLoopBackOff state, preventing the orchestration of application components across the cluster. If the controller lacks enforced memory limits, the unbounded read can place extreme pressure on node memory, potentially impacting other co-located workloads.

Recommendation

  1. Upgrade vela-core to the patched versions immediately: 1.9.14, 1.10.9, or 1.11.0-alpha.4.
  2. Audit existing ComponentDefinition resources to identify and restrict remote Terraform repository URLs to trusted, internal-only sources.
  3. Implement strict RBAC controls to limit which users can create or modify ComponentDefinition objects within the cluster.
  4. Ensure Kubernetes memory limits are configured for the vela-core controller deployment to contain the impact of OOM conditions and prevent node-wide instability.
]]>mediumadvisorydenial-of-servicekuberneteskubevela