CVE-2026-55108: KubeVela Terraform Loader DOS Vulnerability

CVE-2026-55108 Overview

CVE-2026-55108 is a symlink-following denial of service vulnerability in KubeVela, an open source application delivery platform. The flaw resides in the Terraform remote configuration loader GetTerraformConfigurationFromRemote in pkg/controller/utils/capability.go. The loader clones a repository referenced by a core.oam.dev/v1beta1ComponentDefinition and follows repository-controlled variables.tf or main.tf symlinks. An authenticated user able to create or update ComponentDefinition objects can point variables.tf at /dev/zero, causing os.Stat and os.ReadFile to read an unbounded stream. The read exhausts memory in the cluster-wide vela-core controller. The issue is tracked as [CWE-59] Improper Link Resolution Before File Access.

Critical Impact
An attacker with ComponentDefinition write permission can OOM-kill the vela-core controller, trigger repeated Pod restarts, and pressure node memory across the cluster.

Affected Products

KubeVela versions prior to 1.9.14
KubeVela versions 1.10.0-alpha.1 through 1.10.8
KubeVela versions 1.11.0-alpha.1 through 1.11.0-alpha.3

Discovery Timeline

2026-08-28 - CVE-2026-55108 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-55108

Vulnerability Analysis

The vulnerability is a symlink-following resource exhaustion flaw in the KubeVela controller's Terraform remote configuration handling. When a ComponentDefinition specifies a Terraform module source, the controller clones the referenced Git repository and reads variables.tf or main.tf to parse HashiCorp Configuration Language (HCL) input. Because the loader uses os.Stat and os.ReadFile without validating that the target path is a regular file within the cloned tree, a repository-controlled symlink is silently followed. Pointing that symlink at a character device such as /dev/zero returns a stream that never terminates. The read completes only when the process runs out of memory, and Go's os.ReadFile accumulates the entire stream into a single buffer before ParseTerraformVariables or the HCL parser is invoked.

Root Cause

The root cause is the absence of symlink resolution checks and file-size limits in GetTerraformConfigurationFromRemote. The function trusts the contents of a repository supplied by an authenticated tenant. It never verifies that variables.tf or main.tf resolve to a regular file inside the clone directory. It also does not cap the number of bytes read into memory.

Attack Vector

An authenticated user with permission to create or update ComponentDefinition resources publishes a Git repository containing a symlink named variables.tf (or main.tf) pointing to /dev/zero. The user then submits a ComponentDefinition whose terraform.path references that repository. The vela-core controller clones the repository on reconciliation, follows the symlink, and begins an unbounded read. Memory usage climbs until the container is OOM-killed. Because vela-core runs cluster-wide, the crash impacts all tenants sharing the controller and can pressure node memory when no container limit is configured.

The upstream fix rebuilds applied resources from the authoritative ResourceTracker and reattaches creator attribution from dispatch records. This hardens the controller state machine as part of the same backport series that adds symlink and size validation:

// appliedResourcesWithCreator rebuilds the applied resources from the ResourceTracker,
// which is the authoritative source of which resources currently exist, and re-attaches
// the creator recorded while dispatching them. The ResourceTracker does not persist the
// creator, so rebuilding from it alone drops the creator attribution from the status.
// reconcile runs single threaded, matching addAppliedResource, so no locking is needed.
func (h *AppHandler) appliedResourcesWithCreator() []common.ClusterObjectReference {
	rebuilt := h.resourceKeeper.GetAppliedResources()
	for i := range rebuilt {
		if rebuilt[i].Creator != "" {
			continue
		}
		for _, dispatched := range h.appliedResources {
			if dispatched.Creator != "" && sameResource(rebuilt[i], dispatched) {
				rebuilt[i].Creator = dispatched.Creator
				break
			}
		}
	}
	return rebuilt
}

Source: KubeVela Commit 65dedda

Detection Methods for CVE-2026-55108

Indicators of Compromise

Repeated OOMKilled termination reasons on the vela-core controller Pod within short windows.
ComponentDefinition objects referencing external Git repositories with unusual terraform.path values submitted by non-administrative service accounts.
Sudden growth in resident memory of vela-core shortly after a ComponentDefinition create or update event.

Detection Strategies

Audit Kubernetes API server logs for create and update verbs on componentdefinitions.core.oam.dev and correlate with subsequent controller restarts.
Alert when vela-core Pod restart count increases while a reconciliation for a Terraform-typed ComponentDefinition is in flight.
Inspect cloned repository trees in ephemeral controller storage for symlinks whose targets fall outside the clone root, particularly /dev/* device files.

Monitoring Recommendations

Track container memory working set and OOM events for vela-core using Prometheus container_memory_working_set_bytes and kube_pod_container_status_last_terminated_reason.
Enable Kubernetes audit logging at RequestResponse level for the core.oam.dev API group to preserve payloads of submitted ComponentDefinition objects.
Forward controller logs and audit events to a centralized SIEM to correlate tenant activity with controller instability.

How to Mitigate CVE-2026-55108

Immediate Actions Required

Upgrade vela-core to 1.9.14, 1.10.9, or 1.11.0-alpha.4 as appropriate for your release channel.
Restrict RBAC permissions on componentdefinitions.core.oam.dev so only trusted platform operators can create or update these objects.
Set explicit memory limits on the vela-core container to bound the blast radius of any future resource-exhaustion flaw.

Patch Information

The issue is fixed in KubeVela releases v1.9.14, v1.10.9, and v1.11.0-alpha.4. See the KubeVela Security Advisory GHSA-fmgp-q6jx-gg3x and pull requests #7191 and #7192 for the full change set.

Workarounds

Temporarily disable the Terraform remote configuration feature or remove ComponentDefinition objects that reference untrusted Git repositories.
Enforce a Kubernetes admission policy (for example, Kyverno or OPA Gatekeeper) that blocks ComponentDefinition objects sourced from repositories outside an allowlist.
Apply strict container memory limits to vela-core so the kubelet terminates a runaway process before it pressures node memory.

bash

# Configuration example: enforce a memory limit on vela-core
kubectl -n vela-system set resources deployment/kubevela-vela-core \
  --limits=memory=1Gi --requests=memory=256Mi