Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

6389 vulnerabilities reference this CWE, most recent first.

GHSA-FJW8-3GP8-4CVX

Vulnerability from github – Published: 2024-05-16 17:44 – Updated: 2024-05-16 19:06
VLAI
Summary
Denial of service of Minder Server with attacker-controlled REST endpoint
Details

The Minder REST ingester is vulnerable to a denial of service attack via an attacker-controlled REST endpoint that can crash the Minder server.

The REST ingester allows users to interact with REST endpoints to fetch data for rule evaluation. When fetching data with the REST ingester, Minder sends a request to an endpoint and will use the data from the body of the response as the data to evaluate against a certain rule. Minder sends the request on these lines: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L131-L139

… and parses the response body on these lines:

https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L147-L150

https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L196-L220

Minder creates the URL of the endpoint via templating on these lines:

https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L121-L123

As far as I can tell, at this stage in rule evaluation, users fully control the raw template and the params passed to the template via the RuleType type:

https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/pkg/api/protobuf/go/minder/v1/minder.pb.go#L6151-L6173

I have not seen anything that enforces users to only send requests to GitHub REST endpoints. If there is such a constraint, it limits the ease with which this vulnerability can be exploited, but it is still possible. If there is not such a constraint, it is easy to exploit this vuln.

When Minder parses the response from a remote endpoint, it reads the response entirely into memory on these lines:

https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L207

and

https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L213

If the response is sufficiently large, it can drain memory on the machine and crash the Minder server.

The attacker can control the remote REST endpoints that Minder sends requests to, and they can configure the remote REST endpoints to return responses with large bodies. They would then instruct Minder to send a request to their configured endpoint that would return the large response which would crash the Minder server.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/stacklok/minder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.49"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-35185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-16T17:44:39Z",
    "nvd_published_at": "2024-05-16T16:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The Minder REST ingester is vulnerable to a denial of service attack via an attacker-controlled REST endpoint that can crash the Minder server.\n\nThe REST ingester allows users to interact with REST endpoints to fetch data for rule evaluation. When fetching data with the REST ingester, Minder sends a request to an endpoint and will use the data from the body of the response as the data to evaluate against a certain rule. Minder sends the request on these lines:\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L131-L139\n\n\u2026 and parses the response body on these lines:\n\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L147-L150\n\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L196-L220\n\nMinder creates the URL of the endpoint via templating on these lines:\n\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L121-L123\n\nAs far as I can tell, at this stage in rule evaluation, users fully control the raw template and the params passed to the template via the RuleType type:\n\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/pkg/api/protobuf/go/minder/v1/minder.pb.go#L6151-L6173\n\nI have not seen anything that enforces users to only send requests to GitHub REST endpoints. If there is such a constraint, it limits the ease with which this vulnerability can be exploited, but it is still possible. If there is not such a constraint, it is easy to exploit this vuln.\n\nWhen Minder parses the response from a remote endpoint, it reads the response entirely into memory on these lines:\n\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L207\n\nand\n\nhttps://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L213\n\nIf the response is sufficiently large, it can drain memory on the machine and crash the Minder server.\n\nThe attacker can control the remote REST endpoints that Minder sends requests to, and they can configure the remote REST endpoints to return responses with large bodies.  They would then instruct Minder to send a request to their configured endpoint that would return the large response which would crash the Minder server.\n",
  "id": "GHSA-fjw8-3gp8-4cvx",
  "modified": "2024-05-16T19:06:00Z",
  "published": "2024-05-16T17:44:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/security/advisories/GHSA-fjw8-3gp8-4cvx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stacklok/minder/commit/065049336aac0621ee00a0bb2211f8051d47c14b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stacklok/minder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of service of Minder Server with attacker-controlled REST endpoint"
}

GHSA-FM4G-76C9-7W69

Vulnerability from github – Published: 2026-09-15 19:54 – Updated: 2026-09-15 19:54
VLAI
Summary
Http4s: DigestAuth nonce map grows unbounded
Details

The DigestAuth server middleware's stale-nonce cleanup uses an inverted comparison: it removes fresh nonces and stops at the first stale one. Because a new nonce is created for every unauthenticated challenge, an attacker can drive the nonce map to grow without bound until the JVM runs out of heap.

Impact

Unauthenticated remote denial of service (gradual heap exhaustion / OOM) against any service using DigestAuth. The leak is persistent.

Preconditions

  • Application uses DigestAuth on at least one route.

Workarounds

  • Front the DigestAuth protected routes with a rate limiter to slow the leak.
  • Restart periodically.

Fixes

  • The eviction logic is corrected.
  • A max cache size of 1000000 is imposed to protected against a burst between evictions. This limit is not yet configurable.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.34"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-ember-server_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.34"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-ember-server_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.34"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-ember-server_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-M46"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-ember-server_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-M1"
            },
            {
              "fixed": "1.0.0-M47"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-M46"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-ember-server_3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-M1"
            },
            {
              "fixed": "1.0.0-M47"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69208"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-15T19:54:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The `DigestAuth` server middleware\u0027s stale-nonce cleanup uses an inverted comparison: it removes *fresh* nonces and stops at the first *stale* one.  Because a new nonce is created for every unauthenticated challenge, an attacker can drive the nonce map to grow without bound until the JVM runs out of heap.\n\n## Impact\n\nUnauthenticated remote denial of service (gradual heap exhaustion / OOM) against\nany service using DigestAuth.  The leak is persistent.\n\n## Preconditions\n\n- Application uses `DigestAuth` on at least one route.\n\n## Workarounds\n\n- Front the DigestAuth protected routes with a rate limiter to slow the leak.\n- Restart periodically.\n\n## Fixes\n\n- The eviction logic is corrected.\n- A max cache size of 1000000 is imposed to protected against a burst between evictions.  This limit is not yet configurable.",
  "id": "GHSA-fm4g-76c9-7w69",
  "modified": "2026-09-15T19:54:37Z",
  "published": "2026-09-15T19:54:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/security/advisories/GHSA-fm4g-76c9-7w69"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/commit/8cfeda8472954d631dfbe5dc026463a27653e482"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/http4s/http4s"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/releases/tag/v0.23.35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/releases/tag/v1.0.0-M47"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Http4s: DigestAuth nonce map grows unbounded"
}

GHSA-FM58-52Q7-GPVG

Vulnerability from github – Published: 2022-05-21 00:01 – Updated: 2022-06-02 00:00
VLAI
Details

OPC UA Legacy Java Stack 2022-04-01 allows a remote attacker to cause a server to stop processing messages by sending crafted messages that exhaust available resources.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-30551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-20T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "OPC UA Legacy Java Stack 2022-04-01 allows a remote attacker to cause a server to stop processing messages by sending crafted messages that exhaust available resources.",
  "id": "GHSA-fm58-52q7-gpvg",
  "modified": "2022-06-02T00:00:15Z",
  "published": "2022-05-21T00:01:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30551"
    },
    {
      "type": "WEB",
      "url": "https://files.opcfoundation.org/SecurityBulletins/OPC%20Foundation%20Security%20Bulletin%20CVE-2022-30551.pdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OPCFoundation/UA-Java-Legacy"
    },
    {
      "type": "WEB",
      "url": "https://opcfoundation.org"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM5R-J2G9-7G6V

Vulnerability from github – Published: 2025-09-26 18:31 – Updated: 2025-09-26 21:30
VLAI
Details

Wavlink M86X3A_V240730 contains a buffer overflow vulnerability in the /cgi-bin/ExportAllSettings.cgi file. The vulnerability arises because the Cookie parameter does not properly validate the length of input data. Attackers can exploit this to execute arbitrary code or cause a denial of service (DoS) on the system

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-55847"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-120",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-26T18:15:36Z",
    "severity": "HIGH"
  },
  "details": "Wavlink M86X3A_V240730 contains a buffer overflow vulnerability in the /cgi-bin/ExportAllSettings.cgi file. The vulnerability arises because the Cookie parameter does not properly validate the length of input data. Attackers can exploit this to execute arbitrary code or cause a denial of service (DoS) on the system",
  "id": "GHSA-fm5r-j2g9-7g6v",
  "modified": "2025-09-26T21:30:29Z",
  "published": "2025-09-26T18:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55847"
    },
    {
      "type": "WEB",
      "url": "https://github.com/meigui637/iot_zone/blob/main/%E6%A0%88%E6%BA%A2%E5%87%BA%E6%BC%8F%E6%B4%9E.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM5V-X688-F2Q9

Vulnerability from github – Published: 2025-12-29 15:30 – Updated: 2025-12-29 18:30
VLAI
Details

UxPlay 1.72 contains a double free vulnerability in its RTSP request handling. A specially crafted RTSP TEARDOWN request can trigger multiple calls to free() on the same memory address, potentially causing a Denial of Service.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-60458"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-29T15:16:01Z",
    "severity": "MODERATE"
  },
  "details": "UxPlay 1.72 contains a double free vulnerability in its RTSP request handling. A specially crafted RTSP TEARDOWN request can trigger multiple calls to free() on the same memory address, potentially causing a Denial of Service.",
  "id": "GHSA-fm5v-x688-f2q9",
  "modified": "2025-12-29T18:30:54Z",
  "published": "2025-12-29T15:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60458"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0pepsi/CVE-2025-60458"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMCR-J4VV-2WHW

Vulnerability from github – Published: 2026-08-24 21:33 – Updated: 2026-08-25 21:31
VLAI
Details

An integer handling flaw in the cobs_decode function of SpaceDot AcubeSAT OBC software commit eaf90ec allows physically-proximate attackers with UART access to cause a Denial of Service (DoS) via a crafted input.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-75371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T19:16:58Z",
    "severity": "HIGH"
  },
  "details": "An integer handling flaw in the cobs_decode function of SpaceDot AcubeSAT OBC software commit eaf90ec allows physically-proximate attackers with UART access to cause a Denial of Service (DoS) via a crafted input.",
  "id": "GHSA-fmcr-j4vv-2whw",
  "modified": "2026-08-25T21:31:23Z",
  "published": "2026-08-24T21:33:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75371"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dazuo233/cve/issues/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMG9-CQHF-254R

Vulnerability from github – Published: 2022-10-21 19:01 – Updated: 2022-10-22 12:00
VLAI
Details

A potential DOS vulnerability was discovered in GitLab CE/EE affecting all versions from 10.8 before 15.1.6, all versions starting from 15.2 before 15.2.4, all versions starting from 15.3 before 15.3.2. Improper data handling on branch creation could have been used to trigger high CPU usage.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-3639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-21T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A potential DOS vulnerability was discovered in GitLab CE/EE affecting all versions from 10.8 before 15.1.6, all versions starting from 15.2 before 15.2.4, all versions starting from 15.3 before 15.3.2. Improper data handling on branch creation could have been used to trigger high CPU usage.",
  "id": "GHSA-fmg9-cqhf-254r",
  "modified": "2022-10-22T12:00:25Z",
  "published": "2022-10-21T19:01:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3639"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3639.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/366876"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMGP-Q6JX-GG3X

Vulnerability from github – Published: 2026-08-28 16:13 – Updated: 2026-08-28 16:13
VLAI
Summary
KubeVela Terraform remote loader DoS via unbounded file read
Details

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.

  • 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
  1. 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:
    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.

  1. Apply the manifest and observe vela-core:
kubectl apply -f poc-componentdefinition.yaml
kubectl -n vela-system get pods -l app.kubernetes.io/name=vela-core -w
  1. Confirm the OOMKilled termination:
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:

"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.

Severity
8.5 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oam-dev/kubevela"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oam-dev/kubevela"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0-alpha.1"
            },
            {
              "fixed": "1.10.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oam-dev/kubevela"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.11.0-alpha.1"
            },
            {
              "fixed": "1.11.0-alpha.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55108"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:13:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nKubeVela\u0027s 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: \u003cgit repository URL\u003e\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 -\u003e ../../../../../../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 \u0026\u0026 cd poc-tf-dos\nln -s ../../../../../../dev/zero variables.tf\ngit add variables.tf \u0026\u0026 git commit -m \"poc\"\ngit remote add origin https://github.com/\u003cYOUR_ORG\u003e/\u003cYOUR_REPO\u003e.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/\u003cYOUR_ORG\u003e/\u003cYOUR_REPO\u003e.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=\u0027{.items[0].status.containerStatuses[0].lastState.terminated}{\"\\n\"}\u0027\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/\u003cname\u003e` 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.",
  "id": "GHSA-fmgp-q6jx-gg3x",
  "modified": "2026-08-28T16:13:19Z",
  "published": "2026-08-28T16:13:19Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "KubeVela Terraform remote loader DoS via unbounded file read"
}

GHSA-FMGX-6M2H-QH4R

Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18
VLAI
Details

In Wireshark 3.2.0 to 3.2.3, 3.0.0 to 3.0.10, and 2.6.0 to 2.6.16, the NFS dissector could crash. This was addressed in epan/dissectors/packet-nfs.c by preventing excessive recursion, such as for a cycle in the directory graph on a filesystem.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-19T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Wireshark 3.2.0 to 3.2.3, 3.0.0 to 3.0.10, and 2.6.0 to 2.6.16, the NFS dissector could crash. This was addressed in epan/dissectors/packet-nfs.c by preventing excessive recursion, such as for a cycle in the directory graph on a filesystem.",
  "id": "GHSA-fmgx-6m2h-qh4r",
  "modified": "2022-05-24T17:18:11Z",
  "published": "2022-05-24T17:18:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13164"
    },
    {
      "type": "WEB",
      "url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16476"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=e6e98eab8e5e0bbc982cfdc808f2469d7cab6c5a"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5UOISPQTRCZGQLKBVXEDL72AEXEHS425"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DNV3EYL4JBWCR22TJO3PH7ADUVS5RWSU"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202007-13"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2020-08.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00038.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-FMMJ-449G-8XVH

Vulnerability from github – Published: 2026-05-12 21:31 – Updated: 2026-05-12 21:31
VLAI
Details

CAI Content Credentials versions 0.78.2, 0.7.0 and earlier are affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-34673"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T20:16:37Z",
    "severity": "MODERATE"
  },
  "details": "CAI Content Credentials versions 0.78.2, 0.7.0 and earlier are affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-fmmj-449g-8xvh",
  "modified": "2026-05-12T21:31:34Z",
  "published": "2026-05-12T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34673"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/content-authenticity-sdk/apsb26-53.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list