Common Weakness Enumeration

CWE-774

Allowed

Allocation of File Descriptors or Handles Without Limits or Throttling

Abstraction: Variant · Status: Incomplete

The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.

6 vulnerabilities reference this CWE, most recent first.

CVE-2026-27887 (GCVE-0-2026-27887)

Vulnerability from cvelistv5 – Published: 2026-02-26 00:55 – Updated: 2026-02-26 14:34
VLAI
Title
Spin has memory leaks in various WIT interfaces
Summary
Spin is an open source developer tool for building and running serverless applications powered by WebAssembly. When Spin is configured to allow connections to a database or web server which could return responses of unbounded size (e.g. tables with many rows or large content bodies), Spin may in some cases attempt to buffer the entire response before delivering it to the guest, which can lead to the host process running out of memory, panicking, and crashing. In addition, a malicious guest application could incrementally insert a large number of rows or values into a database and then retrieve them all in a single query, leading to large host allocations. Spin 3.6.1, SpinKube 0.6.2, and `containerd-shim-spin` 0.22.1 have been patched to address the issue. As a workaround, configure Spin to only allow access to trusted databases and HTTP servers which limit response sizes.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-770 - Allocation of Resources Without Limits or Throttling
  • CWE-774 - Allocation of File Descriptors or Handles Without Limits or Throttling
  • CWE-789 - Memory Allocation with Excessive Size Value
Assigner
References
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-27887",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-02-26T14:34:14.519689Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-02-26T14:34:29.169Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "spin",
          "vendor": "spinframework",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.6.1"
            }
          ]
        },
        {
          "product": "SpinKube",
          "vendor": "spinframework",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.6.2"
            }
          ]
        },
        {
          "product": "containerd-shim-spin",
          "vendor": "spinframework",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.22.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Spin is an open source developer tool for building and running serverless applications powered by WebAssembly. When Spin is configured to allow connections to a database or web server which could return responses of unbounded size (e.g. tables with many rows or large content bodies), Spin may in some cases attempt to buffer the entire response before delivering it to the guest, which can lead to the host process running out of memory, panicking, and crashing. In addition, a malicious guest application could incrementally insert a large number of rows or values into a database and then retrieve them all in a single query, leading to large host allocations. Spin 3.6.1, SpinKube 0.6.2, and `containerd-shim-spin` 0.22.1 have been patched to address the issue. As a workaround, configure Spin to only allow access to trusted databases and HTTP servers which limit response sizes."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-774",
              "description": "CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789: Memory Allocation with Excessive Size Value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-26T00:55:53.360Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/spinframework/spin/security/advisories/GHSA-mv4f-6ffm-32wx",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/spinframework/spin/security/advisories/GHSA-mv4f-6ffm-32wx"
        }
      ],
      "source": {
        "advisory": "GHSA-mv4f-6ffm-32wx",
        "discovery": "UNKNOWN"
      },
      "title": "Spin has memory leaks in various WIT interfaces"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-27887",
    "datePublished": "2026-02-26T00:55:53.360Z",
    "dateReserved": "2026-02-24T15:19:29.716Z",
    "dateUpdated": "2026-02-26T14:34:29.169Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-27204 (GCVE-0-2026-27204)

Vulnerability from cvelistv5 – Published: 2026-02-24 21:23 – Updated: 2026-02-27 20:54
VLAI
Title
Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion
Summary
Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.6, 36.0.6, 4.0.04, 41.0.4, and 42.0.0, 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. 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. 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.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-400 - Uncontrolled Resource Consumption
  • CWE-770 - Allocation of Resources Without Limits or Throttling
  • CWE-774 - Allocation of File Descriptors or Handles Without Limits or Throttling
  • CWE-789 - Memory Allocation with Excessive Size Value
Assigner
Impacted products
Vendor Product Version
bytecodealliance wasmtime Affected: < 24.0.6
Affected: >= 25.0.0, < 36.0.6
Affected: >= 37.0.0, < 40.0.4
Affected: >= 41.0.0, < 41.0.4
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-27204",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-02-27T20:54:41.376330Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-02-27T20:54:48.839Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "wasmtime",
          "vendor": "bytecodealliance",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 24.0.6"
            },
            {
              "status": "affected",
              "version": "\u003e= 25.0.0, \u003c 36.0.6"
            },
            {
              "status": "affected",
              "version": "\u003e= 37.0.0, \u003c 40.0.4"
            },
            {
              "status": "affected",
              "version": "\u003e= 41.0.0, \u003c 41.0.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.6, 36.0.6, 4.0.04, 41.0.4, and 42.0.0, Wasmtime\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. 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. 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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400: Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-774",
              "description": "CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789: Memory Allocation with Excessive Size Value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-24T21:23:47.007Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w"
        },
        {
          "name": "https://github.com/bytecodealliance/wasmtime/issues/11552",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/bytecodealliance/wasmtime/issues/11552"
        },
        {
          "name": "https://github.com/bytecodealliance/wasmtime/pull/12599",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/bytecodealliance/wasmtime/pull/12599"
        },
        {
          "name": "https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size"
        },
        {
          "name": "https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity"
        },
        {
          "name": "https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel"
        },
        {
          "name": "https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html"
        }
      ],
      "source": {
        "advisory": "GHSA-852m-cvvp-9p4w",
        "discovery": "UNKNOWN"
      },
      "title": "Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-27204",
    "datePublished": "2026-02-24T21:23:47.007Z",
    "dateReserved": "2026-02-18T19:47:02.155Z",
    "dateUpdated": "2026-02-27T20:54:48.839Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2024-48848 (GCVE-0-2024-48848)

Vulnerability from cvelistv5 – Published: 2025-05-22 18:18 – Updated: 2025-05-22 18:41
VLAI
Title
LARGECONTENT - device disk overutilization
Summary
Large content vulnerabilities are present in ASPECT exposing a device to disk overutilization on a system if administrator credentials become compromisedThis issue affects ASPECT-Enterprise: through 3.*; NEXUS Series: through 3.*; MATRIX Series: through 3.*.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-774 - Allocation of File Descriptors or Handles Without Limits or Throttling
Assigner
ABB
Impacted products
Vendor Product Version
ABB ASPECT-Enterprise Affected: 0 , ≤ 3.* (custom)
Create a notification for this product.
ABB NEXUS Series Affected: 0 , ≤ 3.* (custom)
Create a notification for this product.
ABB MATRIX Series Affected: 0 , ≤ 3.* (custom)
Create a notification for this product.
Credits
ABB likes to thank Gjoko Krstikj, Zero Science Lab, for reporting the vulnerabilities in responsible disclosure
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-48848",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-05-22T18:38:11.746939Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-05-22T18:41:30.763Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "affected",
          "platforms": [
            "Linux"
          ],
          "product": "ASPECT-Enterprise",
          "vendor": "ABB",
          "versions": [
            {
              "lessThanOrEqual": "3.*",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Linux"
          ],
          "product": "NEXUS Series",
          "vendor": "ABB",
          "versions": [
            {
              "lessThanOrEqual": "3.*",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "Linux"
          ],
          "product": "MATRIX Series",
          "vendor": "ABB",
          "versions": [
            {
              "lessThanOrEqual": "3.*",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "ABB likes to thank Gjoko Krstikj, Zero Science Lab, for reporting the vulnerabilities in responsible disclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Large content vulnerabilities are present in ASPECT exposing a device to disk overutilization on a system if administrator credentials become compromised\u003cp\u003eThis issue affects ASPECT-Enterprise: through 3.*; NEXUS Series: through 3.*; MATRIX Series: through 3.*.\u003c/p\u003e"
            }
          ],
          "value": "Large content vulnerabilities are present in ASPECT exposing a device to disk overutilization on a system if administrator credentials become compromisedThis issue affects ASPECT-Enterprise: through 3.*; NEXUS Series: through 3.*; MATRIX Series: through 3.*."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-774",
              "description": "CWE-774 Allocation of File Descriptors or Handles Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-22T18:18:03.426Z",
        "orgId": "2b718523-d88f-4f37-9bbd-300c20644bf9",
        "shortName": "ABB"
      },
      "references": [
        {
          "url": "https://search.abb.com/library/Download.aspx?DocumentID=9AKK108471A0021\u0026LanguageCode=en\u0026DocumentPartId=pdf\u0026Action=Launch"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "LARGECONTENT - device disk overutilization",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "2b718523-d88f-4f37-9bbd-300c20644bf9",
    "assignerShortName": "ABB",
    "cveId": "CVE-2024-48848",
    "datePublished": "2025-05-22T18:18:03.426Z",
    "dateReserved": "2024-10-08T17:24:01.445Z",
    "dateUpdated": "2025-05-22T18:41:30.763Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

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

Show details on source website

{
  "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-PJG9-5V2Q-9FPF

Vulnerability from github – Published: 2025-05-22 21:30 – Updated: 2025-05-22 21:30
VLAI
Details

Large content vulnerabilities are present in ASPECT exposing a device to disk overutilization on a system if administrator credentials become compromisedThis issue affects ASPECT-Enterprise: through 3.; NEXUS Series: through 3.; MATRIX Series: through 3.*.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-48848"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-774"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-22T19:15:41Z",
    "severity": "HIGH"
  },
  "details": "Large content vulnerabilities are present in ASPECT exposing a device to disk overutilization on a system if administrator credentials become compromisedThis issue affects ASPECT-Enterprise: through 3.*; NEXUS Series: through 3.*; MATRIX Series: through 3.*.",
  "id": "GHSA-pjg9-5v2q-9fpf",
  "modified": "2025-05-22T21:30:47Z",
  "published": "2025-05-22T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48848"
    },
    {
      "type": "WEB",
      "url": "https://search.abb.com/library/Download.aspx?DocumentID=9AKK108471A0021\u0026LanguageCode=en\u0026DocumentPartId=pdf\u0026Action=Launch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R5W7-F542-Q2J4

Vulnerability from github – Published: 2025-01-28 20:37 – Updated: 2025-01-28 20:37
VLAI
Summary
Potential DoS when using ContextLines integration
Details

Impact

The ContextLines integration uses readable streams to more efficiently use memory when reading files. The ContextLines integration is used to attach source context to outgoing events.

The stream was not explicitly closed after use. This could lead to excessive amounts of file handles open on the system and potentially lead to a Denial of Service (DoS).

The ContextLines integration is enabled by default in the Node SDK (@sentry/node) and SDKs that run in Node.js environments (@sentry/astro, @sentry/aws-serverless, @sentry/bun, @sentry/google-cloud-serverless, @sentry/nestjs, @sentry/nextjs, @sentry/nuxt, @sentry/remix, @sentry/solidstart, @sentry/sveltekit).

Patches

Users should upgrade to version 8.49.0 or higher.

Workarounds

To remediate this issue in affected versions without upgrading to version 8.49.0 and above you can disable the ContextLines integration. See the docs for more details.

Sentry.init({
  // ...
  integrations: function (integrations) {
    // integrations will be all default integrations
    return integrations.filter(function (integration) {
      return integration.name !== "ContextLines";
    });
  },
});

If you disable the ContextLines integration, you will lose source context on your error events.

References

  • Reported issue: https://github.com/getsentry/sentry-javascript/issues/14892
  • PR Fix: https://github.com/getsentry/sentry-javascript/pull/14997
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/aws-serverless"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/bun"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/google-cloud-serverless"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/nestjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/remix"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/solidstart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sentry/sveltekit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.10.0"
            },
            {
              "fixed": "8.49.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-774"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-28T20:37:26Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nThe [ContextLines integration](https://docs.sentry.io/platforms/javascript/guides/node/configuration/integrations/contextlines/) uses readable streams to more efficiently use memory when reading files. The ContextLines integration is used to attach source context to outgoing events.\n\nThe stream was not explicitly closed after use. This could lead to excessive amounts of file handles open on the system and potentially lead to a Denial of Service (DoS).\n\nThe ContextLines integration is enabled by default in the Node SDK (`@sentry/node`) and SDKs that run in Node.js environments (`@sentry/astro`, `@sentry/aws-serverless`, `@sentry/bun`, `@sentry/google-cloud-serverless`, `@sentry/nestjs`, `@sentry/nextjs`, `@sentry/nuxt`, `@sentry/remix`, `@sentry/solidstart`, `@sentry/sveltekit`).\n\n### Patches\n\nUsers should upgrade to version `8.49.0` or higher.\n\n### Workarounds\n\nTo remediate this issue in affected versions without upgrading to version `8.49.0` and above you can disable the ContextLines integration. See the [docs](https://docs.sentry.io/platforms/javascript/guides/node/configuration/integrations/#removing-a-default-integration) for more details.\n\n```js\nSentry.init({\n  // ...\n  integrations: function (integrations) {\n    // integrations will be all default integrations\n    return integrations.filter(function (integration) {\n      return integration.name !== \"ContextLines\";\n    });\n  },\n});\n```\n\nIf you disable the ContextLines integration, you will lose source context on your error events.\n\n### References\n- Reported issue: https://github.com/getsentry/sentry-javascript/issues/14892\n- PR Fix: https://github.com/getsentry/sentry-javascript/pull/14997\n",
  "id": "GHSA-r5w7-f542-q2j4",
  "modified": "2025-01-28T20:37:49Z",
  "published": "2025-01-28T20:37:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry-javascript/security/advisories/GHSA-r5w7-f542-q2j4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry-javascript/issues/14892"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getsentry/sentry-javascript/pull/14997"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getsentry/sentry-javascript"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Potential DoS when using ContextLines integration"
}

Mitigation MIT-47
Operation Architecture and Design

Strategy: Resource Limitation

  • Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
  • When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
  • Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

No CAPEC attack patterns related to this CWE.