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-VMF7-HMH6-VV57

Vulnerability from github – Published: 2022-03-05 00:00 – Updated: 2022-03-18 20:06
VLAI
Summary
Denial of Service in Go-Ethereum
Details

A design flaw in all versions of Go-Ethereum allows an attacker node to send 5120 pending transactions of a high gas price from one account that all fully spend the full balance of the account to a victim Geth node, which can purge all of pending transactions in a victim node's memory pool and then occupy the memory pool to prevent new transactions from entering the pool, resulting in a denial of service (DoS).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ethereum/go-ethereum"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.10.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-09T19:20:00Z",
    "nvd_published_at": "2022-03-04T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "A design flaw in all versions of Go-Ethereum allows an attacker node to send 5120 pending transactions of a high gas price from one account that all fully spend the full balance of the account to a victim Geth node, which can purge all of pending transactions in a victim node\u0027s memory pool and then occupy the memory pool to prevent new transactions from entering the pool, resulting in a denial of service (DoS).",
  "id": "GHSA-vmf7-hmh6-vv57",
  "modified": "2022-03-18T20:06:58Z",
  "published": "2022-03-05T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23328"
    },
    {
      "type": "WEB",
      "url": "https://dl.acm.org/doi/pdf/10.1145/3460120.3485369"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ethereum/go-ethereum"
    },
    {
      "type": "WEB",
      "url": "https://tristartom.github.io/docs/ccs21.pdf"
    },
    {
      "type": "WEB",
      "url": "http://ethereum.com"
    },
    {
      "type": "WEB",
      "url": "http://go-ethereum.com"
    }
  ],
  "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": "Denial of Service in Go-Ethereum"
}

GHSA-VMHP-2G3X-CWWQ

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

In readBlock of MatroskaExtractor.cpp, there is a possible denial of service due to resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-156819528

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-0491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-15T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In readBlock of MatroskaExtractor.cpp, there is a possible denial of service due to resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-156819528",
  "id": "GHSA-vmhp-2g3x-cwwq",
  "modified": "2022-05-24T17:36:25Z",
  "published": "2022-05-24T17:36:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0491"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2020-12-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VMQM-G3VH-847M

Vulnerability from github – Published: 2020-06-15 18:51 – Updated: 2021-07-22 22:28
VLAI
Summary
Denial of service in Apache Xerces2
Details

Apache Xerces2 Java Parser before 2.12.0 allows remote attackers to cause a denial of service (CPU consumption) via a crafted message to an XML service, which triggers hash table collisions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "xerces:xercesImpl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2012-0881"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-15T15:51:37Z",
    "nvd_published_at": "2017-10-30T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Apache Xerces2 Java Parser before 2.12.0 allows remote attackers to cause a denial of service (CPU consumption) via a crafted message to an XML service, which triggers hash table collisions.",
  "id": "GHSA-vmqm-g3vh-847m",
  "modified": "2021-07-22T22:28:36Z",
  "published": "2020-06-15T18:51:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/xerces2-j/commit/992b5d9c24102ad20330d36c0a71162753a37449"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2014/07/08/11"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rea7b831dceeb2a2fa817be6f63b08722042e3647fb2d47c144370a56@%3Ccommon-issues.hadoop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rea7b831dceeb2a2fa817be6f63b08722042e3647fb2d47c144370a56%40%3Ccommon-issues.hadoop.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r204ba2a9ea750f38d789d2bb429cc0925ad6133deea7cbc3001d96b5@%3Csolr-user.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r204ba2a9ea750f38d789d2bb429cc0925ad6133deea7cbc3001d96b5%40%3Csolr-user.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f9bc3e55f4e28d1dcd1a69aae6d53e609a758e34d2869b4d798e13cc@%3Cissues.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f9bc3e55f4e28d1dcd1a69aae6d53e609a758e34d2869b4d798e13cc%40%3Cissues.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b0656d359c7d40ec9f39c8cc61bca66802ef9a2a12ee199f5b0c1442@%3Cdev.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b0656d359c7d40ec9f39c8cc61bca66802ef9a2a12ee199f5b0c1442%40%3Cdev.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451@%3Csolr-user.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451%40%3Csolr-user.lucene.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/519eb0fd45642dcecd9ff74cb3e71c20a4753f7d82e2f07864b5108f@%3Cdev.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/519eb0fd45642dcecd9ff74cb3e71c20a4753f7d82e2f07864b5108f%40%3Cdev.drill.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/49dc6702104a86ecbb40292dcd329ce9ae4c32b74733199ecab14a73@%3Cj-users.xerces.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/49dc6702104a86ecbb40292dcd329ce9ae4c32b74733199ecab14a73%40%3Cj-users.xerces.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/XERCESJ-1685"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=787104"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of service in Apache Xerces2"
}

GHSA-VMRH-MJ92-7WJ2

Vulnerability from github – Published: 2022-05-14 03:22 – Updated: 2022-05-14 03:22
VLAI
Details

Huawei AR1200 V200R006C10SPC300, AR160 V200R006C10SPC300, AR200 V200R006C10SPC300, AR2200 V200R006C10SPC300, AR3200 V200R006C10SPC300 devices have an improper resource management vulnerability. Due to the improper implementation of ACL mechanism, a remote attacker may send TCP messages to the management interface of the affected device to exploit this vulnerability. Successful exploit could exhaust the socket resource of management interface, leading to a DoS condition.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-7920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-19T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "Huawei AR1200 V200R006C10SPC300, AR160 V200R006C10SPC300, AR200 V200R006C10SPC300, AR2200 V200R006C10SPC300, AR3200 V200R006C10SPC300 devices have an improper resource management vulnerability. Due to the improper implementation of ACL mechanism, a remote attacker may send TCP messages to the management interface of the affected device to exploit this vulnerability. Successful exploit could exhaust the socket resource of management interface, leading to a DoS condition.",
  "id": "GHSA-vmrh-mj92-7wj2",
  "modified": "2022-05-14T03:22:02Z",
  "published": "2022-05-14T03:22:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7920"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20180418-01-ar-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VMWJ-88GQ-629H

Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-08-06 00:00
VLAI
Details

On Juniper Networks Junos OS platforms with link aggregation (lag) configured, executing any operation that fetches Aggregated Ethernet (AE) interface statistics, including but not limited to SNMP GET requests, causes a slow kernel memory leak. If all the available memory is consumed, the traffic will be impacted and a reboot might be required. The following log can be seen if this issue happens. /kernel: rt_pfe_veto: Memory over consumed. Op 1 err 12, rtsm_id 0:-1, msg type 72 /kernel: rt_pfe_veto: free kmem_map memory = (20770816) curproc = kmd An administrator can use the following CLI command to monitor the status of memory consumption (ifstat bucket): user@device > show system virtual-memory no-forwarding | match ifstat Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ifstat 2588977 162708K - 19633958 <<<< user@device > show system virtual-memory no-forwarding | match ifstat Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ifstat 3021629 189749K - 22914415 <<<< This issue does not affect the following platforms: Juniper Networks MX Series. Juniper Networks PTX1000-72Q, PTX3000, PTX5000, PTX10001, PTX10002-60C, PTX10003_160C, PTX10003_80C, PTX10003_81CD, PTX10004, PTX10008, PTX10016 Series. Juniper Networks EX9200 Series. Juniper Networks ACX710, ACX6360 Series. Juniper Networks NFX Series. This issue affects Juniper Networks Junos OS: 17.1 versions 17.1R3 and above prior to 17.3R3-S11; 17.4 versions prior to 17.4R3-S5; 18.2 versions prior to 18.2R3-S7, 18.2R3-S8; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R1-S6; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2-S2, 20.2R3; 20.3 versions prior to 20.3R1-S2, 20.3R2. This issue does not affect Juniper Networks Junos OS prior to 17.1R3.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-0230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-22T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "On Juniper Networks Junos OS platforms with link aggregation (lag) configured, executing any operation that fetches Aggregated Ethernet (AE) interface statistics, including but not limited to SNMP GET requests, causes a slow kernel memory leak. If all the available memory is consumed, the traffic will be impacted and a reboot might be required. The following log can be seen if this issue happens. /kernel: rt_pfe_veto: Memory over consumed. Op 1 err 12, rtsm_id 0:-1, msg type 72 /kernel: rt_pfe_veto: free kmem_map memory = (20770816) curproc = kmd An administrator can use the following CLI command to monitor the status of memory consumption (ifstat bucket): user@device \u003e show system virtual-memory no-forwarding | match ifstat Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ifstat 2588977 162708K - 19633958 \u003c\u003c\u003c\u003c user@device \u003e show system virtual-memory no-forwarding | match ifstat Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ifstat 3021629 189749K - 22914415 \u003c\u003c\u003c\u003c This issue does not affect the following platforms: Juniper Networks MX Series. Juniper Networks PTX1000-72Q, PTX3000, PTX5000, PTX10001, PTX10002-60C, PTX10003_160C, PTX10003_80C, PTX10003_81CD, PTX10004, PTX10008, PTX10016 Series. Juniper Networks EX9200 Series. Juniper Networks ACX710, ACX6360 Series. Juniper Networks NFX Series. This issue affects Juniper Networks Junos OS: 17.1 versions 17.1R3 and above prior to 17.3R3-S11; 17.4 versions prior to 17.4R3-S5; 18.2 versions prior to 18.2R3-S7, 18.2R3-S8; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R1-S6; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2-S2, 20.2R3; 20.3 versions prior to 20.3R1-S2, 20.3R2. This issue does not affect Juniper Networks Junos OS prior to 17.1R3.",
  "id": "GHSA-vmwj-88gq-629h",
  "modified": "2022-08-06T00:00:42Z",
  "published": "2022-05-24T17:48:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0230"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11125"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VP26-RMJ2-HJ2C

Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2024-08-01 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

jfs: fix slab-out-of-bounds Read in dtSearch

Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error.

Dave: Set return code to -EIO

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-52602"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-06T07:15:10Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix slab-out-of-bounds Read in dtSearch\n\nCurrently while searching for current page in the sorted entry table\nof the page there is a out of bound access. Added a bound check to fix\nthe error.\n\nDave:\nSet return code to -EIO",
  "id": "GHSA-vp26-rmj2-hj2c",
  "modified": "2024-08-01T15:31:30Z",
  "published": "2024-03-06T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52602"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VP2X-QP44-57V7

Vulnerability from github – Published: 2026-09-02 14:34 – Updated: 2026-09-02 14:34
VLAI
Summary
NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`
Details

Summary

XMLCorpusView._read_xml_fragment() reads a corpus file in 1 KiB blocks, appending each block to a growing fragment string, then calls _VALID_XML_RE.match(fragment) on the full accumulated buffer every iteration. Because each iteration rescans the entire accumulated fragment, the total amount of work grows quadratically with input size.

Commit c9c332284 (CWE-1333) made each match() call linear. The quadratic behavior is separate: the loop calls match() once per 1 KiB block, each time on a longer buffer.

On the test system, an 8 MiB malformed XML file consumed approximately 48 CPU-seconds through the public BNCCorpusReader.words() API with no source modification. Absolute timings vary by hardware. _read_xml_fragment() imposes no limit on fragment size or iteration count.

Details

File: nltk/corpus/reader/xmldocs.py
Function: XMLCorpusView._read_xml_fragment(), lines 261–308

The relevant loop:

fragment = ""
while True:
    fragment += stream.read(self._BLOCK_SIZE)      # grows by 1 KiB per iteration
    if self._VALID_XML_RE.match(fragment):         # rescans full buffer each time
        return fragment
    ...
    last_open_bracket = fragment.rfind("<")
    if last_open_bracket > 0:                      # False for single-'<' payload
        if self._VALID_XML_RE.match(fragment[:last_open_bracket]):
            return ...
    # loop continues

For a payload of b'<' + b'a' * (N-1):

  • For this malformed input, _VALID_XML_RE.match(fragment) does not succeed because the unterminated tag prevents the expression from matching before EOF.
  • fragment.rfind("<") returns 0; the guard last_open_bracket > 0 is False, so the backtrack branch is never taken.
  • The only exit is EOF, after all N bytes are consumed.

Affected readers -> readers that rely on XMLCorpusView, including BNCCorpusReader, NPSChatCorpusReader, SemcorCorpusReader, MTECorpusReader, NKJPCorpusReader, FrameNetCorpusReader, VerbNetCorpusReader, and direct XMLCorpusView instantiation. XMLCorpusReader.xml() is not affected -> it calls defusedxml.safe_parse().

PoC

Requires only pip install nltk. No corpus data needed.

from pathlib import Path
from tempfile import TemporaryDirectory
from time import perf_counter
from nltk.corpus.reader.bnc import BNCCorpusReader

SIZES_KIB = (256, 512, 1024, 2048, 4096, 8192)
results = []
with TemporaryDirectory() as directory:
    root = Path(directory)
    malformed = root / "unterminated.xml"
    for kib in SIZES_KIB:
        malformed.write_bytes(b"<" + b"a" * (kib * 1024 - 1))
        t = perf_counter()
        try:
            list(BNCCorpusReader(str(root), [malformed.name]).words())
        except ValueError as e:
            assert "tag not closed" in str(e)
        results.append(perf_counter() - t)

print("KiB      seconds   growth")
for i, (kib, elapsed) in enumerate(zip(SIZES_KIB, results)):
    ratio = "-" if i == 0 else f"{elapsed / results[i-1]:.2f}x"
    print(f"{kib:5d}  {elapsed:9.3f}  {ratio}")

Runtime should increase by approximately fourfold for each doubling of input size, although absolute timings vary by hardware.

During verification, _VALID_XML_RE.match() was instrumented to record the size of each input. For a 256 KiB malformed file it was invoked 257 times on monotonically increasing buffers (1024, 2048, …, 262144 bytes), with the final call occurring after EOF. This confirms that every iteration rescans the accumulated fragment.

Impact

Applications that process attacker-controlled XML corpus files through an affected reader are vulnerable. The attacker needs only write access to a path the reader will open. No NLTK credentials or special privileges required. Offline tools reading only trusted local corpora are not at risk.

Affected versions: Verified in NLTK 3.9.4, 3.10.0, and the current develop branch. Historical inspection indicates the same loop structure has existed since the introduction of XMLCorpusView (2007), but only the listed versions were experimentally verified. No patch exists in any published release.

This issue results in CPU exhaustion and may allow denial of service in applications that process attacker-controlled XML corpus files.

Suggested Fix

Avoid rescanning the accumulated fragment from the beginning after each 1 KiB read. Incremental parsing, bounded fragment accumulation, or another streaming approach would eliminate the quadratic behavior while preserving existing semantics.

A regression test should verify that BNCCorpusReader.words() raises ValueError within a fixed timeout (e.g. 5 seconds) against a 2 MiB malformed input. The existing test_xmldocs_security.py covers only the prior ReDoS payloads and does not exercise this path.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-81723"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-02T14:34:11Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`XMLCorpusView._read_xml_fragment()` reads a corpus file in 1 KiB blocks, appending\neach block to a growing `fragment` string, then calls `_VALID_XML_RE.match(fragment)`\non the full accumulated buffer every iteration. Because each iteration rescans the\nentire accumulated fragment, the total amount of work grows quadratically with input\nsize.\n\nCommit `c9c332284` (CWE-1333) made each `match()` call linear. The quadratic behavior\nis separate: the loop calls `match()` once per 1 KiB block, each time on a longer\nbuffer.\n\nOn the test system, an 8 MiB malformed XML file consumed approximately 48 CPU-seconds\nthrough the public `BNCCorpusReader.words()` API with no source modification. Absolute\ntimings vary by hardware. `_read_xml_fragment()` imposes no limit on fragment size or\niteration count.\n\n## Details\n\n**File:** `nltk/corpus/reader/xmldocs.py`  \n**Function:** `XMLCorpusView._read_xml_fragment()`, lines 261\u2013308\n\nThe relevant loop:\n\n```python\nfragment = \"\"\nwhile True:\n    fragment += stream.read(self._BLOCK_SIZE)      # grows by 1 KiB per iteration\n    if self._VALID_XML_RE.match(fragment):         # rescans full buffer each time\n        return fragment\n    ...\n    last_open_bracket = fragment.rfind(\"\u003c\")\n    if last_open_bracket \u003e 0:                      # False for single-\u0027\u003c\u0027 payload\n        if self._VALID_XML_RE.match(fragment[:last_open_bracket]):\n            return ...\n    # loop continues\n```\n\nFor a payload of `b\u0027\u003c\u0027 + b\u0027a\u0027 * (N-1)`:\n\n- For this malformed input, `_VALID_XML_RE.match(fragment)` does not succeed because\n  the unterminated tag prevents the expression from matching before EOF.\n- `fragment.rfind(\"\u003c\")` returns `0`; the guard `last_open_bracket \u003e 0` is `False`, so\n  the backtrack branch is never taken.\n- The only exit is EOF, after all N bytes are consumed.\n\n**Affected readers** -\u003e readers that rely on `XMLCorpusView`, including\n`BNCCorpusReader`, `NPSChatCorpusReader`, `SemcorCorpusReader`, `MTECorpusReader`,\n`NKJPCorpusReader`, `FrameNetCorpusReader`, `VerbNetCorpusReader`, and direct\n`XMLCorpusView` instantiation. `XMLCorpusReader.xml()` is not affected -\u003e it calls\n`defusedxml.safe_parse()`.\n\n## PoC\n\nRequires only `pip install nltk`. No corpus data needed.\n\n```python\nfrom pathlib import Path\nfrom tempfile import TemporaryDirectory\nfrom time import perf_counter\nfrom nltk.corpus.reader.bnc import BNCCorpusReader\n\nSIZES_KIB = (256, 512, 1024, 2048, 4096, 8192)\nresults = []\nwith TemporaryDirectory() as directory:\n    root = Path(directory)\n    malformed = root / \"unterminated.xml\"\n    for kib in SIZES_KIB:\n        malformed.write_bytes(b\"\u003c\" + b\"a\" * (kib * 1024 - 1))\n        t = perf_counter()\n        try:\n            list(BNCCorpusReader(str(root), [malformed.name]).words())\n        except ValueError as e:\n            assert \"tag not closed\" in str(e)\n        results.append(perf_counter() - t)\n\nprint(\"KiB      seconds   growth\")\nfor i, (kib, elapsed) in enumerate(zip(SIZES_KIB, results)):\n    ratio = \"-\" if i == 0 else f\"{elapsed / results[i-1]:.2f}x\"\n    print(f\"{kib:5d}  {elapsed:9.3f}  {ratio}\")\n```\n\nRuntime should increase by approximately fourfold for each doubling of input size,\nalthough absolute timings vary by hardware.\n\nDuring verification, `_VALID_XML_RE.match()` was instrumented to record the size of\neach input. For a 256 KiB malformed file it was invoked 257 times on monotonically\nincreasing buffers (1024, 2048, \u2026, 262144 bytes), with the final call occurring after\nEOF. This confirms that every iteration rescans the accumulated fragment.\n\n## Impact\n\nApplications that process attacker-controlled XML corpus files through an affected reader\nare vulnerable. The attacker needs only write access to a path the reader will open. No\nNLTK credentials or special privileges required. Offline tools reading only trusted\nlocal corpora are not at risk.\n\n**Affected versions:** Verified in NLTK 3.9.4, 3.10.0, and the current develop branch.\nHistorical inspection indicates the same loop structure has existed since the\nintroduction of `XMLCorpusView` (2007), but only the listed versions were\nexperimentally verified. No patch exists in any published release.\n\nThis issue results in CPU exhaustion and may allow denial of service in applications\nthat process attacker-controlled XML corpus files.\n\n## Suggested Fix\n\nAvoid rescanning the accumulated fragment from the beginning after each 1 KiB read.\nIncremental parsing, bounded fragment accumulation, or another streaming approach would\neliminate the quadratic behavior while preserving existing semantics.\n\nA regression test should verify that `BNCCorpusReader.words()` raises `ValueError`\nwithin a fixed timeout (e.g. 5 seconds) against a 2 MiB malformed input. The existing\n`test_xmldocs_security.py` covers only the prior ReDoS payloads and does not exercise\nthis path.",
  "id": "GHSA-vp2x-qp44-57v7",
  "modified": "2026-09-02T14:34:11Z",
  "published": "2026-09-02T14:34:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-vp2x-qp44-57v7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81723"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/7808692d451b962711005d954859bb83aabcf8fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nltk/nltk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/releases/tag/v3.10.3"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-before-3.10.3-quadratic-cpu-exhaustion-via-xmlcorpusview"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`"
}

GHSA-VP43-WPFX-V79M

Vulnerability from github – Published: 2024-06-25 21:31 – Updated: 2024-06-25 21:31
VLAI
Details

In WhatsUp Gold versions released before 2023.1.3, an unauthenticated Denial of Service

vulnerability was identified. An unauthenticated attacker can put the application into the SetAdminPassword installation step, which renders the application non-accessible.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-5013"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-25T21:16:00Z",
    "severity": "HIGH"
  },
  "details": "In WhatsUp Gold versions released before 2023.1.3,\u00a0an unauthenticated Denial of Service \n\nvulnerability was identified.\u00a0An unauthenticated attacker can put the application into the SetAdminPassword installation step, which renders the application non-accessible.",
  "id": "GHSA-vp43-wpfx-v79m",
  "modified": "2024-06-25T21:31:17Z",
  "published": "2024-06-25T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5013"
    },
    {
      "type": "WEB",
      "url": "https://community.progress.com/s/article/WhatsUp-Gold-Security-Bulletin-June-2024"
    },
    {
      "type": "WEB",
      "url": "https://www.progress.com/network-monitoring"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VP52-PCJ8-J9QC

Vulnerability from github – Published: 2026-09-01 21:32 – Updated: 2026-09-01 21:32
VLAI
Summary
gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation
Details

Impact

An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.

Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).

Patches

The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.

Workarounds

This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.

This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.83.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "google.golang.org/grpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.83.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-84304"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-01T21:32:41Z",
    "nvd_published_at": "2026-09-01T19:17:30Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAn unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.\n\nRepeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).\n\n### Patches\nThe change to fix this issue is merged in `master` and a patch release, 1.83.1, has been published that contains this fix.\n\n### Workarounds\nThis vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.\n\nThis behavior is enabled by default. A temporary escape hatch is provided via the environment variable `GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false` to disable the feature if unforeseen issues arise, but it will be removed in a future release.",
  "id": "GHSA-vp52-pcj8-j9qc",
  "modified": "2026-09-01T21:32:41Z",
  "published": "2026-09-01T21:32:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-vp52-pcj8-j9qc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84304"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/pull/9331"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/pull/9333"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/commit/7354d9c8debb4bcf2225bf429857078de310c176"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/commit/8cfeca0e1ee5ea0980dcc320e20240fa1079ec77"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/releases/tag/v1.83.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation"
}

GHSA-VP56-6G26-6827

Vulnerability from github – Published: 2022-08-02 00:00 – Updated: 2022-08-04 17:37
VLAI
Summary
node-fetch Inefficient Regular Expression Complexity
Details

node-fetch is a light-weight module that brings window.fetch to node.js.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in the isOriginPotentiallyTrustworthy() function in referrer.js, when processing a URL string with alternating letters and periods, such as 'http://' + 'a.a.'.repeat(i) + 'a'.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "node-fetch"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-2596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-04T17:37:24Z",
    "nvd_published_at": "2022-08-01T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "[node-fetch](https://www.npmjs.com/package/node-fetch) is a light-weight module that brings window.fetch to node.js.\n\nAffected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in the `isOriginPotentiallyTrustworthy()` function in `referrer.js`, when processing a URL string with alternating letters and periods, such as `\u0027http://\u0027 + \u0027a.a.\u0027.repeat(i) + \u0027a\u0027`.",
  "id": "GHSA-vp56-6g26-6827",
  "modified": "2022-08-04T17:37:24Z",
  "published": "2022-08-02T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2596"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-fetch/node-fetch/pull/1611"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-fetch/node-fetch/commit/28802387292baee467e042e168d92597b5bbbe3d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/node-fetch/node-fetch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-fetch/node-fetch/releases/tag/v3.2.10"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/a7e6a136-0a4b-46c4-ad20-802f1dd60bf7"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "node-fetch Inefficient Regular Expression Complexity "
}
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