Common Weakness Enumeration

CWE-407

Allowed-with-Review

Inefficient Algorithmic Complexity

Abstraction: Class · Status: Incomplete

An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.

377 vulnerabilities reference this CWE, most recent first.

GHSA-R4XH-JQRQ-34V2

Vulnerability from github – Published: 2026-10-05 23:41 – Updated: 2026-10-05 23:41
VLAI
Summary
smol-toml: Quadratic-time parse() from parseKey rescanning to end of document on each key line
Details

Summary

parse() has a quadratic-time path in parseKey, reachable on default options with ordinary valid input. For every key line and table-header line, parseKey (dist/struct.js, lines 58 and 86) finds the dotted-key separator with ctx.s.indexOf('.', ctx.p), where ctx.s is the whole document. When a key has no . ahead of it, that search runs all the way to the end of the input, and the result is then clamped back to the line terminator endPtr - so everything scanned past the current line is wasted. parseKey runs once per line, so a document of N dot-free keys costs O(n^2).

The most ordinary TOML shape triggers it: a flat list of key = value lines, or a repeated [[a]] table. No dotted keys, no special options, valid input throughout.

Proof of concept

import { parse } from 'smol-toml'

let doc = ''
for (let i = 0; i < 256000; i++) doc += 'k' + i + ' = 1\n'

console.time('parse')
parse(doc) // ~2.8 MB of valid TOML, default options
console.timeEnd('parse')

Doubling the line count roughly quadruples the time:

lines size parse()
32k 0.3 MB 0.3 s
64k 0.7 MB 1.0 s
128k 1.4 MB 3.5 s
256k 2.8 MB 14 s

Impact

Any service that runs parse() on attacker-supplied TOML can be stalled. The work is synchronous, so it blocks the whole event loop, and the quadratic is unbounded: a ~7 MB body pins a core for about a minute, larger bodies for several.

Patches

Version 1.9.0 uses a different implementation for parsing keys which is strictly linear.

Workarounds

Limit the maximum document size accepted when parsing arbitrary documents.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "smol-toml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:41:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`parse()` has a quadratic-time path in `parseKey`, reachable on default options with ordinary valid input. For every key line and table-header line, `parseKey` (dist/struct.js, lines 58 and 86) finds the dotted-key separator with `ctx.s.indexOf(\u0027.\u0027, ctx.p)`, where `ctx.s` is the whole document. When a key has no `.` ahead of it, that search runs all the way to the end of the input, and the result is then clamped back to the line terminator `endPtr` - so everything scanned past the current line is wasted. `parseKey` runs once per line, so a document of N dot-free keys costs O(n^2).\n\nThe most ordinary TOML shape triggers it: a flat list of `key = value` lines, or a repeated `[[a]]` table. No dotted keys, no special options, valid input throughout.\n\n### Proof of concept\n\n```js\nimport { parse } from \u0027smol-toml\u0027\n\nlet doc = \u0027\u0027\nfor (let i = 0; i \u003c 256000; i++) doc += \u0027k\u0027 + i + \u0027 = 1\\n\u0027\n\nconsole.time(\u0027parse\u0027)\nparse(doc) // ~2.8 MB of valid TOML, default options\nconsole.timeEnd(\u0027parse\u0027)\n```\n\nDoubling the line count roughly quadruples the time:\n\n| lines | size | parse() |\n|---|---|---|\n| 32k | 0.3 MB | 0.3 s |\n| 64k | 0.7 MB | 1.0 s |\n| 128k | 1.4 MB | 3.5 s |\n| 256k | 2.8 MB | 14 s |\n\n### Impact\nAny service that runs `parse()` on attacker-supplied TOML can be stalled. The work is synchronous, so it blocks the whole event loop, and the quadratic is unbounded: a ~7 MB body pins a core for about a minute, larger bodies for several.\n\n### Patches\nVersion 1.9.0 uses a different implementation for parsing keys which is strictly linear.\n\n### Workarounds\nLimit the maximum document size accepted when parsing arbitrary documents.",
  "id": "GHSA-r4xh-jqrq-34v2",
  "modified": "2026-10-05T23:41:14Z",
  "published": "2026-10-05T23:41:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/squirrelchat/smol-toml/security/advisories/GHSA-r4xh-jqrq-34v2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/squirrelchat/smol-toml/commit/99102aa57fc932f760ea9c15b4cf1c181f952d24"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/squirrelchat/smol-toml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/squirrelchat/smol-toml/releases/tag/v1.9.0"
    }
  ],
  "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": "smol-toml: Quadratic-time parse() from parseKey rescanning to end of document on each key line"
}

GHSA-R5W3-XV2F-J59Q

Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-07-30 18:26
VLAI
Summary
Spring Framework Algorithmic Denial of Service via SpEL Expressions
Details

Applications that evaluate user-supplied Spring Expression Language (SpEL) expressions are vulnerable to an Algorithmic Denial of Service (DoS). By providing a specially crafted expression, an attacker can trigger excessive resource consumption during evaluation, leading to application degradation or unavailability.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-expression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.18"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-expression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.0"
            },
            {
              "fixed": "6.2.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-expression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0"
            },
            {
              "last_affected": "6.1.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework:spring-expression"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.3.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T18:26:06Z",
    "nvd_published_at": "2026-06-09T05:16:37Z",
    "severity": "HIGH"
  },
  "details": "Applications that evaluate user-supplied Spring Expression Language (SpEL) expressions are vulnerable to an Algorithmic Denial of Service (DoS). By providing a specially crafted expression, an attacker can trigger excessive resource consumption during evaluation, leading to application degradation or unavailability.\n\nAffected versions:\nSpring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.",
  "id": "GHSA-r5w3-xv2f-j59q",
  "modified": "2026-07-30T18:26:06Z",
  "published": "2026-06-09T06:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41850"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/spring-framework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-framework/releases/tag/v6.2.19"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-framework/releases/tag/v7.0.8"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-41850"
    }
  ],
  "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": "Spring Framework Algorithmic Denial of Service via SpEL Expressions"
}

GHSA-R8CJ-3554-33MR

Vulnerability from github – Published: 2026-05-08 18:19 – Updated: 2026-05-08 18:19
VLAI
Summary
justhtml introduces denial-of-service hardening
Details

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

  • justhtml < 1.18.0

Fixed version

  • justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

  • applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
  • custom transform or sanitization pipelines that run selector matching over very large untrusted documents
  • applications that construct or mutate DOM trees programmatically from untrusted structure
  • applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

  • shared selector limits for parse and match operations
  • structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
  • match-operation and string-byte budgets
  • per-query matcher state for caches and cycle guards
  • precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
  • consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
  • linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

  • CWE-400: Uncontrolled Resource Consumption
  • CWE-407: Inefficient Algorithmic Complexity
  • CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

  • do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
  • restrict the size of untrusted documents before selector matching or linkification
  • avoid constructing programmatic DOM graphs from untrusted structure
  • avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "justhtml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T18:19:30Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\n`justhtml` `1.18.0` fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.\n\nThese issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.\n\n## Affected versions\n\n- `justhtml` `\u003c 1.18.0`\n\n## Fixed version\n\n- `justhtml` `1.18.0` released on May 4, 2026\n\n## Impact\n\n### CSS selector handling\n\nApplications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.\n\nThe affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as `:not(...)`, repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and `:contains(...)` over large descendant text.\n\nProgrammatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for `:contains(...)`.\n\n### Linkification\n\nAttacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.\n\n## Default configuration\n\nOrdinary sanitization of parsed HTML with the default `JustHTML(..., sanitize=True)` configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.\n\nThe main risk areas are:\n\n- applications that accept selector strings from untrusted users and pass them to `query(...)`, `matches(...)`, or selector-based transforms\n- custom transform or sanitization pipelines that run selector matching over very large untrusted documents\n- applications that construct or mutate DOM trees programmatically from untrusted structure\n- applications that enable `Linkify(...)` over attacker-controlled text\n\n## Fixes in 1.18.0\n\n`1.18.0` adds generalized selector resource controls and removes several repeated-work hot paths:\n\n- shared selector limits for parse and match operations\n- structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth\n- match-operation and string-byte budgets\n- per-query matcher state for caches and cycle guards\n- precomputed or cached ancestor, sibling, positional, attribute-token, text-content, `:not(...)`, `:empty`, and `:nth-child(...)` work\n- consistent enforcement across public parsing, `query(...)`, tag-only query fast paths, transform selector compilation, and sanitization transform matching\n- linkification hardening for punctuation-heavy inputs and trailing bracket trimming\n\n## CWE mapping\n\n- CWE-400: Uncontrolled Resource Consumption\n- CWE-407: Inefficient Algorithmic Complexity\n- CWE-835: Loop with Unreachable Exit Condition\n\n## Recommended action\n\nUpgrade to `justhtml` `1.18.0`.\n\nIf users cannot upgrade immediately:\n\n- do not pass untrusted selector strings to `query(...)`, `matches(...)`, or selector-based transforms\n- restrict the size of untrusted documents before selector matching or linkification\n- avoid constructing programmatic DOM graphs from untrusted structure\n- avoid enabling `Linkify(...)` on very large attacker-controlled text\n\n## Credit\n\nDiscovered during an internal security review of `justhtml`.",
  "id": "GHSA-r8cj-3554-33mr",
  "modified": "2026-05-08T18:19:30Z",
  "published": "2026-05-08T18:19:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/EmilStenstrom/justhtml/security/advisories/GHSA-r8cj-3554-33mr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EmilStenstrom/justhtml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "justhtml introduces denial-of-service hardening"
}

GHSA-RFM6-5393-X9WF

Vulnerability from github – Published: 2025-02-05 12:33 – Updated: 2025-02-05 12:33
VLAI
Details

An issue was discovered in GitLab CE/EE affecting all versions starting from 13.6 prior to 17.2.9, starting from 17.3 prior to 17.3.5, and starting from 17.4 prior to 17.4.2, where viewing diffs of MR with conflicts can be slow.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-9631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-05T11:15:17Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in GitLab CE/EE affecting all versions starting from 13.6 prior to 17.2.9, starting from 17.3 prior to 17.3.5, and starting from 17.4 prior to 17.4.2, where viewing diffs of MR with conflicts can be slow.",
  "id": "GHSA-rfm6-5393-x9wf",
  "modified": "2025-02-05T12:33:07Z",
  "published": "2025-02-05T12:33:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9631"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2650086"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/480867"
    }
  ],
  "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-RH35-RP32-726P

Vulnerability from github – Published: 2026-10-02 12:31 – Updated: 2026-10-02 12:31
VLAI
Details

Inefficient Algorithmic Complexity vulnerability in Apache Thrift PHP bindings.

This issue affects Apache Thrift: before 0.25.0.

Users are recommended to upgrade to version 0.25.0, which fixes the issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-94653"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-02T12:17:24Z",
    "severity": "HIGH"
  },
  "details": "Inefficient Algorithmic Complexity vulnerability in Apache Thrift PHP bindings.\n\n\n\nThis issue affects Apache Thrift: before 0.25.0.\n\n\n\nUsers are recommended to upgrade to version 0.25.0, which fixes the issue.",
  "id": "GHSA-rh35-rp32-726p",
  "modified": "2026-10-02T12:31:19Z",
  "published": "2026-10-02T12:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94653"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/33otcgbqd27wf6qq810q56znzbomnhg1"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/8zbv1y4wzr3nn5mzmdph7b0n6tm0lc4m"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-RJ75-HQRM-R3GF

Vulnerability from github – Published: 2026-10-05 22:53 – Updated: 2026-10-05 22:53
VLAI
Summary
PostCSS: Quadratic complexity in flat selector parsing allows CPU exhaustion
Details

Impact

. and # are not word delimiters in the tokenizer, so a flat selector such as .a.a.a... reaches splitWord() as a single word token carrying n class or id indexes. Three passes scanned those index arrays linearly for every index, making the parse O(n^2) in the number of indexes rather than in input length: uniqs(), the indices.forEach loop, and the Sass-interpolation filter. Parsing a 400 KB flat selector took ~34 s on a modern laptop, fully occupying a single thread. A benign selector of identical byte size parses in tens of milliseconds, so the cost is driven by the index count, not the input size. The nesting depth of such a selector is 0, so the maxNestingDepth guard added in 7.1.3 offers no protection.

Reachability is deployment dependent. Only consumers that parse untrusted, attacker-supplied selectors synchronously in a request path are exposed, for example CSS sanitizers, CSS-in-JS services and online playgrounds. Ordinary build-time use on trusted sources is not affected.

Patches

Fixed in 7.1.6. The three passes now use Set membership tests, making parsing linear in the number of indexes. There is no behaviour change: parsing is byte-identical on a differential corpus of 8413 selectors.

Workarounds

Cap the size of selectors accepted from untrusted sources before parsing.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "postcss-selector-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104844"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:53:54Z",
    "nvd_published_at": "2026-10-02T16:16:46Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`.` and `#` are not word delimiters in the tokenizer, so a flat selector such as\n`.a.a.a...` reaches `splitWord()` as a single word token carrying n class or id\nindexes. Three passes scanned those index arrays linearly for every index,\nmaking the parse O(n^2) in the number of indexes rather than in input length:\n`uniqs()`, the `indices.forEach` loop, and the Sass-interpolation filter.\nParsing a 400 KB flat selector took ~34 s on a modern laptop, fully occupying a\nsingle thread. A benign selector of identical byte size parses in tens of\nmilliseconds, so the cost is driven by the index count, not the input size.\nThe nesting depth of such a selector is 0, so the `maxNestingDepth` guard added\nin 7.1.3 offers no protection.\n\nReachability is deployment dependent. Only consumers that parse untrusted,\nattacker-supplied selectors synchronously in a request path are exposed, for\nexample CSS sanitizers, CSS-in-JS services and online playgrounds. Ordinary\nbuild-time use on trusted sources is not affected.\n\n### Patches\n\nFixed in 7.1.6. The three passes now use Set membership tests, making parsing\nlinear in the number of indexes. There is no behaviour change: parsing is\nbyte-identical on a differential corpus of 8413 selectors.\n\n### Workarounds\n\nCap the size of selectors accepted from untrusted sources before parsing.",
  "id": "GHSA-rj75-hqrm-r3gf",
  "modified": "2026-10-05T22:53:54Z",
  "published": "2026-10-05T22:53:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/postcss/postcss-selector-parser/security/advisories/GHSA-rj75-hqrm-r3gf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104844"
    },
    {
      "type": "WEB",
      "url": "https://github.com/postcss/postcss-selector-parser/commit/62b191792df0a0bc56062e5a875bc74aae2a51cd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/postcss/postcss-selector-parser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/postcss/postcss-selector-parser/releases/tag/7.1.6"
    }
  ],
  "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": "PostCSS: Quadratic complexity in flat selector parsing allows CPU exhaustion"
}

GHSA-RMHM-CWGP-268P

Vulnerability from github – Published: 2024-11-26 21:32 – Updated: 2024-11-26 21:32
VLAI
Details

A denial of service (DoS) condition was discovered in GitLab CE/EE affecting all versions from 13.2.4 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. By leveraging this vulnerability an attacker could create a DoS condition by sending crafted API calls. This was a regression of an earlier patch.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T19:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A denial of service (DoS) condition was discovered in GitLab CE/EE affecting all versions from 13.2.4 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. By leveraging this vulnerability an attacker could create a DoS condition by sending crafted API calls. This was a regression of an earlier patch.",
  "id": "GHSA-rmhm-cwgp-268p",
  "modified": "2024-11-26T21:32:24Z",
  "published": "2024-11-26T21:32:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11828"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2380264"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/443559"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RQFJ-9WMV-VPGP

Vulnerability from github – Published: 2025-04-20 00:31 – Updated: 2025-04-20 00:31
VLAI
Details

mystrtod in mjson 1.2.7 requires more than a billion iterations during processing of certain digit strings such as 8891110122900e913013935755114.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-30421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-19T22:15:14Z",
    "severity": "LOW"
  },
  "details": "mystrtod in mjson 1.2.7 requires more than a billion iterations during processing of certain digit strings such as 8891110122900e913013935755114.",
  "id": "GHSA-rqfj-9wmv-vpgp",
  "modified": "2025-04-20T00:31:40Z",
  "published": "2025-04-20T00:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30421"
    },
    {
      "type": "WEB",
      "url": "https://github.com/boofish/json_bugs/blob/main/mjson"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cesanta/mjson/releases"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V245-V573-V5VM

Vulnerability from github – Published: 2026-07-21 19:06 – Updated: 2026-07-21 19:06
VLAI
Summary
linkify-it: Quadratic-complexity DoS via the `mailto:` validator scan-loop on attacker text
Details

Summary

linkify-it's schema-scan loop (.test() / .match(), the documented public API) invokes the mailto: schema validator at every mailto: occurrence in the input text. For each occurrence the validator does text.slice(pos) (an O(n) copy) and runs an email regex whose local-part class src_email_name greedily scans the entire remaining tail (O(n)) before failing. With N mailto: occurrences that is N × O(n) = O(n²). Because linkify-it runs on arbitrary user text (markdown-it feeds it whole documents when linkify:true), an unauthenticated attacker can block the single-threaded event loop for many seconds with a small input. No length bound (unlike an HTTP header).

Root cause — index.mjs + lib/re.mjs

// index.mjs (mailto validator) — runs at every "mailto:" hit
'mailto:': { validate: function (text, pos, self) {
  const tail = text.slice(pos)                                  // O(n) copy per hit
  if (!self.re.mailto) self.re.mailto = new RegExp('^' + self.re.src_email_name + '@' + self.re.src_host_strict, 'i')
  if (self.re.mailto.test(tail)) { ... }                        // scans the whole O(n) tail
  return 0
}}
// lib/re.mjs:91-93 — every char of "mailto:" (incl. ':','-',';') is in this class:
re.src_email_name = '[\\-;:&=\\+\\$,\\.a-zA-Z0-9_][\\-;:&=\\+\\$,\\"\\.a-zA-Z0-9_]*'

The while ((m = re.exec(text)) !== null) { …testSchemaAt… } scan loop calls the validator at each mailto: hit; src_email_name greedily consumes the whole tail (all chars are in its class) then fails for lack of @. http:/https: do NOT blow up — their validator requires the tail to start with //, failing in O(1) per hit.

Proof of Concept (confirmed, linkify-it 5.0.1, Node v24)

const LinkifyIt = require('linkify-it');
const lf = new LinkifyIt();
lf.match('mailto:'.repeat(48000));   // ~336 KB of "mailto:mailto:…" -> seconds of blocked event loop
input (same bytes) 56 KB 112 KB 224 KB 336 KB
mailto: contiguous 97 ms 357 ms 1438 ms 3272 ms
mailto: space-separated 2 ms 3 ms 5 ms 8 ms
http:// contiguous 12 ms 17 ms 33 ms 49 ms

×~4 per 2× input ⇒ O(n²); equal-byte controls stay flat ⇒ algorithmic, not a GC/allocation artifact. Real-world via markdown-it 14.x ({linkify:true}), md.render('mailto:'.repeat(n)): 219 KB ≈ ~5 s. image

Impact

Reachable on arbitrary user text via the documented .test()/.match() API and through markdown-it's linkifier — comment systems, chat, forums, wikis, note apps that render user markdown with linkify enabled. A ~220 KB post hangs the event loop ~5 s; a few hundred KB → tens of seconds. Availability only.

Suggested remediation

Bound the email local-part per RFC 5321 (≤64) so per-hit work is O(1), and avoid the full-tail slice:

// lib/re.mjs — cap the greedy run:
re.src_email_name = '[\\-;:&=\\+\\$,\\.a-zA-Z0-9_][\\-;:&=\\+\\$,\\"\\.a-zA-Z0-9_]{0,63}'
// index.mjs — prefer a sticky regex anchored at `pos` over text.slice(pos).

Affected / disclosure

All versions through 5.0.1 (latest); same code on master. cve-mcp/OSV report no known vulnerability for linkify-it. Distinct from markdown-it's own *-run ReDoS (CVE-2026-2327, different package/path) and the recent markdown-it DoS. Reported privately; happy to test a patch against the PoC.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "linkify-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T19:06:09Z",
    "nvd_published_at": "2026-07-08T17:17:26Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`linkify-it`\u0027s schema-scan loop (`.test()` / `.match()`, the documented public API) invokes the `mailto:`\nschema validator at **every** `mailto:` occurrence in the input text. For each occurrence the validator does\n`text.slice(pos)` (an O(n) copy) and runs an email regex whose local-part class `src_email_name` greedily\nscans the **entire remaining tail** (O(n)) before failing. With N `mailto:` occurrences that is\n**N \u00d7 O(n) = O(n\u00b2)**. Because linkify-it runs on arbitrary user text (markdown-it feeds it whole documents\nwhen `linkify:true`), an unauthenticated attacker can block the single-threaded event loop for many seconds\nwith a small input. No length bound (unlike an HTTP header).\n\n### Root cause \u2014 `index.mjs` + `lib/re.mjs`\n```js\n// index.mjs (mailto validator) \u2014 runs at every \"mailto:\" hit\n\u0027mailto:\u0027: { validate: function (text, pos, self) {\n  const tail = text.slice(pos)                                  // O(n) copy per hit\n  if (!self.re.mailto) self.re.mailto = new RegExp(\u0027^\u0027 + self.re.src_email_name + \u0027@\u0027 + self.re.src_host_strict, \u0027i\u0027)\n  if (self.re.mailto.test(tail)) { ... }                        // scans the whole O(n) tail\n  return 0\n}}\n// lib/re.mjs:91-93 \u2014 every char of \"mailto:\" (incl. \u0027:\u0027,\u0027-\u0027,\u0027;\u0027) is in this class:\nre.src_email_name = \u0027[\\\\-;:\u0026=\\\\+\\\\$,\\\\.a-zA-Z0-9_][\\\\-;:\u0026=\\\\+\\\\$,\\\\\"\\\\.a-zA-Z0-9_]*\u0027\n```\nThe `while ((m = re.exec(text)) !== null) { \u2026testSchemaAt\u2026 }` scan loop calls the validator at each\n`mailto:` hit; `src_email_name` greedily consumes the whole tail (all chars are in its class) then fails for\nlack of `@`. `http:`/`https:` do NOT blow up \u2014 their validator requires the tail to start with `//`, failing\nin O(1) per hit.\n\n### Proof of Concept (confirmed, linkify-it 5.0.1, Node v24)\n```js\nconst LinkifyIt = require(\u0027linkify-it\u0027);\nconst lf = new LinkifyIt();\nlf.match(\u0027mailto:\u0027.repeat(48000));   // ~336 KB of \"mailto:mailto:\u2026\" -\u003e seconds of blocked event loop\n```\n| input (same bytes) | 56 KB | 112 KB | 224 KB | 336 KB |\n|---|---:|---:|---:|---:|\n| **`mailto:` contiguous** | 97 ms | 357 ms | 1438 ms | 3272 ms |\n| `mailto:` space-separated | 2 ms | 3 ms | 5 ms | 8 ms |\n| `http://` contiguous | 12 ms | 17 ms | 33 ms | 49 ms |\n\n\u00d7~4 per 2\u00d7 input \u21d2 O(n\u00b2); equal-byte controls stay flat \u21d2 algorithmic, not a GC/allocation artifact.\nReal-world via markdown-it 14.x (`{linkify:true}`), `md.render(\u0027mailto:\u0027.repeat(n))`: 219 KB \u2248 ~5 s.\n\u003cimg width=\"737\" height=\"161\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b5d390f3-68d0-4861-9c47-ad8aff0203d5\" /\u003e\n\n### Impact\nReachable on arbitrary user text via the documented `.test()`/`.match()` API and through markdown-it\u0027s\nlinkifier \u2014 comment systems, chat, forums, wikis, note apps that render user markdown with linkify enabled.\nA ~220 KB post hangs the event loop ~5 s; a few hundred KB \u2192 tens of seconds. Availability only.\n\n### Suggested remediation\nBound the email local-part per RFC 5321 (\u226464) so per-hit work is O(1), and avoid the full-tail slice:\n```js\n// lib/re.mjs \u2014 cap the greedy run:\nre.src_email_name = \u0027[\\\\-;:\u0026=\\\\+\\\\$,\\\\.a-zA-Z0-9_][\\\\-;:\u0026=\\\\+\\\\$,\\\\\"\\\\.a-zA-Z0-9_]{0,63}\u0027\n// index.mjs \u2014 prefer a sticky regex anchored at `pos` over text.slice(pos).\n```\n\n### Affected / disclosure\nAll versions through 5.0.1 (latest); same code on `master`. cve-mcp/OSV report no known vulnerability for\nlinkify-it. Distinct from markdown-it\u0027s own `*`-run ReDoS (CVE-2026-2327, different package/path) and the\nrecent markdown-it DoS. Reported privately; happy to test a patch against the PoC.",
  "id": "GHSA-v245-v573-v5vm",
  "modified": "2026-07-21T19:06:09Z",
  "published": "2026-07-21T19:06:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/linkify-it/security/advisories/GHSA-v245-v573-v5vm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/linkify-it/commit/105e5d77f7d119871d2b2d86ed208568eb3e7ffe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/markdown-it/linkify-it"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/linkify-it/releases/tag/5.0.2"
    }
  ],
  "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": "linkify-it: Quadratic-complexity DoS via the `mailto:` validator scan-loop on attacker text"
}

GHSA-V247-6F48-MGCJ

Vulnerability from github – Published: 2026-10-01 15:07 – Updated: 2026-10-01 15:07
VLAI
Summary
pypdf: Possible long runtimes with large amount of embedded files
Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.

Patches

This has been fixed in pypdf==6.19.0.

Workarounds

If you cannot upgrade yet, consider applying the changes from PR #4081.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:07:35Z",
    "nvd_published_at": "2026-09-30T21:17:07Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.\n\n### Patches\n\nThis has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).\n\n### Workarounds\n\nIf you cannot upgrade yet, consider applying the changes from PR [#4081](https://github.com/py-pdf/pypdf/pull/4081).",
  "id": "GHSA-v247-6f48-mgcj",
  "modified": "2026-10-01T15:07:35Z",
  "published": "2026-10-01T15:07:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-v247-6f48-mgcj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102999"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/4081"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/6b10556d13609a68f9ed18bb29fdd8bba88eb2c3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.19.0"
    }
  ],
  "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": "pypdf: Possible long runtimes with large amount of embedded files"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.