Common Weakness Enumeration

CWE-407

Allowed-with-Review

Inefficient Algorithmic Complexity

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

193 vulnerabilities reference this CWE, most recent first.

GHSA-5478-66C3-RHXR

Vulnerability from github – Published: 2026-04-08 21:50 – Updated: 2026-04-08 21:50
VLAI
Summary
Pretext: Algorithmic Complexity (DoS) in the text analysis phase
Details

isRepeatedSingleCharRun() in src/analysis.ts (line 285) re-scans the entire accumulated segment on every merge iteration during text analysis, producing O(n²) total work for input consisting of repeated identical punctuation characters. An attacker who controls text passed to prepare() can block the main thread for ~20 seconds with 80KB of input (e.g., "(".repeat(80_000)).

Tested against commit 9364741d3562fcc65aacc50953e867a5cb9fdb23 (v0.0.4) on Node.js v24.12.0, Windows x64.

A standalone PoC and detailed write-up are attached below.

Root Cause

The buildMergedSegmentation() function (line 795) processes text segments produced by Intl.Segmenter. When consecutive non-word-like segments consist of the same single character (e.g., (, [, !, #), the code merges them into one growing segment (line 859):

// analysis.ts:849-859 - the merge branch inside the build loop
} else if (
  isText &&
  !piece.isWordLike &&
  mergedLen > 0 &&
  mergedKinds[mergedLen - 1] === 'text' &&
  piece.text.length === 1 &&
  piece.text !== '-' &&
  piece.text !== '—' &&
  isRepeatedSingleCharRun(mergedTexts[mergedLen - 1]!, piece.text)  // <- O(n) per call
) {
  mergedTexts[mergedLen - 1] += piece.text  // append to accumulator

Before each merge, it calls isRepeatedSingleCharRun() (line 857) to verify that ALL characters in the accumulated segment match the new character:

// analysis.ts:285-291
function isRepeatedSingleCharRun(segment: string, ch: string): boolean {
  if (segment.length === 0) return false
  for (const part of segment) {    // <- Iterates ENTIRE accumulated string
    if (part !== ch) return false
  }
  return true
}

Intl.Segmenter with granularity: 'word' produces individual non-word segments for each punctuation character. For a string of N identical punctuation characters, the merge check is called N times. On the k-th call, the accumulated segment is k characters long, so isRepeatedSingleCharRun performs k comparisons.

Total work: 1 + 2 + 3 + ... + N = N(N+1)/2 = O(n^2)

Call chain

prepare(text, font)                                          // layout.ts:472
  -> prepareInternal(text, font, ...)                        // layout.ts:424
    -> analyzeText(text, profile, whiteSpace='normal')       // layout.ts:430 -> analysis.ts:993
      -> buildMergedSegmentation(normalized, profile, ...)   // analysis.ts:1013 -> analysis.ts:795
        -> for each Intl.Segmenter segment:
          -> isRepeatedSingleCharRun(accumulated, newChar)   // line 857 -> line 285
            -> iterates entire accumulated string            // O(k) per call, k growing

Proof of Concept

The simplest payload is a string of repeated ( characters:

import { prepare } from '@chenglou/pretext'

// 80,000 characters -> ~20 seconds of main-thread blocking
const payload = '('.repeat(80_000)
prepare(payload, '16px Arial')  // Blocks for ~20 seconds

Any single character that meets these criteria works: 1. Classified as 'text' by classifySegmentBreakChar (analysis.ts:321) - i.e., not a space, NBSP, ZWSP, soft-hyphen, tab, or newline 2. Produced as individual non-word segments by Intl.Segmenter (word granularity) 3. Not - or em-dash (explicitly excluded at lines 855-856)

Working payload characters include: (, [, {, #, @, !, %, ^, ~, <, >, etc.

Impact

  • Chat/messaging applications: User sends an 80KB message of ( characters; the receiving client's UI thread freezes for ~20 seconds while rendering.
  • Comment/form systems: User-supplied text in any text field that uses pretext for layout measurement blocks the main thread.
  • Server-side rendering: If prepare() is called server-side (Node.js/Bun), a single request can consume 20+ seconds of CPU time per 80KB of payload.

The attack requires no authentication, special characters, or encoding tricks - just repeated ASCII punctuation. 80KB is well within typical text input limits.

As an application-level mitigation, callers can cap the length of text passed to prepare() before a library-level fix is available.

Suggested Fix

Replace the O(n) full-scan verification with O(1) constant-time checks. Since the merge only ever appends the same character to an existing repeated-char run, the invariant is maintained structurally:

Option A - Check only endpoints (O(1)):

function isRepeatedSingleCharRun(segment: string, ch: string): boolean {
  return segment.length > 0 && segment[0] === ch && segment[segment.length - 1] === ch
}

This works for the current code because this branch only fires after earlier merge branches (CJK, Myanmar, Arabic) have been skipped, and those branches produce segments that would not start and end with the same ASCII punctuation character. However, the safety relies on an emergent property of the branch ordering and the other merge branches. Future refactors that add new merge branches or reorder the existing ones could silently break the invariant.

Option B - Track with metadata Add a boolean lastMergeWasSingleCharRun alongside the accumulator arrays. Set it to true when a single-char merge succeeds, false when any other merge branch is taken. Check the flag instead of re-scanning the string.

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= 0.0.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@chenglou/pretext"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T21:50:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`isRepeatedSingleCharRun()` in `src/analysis.ts` (line 285) re-scans the entire accumulated segment on every merge iteration during text analysis, producing O(n\u00b2) total work for input consisting of repeated identical punctuation characters. An attacker who controls text passed to `prepare()` can block the main thread for ~20 seconds with 80KB of input (e.g., `\"(\".repeat(80_000)`).\n\nTested against commit 9364741d3562fcc65aacc50953e867a5cb9fdb23 (v0.0.4) on Node.js v24.12.0, Windows x64.\n\nA standalone PoC and detailed write-up are attached below.\n\n---\n\n## Root Cause\n\nThe `buildMergedSegmentation()` function (line 795) processes text segments produced by `Intl.Segmenter`. When consecutive non-word-like segments consist of the same single character (e.g., `(`, `[`, `!`, `#`), the code merges them into one growing segment (line 859):\n\n```typescript\n// analysis.ts:849-859 - the merge branch inside the build loop\n} else if (\n  isText \u0026\u0026\n  !piece.isWordLike \u0026\u0026\n  mergedLen \u003e 0 \u0026\u0026\n  mergedKinds[mergedLen - 1] === \u0027text\u0027 \u0026\u0026\n  piece.text.length === 1 \u0026\u0026\n  piece.text !== \u0027-\u0027 \u0026\u0026\n  piece.text !== \u0027\u2014\u0027 \u0026\u0026\n  isRepeatedSingleCharRun(mergedTexts[mergedLen - 1]!, piece.text)  // \u003c- O(n) per call\n) {\n  mergedTexts[mergedLen - 1] += piece.text  // append to accumulator\n```\n\nBefore each merge, it calls `isRepeatedSingleCharRun()` (line 857) to verify that ALL characters in the accumulated segment match the new character:\n\n```typescript\n// analysis.ts:285-291\nfunction isRepeatedSingleCharRun(segment: string, ch: string): boolean {\n  if (segment.length === 0) return false\n  for (const part of segment) {    // \u003c- Iterates ENTIRE accumulated string\n    if (part !== ch) return false\n  }\n  return true\n}\n```\n\n`Intl.Segmenter` with `granularity: \u0027word\u0027` produces individual non-word segments for each punctuation character. For a string of N identical punctuation characters, the merge check is called N times. On the k-th call, the accumulated segment is k characters long, so `isRepeatedSingleCharRun` performs k comparisons.\n\nTotal work: `1 + 2 + 3 + ... + N = N(N+1)/2 = O(n^2)`\n\n### Call chain\n\n```\nprepare(text, font)                                          // layout.ts:472\n  -\u003e prepareInternal(text, font, ...)                        // layout.ts:424\n    -\u003e analyzeText(text, profile, whiteSpace=\u0027normal\u0027)       // layout.ts:430 -\u003e analysis.ts:993\n      -\u003e buildMergedSegmentation(normalized, profile, ...)   // analysis.ts:1013 -\u003e analysis.ts:795\n        -\u003e for each Intl.Segmenter segment:\n          -\u003e isRepeatedSingleCharRun(accumulated, newChar)   // line 857 -\u003e line 285\n            -\u003e iterates entire accumulated string            // O(k) per call, k growing\n```\n\n## Proof of Concept\n\nThe simplest payload is a string of repeated `(` characters:\n\n```typescript\nimport { prepare } from \u0027@chenglou/pretext\u0027\n\n// 80,000 characters -\u003e ~20 seconds of main-thread blocking\nconst payload = \u0027(\u0027.repeat(80_000)\nprepare(payload, \u002716px Arial\u0027)  // Blocks for ~20 seconds\n```\n\nAny single character that meets these criteria works:\n1. Classified as `\u0027text\u0027` by `classifySegmentBreakChar` (analysis.ts:321) - i.e., not a space, NBSP, ZWSP, soft-hyphen, tab, or newline\n2. Produced as individual non-word segments by `Intl.Segmenter` (word granularity)\n3. Not `-` or em-dash (explicitly excluded at lines 855-856)\n\nWorking payload characters include: `(`, `[`, `{`, `#`, `@`, `!`, `%`, `^`, `~`, `\u003c`, `\u003e`, etc.\n\n---\n\n## Impact\n\n- **Chat/messaging applications:** User sends an 80KB message of `(` characters;\n  the receiving client\u0027s UI thread freezes for ~20 seconds while rendering.\n- **Comment/form systems:** User-supplied text in any text field that uses\n  `pretext` for layout measurement blocks the main thread.\n- **Server-side rendering:** If `prepare()` is called server-side (Node.js/Bun),\n  a single request can consume 20+ seconds of CPU time per 80KB of payload.\n\nThe attack requires no authentication, special characters, or encoding tricks -\njust repeated ASCII punctuation. 80KB is well within typical text input limits.\n\nAs an application-level mitigation, callers can cap the length of text passed to\n`prepare()` before a library-level fix is available.\n\n## Suggested Fix\n\nReplace the O(n) full-scan verification with O(1) constant-time checks. \nSince the merge only ever appends the same character to an existing repeated-char run, the invariant is maintained structurally:\n\n**Option A - Check only endpoints (O(1)):**\n```typescript\nfunction isRepeatedSingleCharRun(segment: string, ch: string): boolean {\n  return segment.length \u003e 0 \u0026\u0026 segment[0] === ch \u0026\u0026 segment[segment.length - 1] === ch\n}\n```\nThis works for the current code because this branch only fires after earlier merge branches (CJK, Myanmar, Arabic) have been skipped, and those branches produce segments that would not start and end with the same ASCII punctuation character. However, the safety relies on an emergent property of the branch ordering and the other merge branches. Future refactors that add new merge branches or reorder the existing ones could silently break the invariant.\n\n**Option B - Track with metadata**\nAdd a boolean `lastMergeWasSingleCharRun` alongside the accumulator arrays. Set it to `true` when a single-char merge succeeds, `false` when any other merge branch is taken. Check the flag instead of re-scanning the string.",
  "id": "GHSA-5478-66c3-rhxr",
  "modified": "2026-04-08T21:50:51Z",
  "published": "2026-04-08T21:50:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/chenglou/pretext/security/advisories/GHSA-5478-66c3-rhxr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chenglou/pretext"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chenglou/pretext/releases/tag/v0.0.5"
    }
  ],
  "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": "Pretext: Algorithmic Complexity (DoS) in the text analysis phase"
}

GHSA-575V-PHRX-CJCP

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

The racoon daemon in IPsec-Tools 0.8.2 contains a remotely exploitable computational-complexity attack when parsing and storing ISAKMP fragments. The implementation permits a remote attacker to exhaust computational resources on the remote endpoint by repeatedly sending ISAKMP fragment packets in a particular order such that the worst-case computational complexity is realized in the algorithm utilized to determine if reassembly of the fragments can take place.

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-2016-10396"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-06T01:29:00Z",
    "severity": "HIGH"
  },
  "details": "The racoon daemon in IPsec-Tools 0.8.2 contains a remotely exploitable computational-complexity attack when parsing and storing ISAKMP fragments. The implementation permits a remote attacker to exhaust computational resources on the remote endpoint by repeatedly sending ISAKMP fragment packets in a particular order such that the worst-case computational complexity is realized in the algorithm utilized to determine if reassembly of the fragments can take place.",
  "id": "GHSA-575v-phrx-cjcp",
  "modified": "2022-05-17T02:24:48Z",
  "published": "2022-05-17T02:24:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10396"
    },
    {
      "type": "WEB",
      "url": "https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51682"
    },
    {
      "type": "WEB",
      "url": "http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ipsec-tools/src/racoon/isakmp_frag.c.diff?r1=1.5\u0026r2=1.5.36.1"
    },
    {
      "type": "WEB",
      "url": "http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ipsec-tools/src/racoon/isakmp_frag.c?only_with_tag=MAIN"
    }
  ],
  "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-5HGR-HG42-57JG

Vulnerability from github – Published: 2026-06-16 13:46 – Updated: 2026-06-16 13:46
VLAI
Summary
pypdf: Inefficient decoding of FlateDecode PNG predictor streams
Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the /FlateDecode filter with a PNG predictor.

Patches

This has been fixed in pypdf==6.12.2.

Workarounds

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

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49460"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T13:46:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the `/FlateDecode` filter with a PNG predictor.\n\n### Patches\nThis has been fixed in [pypdf==6.12.2](https://github.com/py-pdf/pypdf/releases/tag/6.12.2).\n\n### Workarounds\nIf you cannot upgrade yet, consider applying the changes from PR [#3806](https://github.com/py-pdf/pypdf/pull/3806).",
  "id": "GHSA-5hgr-hg42-57jg",
  "modified": "2026-06-16T13:46:42Z",
  "published": "2026-06-16T13:46:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-5hgr-hg42-57jg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/3806"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.12.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypdf: Inefficient decoding of FlateDecode PNG predictor streams"
}

GHSA-5MF9-H53Q-7MHQ

Vulnerability from github – Published: 2026-04-07 15:30 – Updated: 2026-06-05 17:51
VLAI
Summary
Django has potential DoS via MultiPartParser through crafted multipart uploads
Details

An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. MultiPartParser allows remote attackers to degrade performance by submitting multipart uploads with Content-Transfer-Encoding: base64 including excessive whitespace.

Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Seokchan Yoon for reporting this issue.

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": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0"
            },
            {
              "fixed": "6.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.2"
            },
            {
              "fixed": "5.2.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2"
            },
            {
              "fixed": "4.2.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:29:16Z",
    "nvd_published_at": "2026-04-07T15:17:39Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. `MultiPartParser` allows remote attackers to degrade performance by submitting multipart uploads with `Content-Transfer-Encoding: base64` including excessive whitespace.\n\nEarlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\nDjango would like to thank Seokchan Yoon for reporting this issue.",
  "id": "GHSA-5mf9-h53q-7mhq",
  "modified": "2026-06-05T17:51:58Z",
  "published": "2026-04-07T15:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33033"
    },
    {
      "type": "WEB",
      "url": "https://docs.djangoproject.com/en/dev/releases/security"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django/django"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2026-48.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/django-announce"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2026/apr/07/security-releases"
    }
  ],
  "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": "Django has potential DoS via MultiPartParser through crafted multipart uploads"
}

GHSA-5RVQ-CXJ2-64VF

Vulnerability from github – Published: 2026-06-15 20:24 – Updated: 2026-06-15 20:24
VLAI
Summary
python-multipart: Quadratic-time querystring parsing with semicolon separators causes CPU denial of service
Details

Summary

When parsing application/x-www-form-urlencoded bodies, QuerystringParser located the field separator with a two step lookup: it first scanned the entire remaining buffer for &, and only when no & existed anywhere ahead did it fall back to scanning for ;. For a body that uses ; as the separator and contains no &, every field iteration performed a full failed & scan over the entire remaining buffer before locating the nearby ;. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.

An attacker can submit a small crafted body of the form a;a;a;... and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.

Details

In python_multipart/multipart.py, both the FIELD_NAME and FIELD_DATA states located the next separator like this:

sep_pos = data.find(b"&", i)
if sep_pos == -1:
    sep_pos = data.find(b";", i)

data.find(b"&", i) scans from i to the end of the buffer and returns -1 only when there is no & anywhere in the remainder. For a ; separated body with no &, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.

For example, a 1 MiB url encoded body consisting of a; repeated ~500,000 times, submitted with Content-Type: application/x-www-form-urlencoded, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of CPU for a single request. Cost scales quadratically with chunk size.

The parser is reachable through the public QuerystringParser class and through the high level FormParser, create_form_parser, and parse_form APIs for url encoded bodies. It is also the parser Starlette and FastAPI use for application/x-www-form-urlencoded request bodies via request.form().

Impact

Uncontrolled CPU consumption (denial of service). Parsing is synchronous, so a single small crafted form body occupies the handling worker for seconds, blocking any other work on that worker until parsing finishes. Sustained concurrent requests keep workers continuously busy, degrading or denying service.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which treats only & as a field separator (per the WHATWG URL standard) using a single bounded scan, making parsing linear in the body length.

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": "PyPI",
        "name": "python-multipart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:24:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen parsing `application/x-www-form-urlencoded` bodies, `QuerystringParser` located the field separator with a two step lookup: it first scanned the entire remaining buffer for `\u0026`, and only when no `\u0026` existed anywhere ahead did it fall back to scanning for `;`. For a body that uses `;` as the separator and contains no `\u0026`, every field iteration performed a full failed `\u0026` scan over the entire remaining buffer before locating the nearby `;`. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk.\n\nAn attacker can submit a small crafted body of the form `a;a;a;...` and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes.\n\n### Details\n\nIn `python_multipart/multipart.py`, both the `FIELD_NAME` and `FIELD_DATA` states located the next separator like this:\n\n```python\nsep_pos = data.find(b\"\u0026\", i)\nif sep_pos == -1:\n    sep_pos = data.find(b\";\", i)\n```\n\n`data.find(b\"\u0026\", i)` scans from `i` to the end of the buffer and returns `-1` only when there is no `\u0026` anywhere in the remainder. For a `;` separated body with no `\u0026`, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.\n\nFor example, a 1 MiB url encoded body consisting of `a;` repeated ~500,000 times, submitted with `Content-Type: application/x-www-form-urlencoded`, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of CPU for a single request. Cost scales quadratically with chunk size.\n\nThe parser is reachable through the public `QuerystringParser` class and through the high level `FormParser`, `create_form_parser`, and `parse_form` APIs for url encoded bodies. It is also the parser Starlette and FastAPI use for `application/x-www-form-urlencoded` request bodies via `request.form()`.\n\n### Impact\n\nUncontrolled CPU consumption (denial of service). Parsing is synchronous, so a single small crafted form body occupies the handling worker for seconds, blocking any other work on that worker until parsing finishes. Sustained concurrent requests keep workers continuously busy, degrading or denying service.\n\n### Mitigation\n\nUpgrade to `python-multipart` `0.0.30` or later, which treats only `\u0026` as a field separator (per the [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing)) using a single bounded scan, making parsing linear in the body length.",
  "id": "GHSA-5rvq-cxj2-64vf",
  "modified": "2026-06-15T20:24:09Z",
  "published": "2026-06-15T20:24:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/python-multipart/security/advisories/GHSA-5rvq-cxj2-64vf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Kludex/python-multipart"
    }
  ],
  "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": "python-multipart: Quadratic-time querystring parsing with semicolon separators causes CPU denial of service"
}

GHSA-6522-R5FQ-99GW

Vulnerability from github – Published: 2026-05-20 12:30 – Updated: 2026-06-30 03:36
VLAI
Details

NLnet Labs Unbound up to and including version 1.25.0 has a vulnerability when handling replies with very large RRsets that Unbound needs to perform name compression for. Malicious upstream responses with very large RRsets with records that don't share a suffix above the root can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. An adversary can exploit the vulnerability by querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. A compression limit was introduced in 1.21.1 for this but it didn't account for the case where records would not share any suffix above the root. That causes Unbound to go in a different code path because of the compression tree lookup failure and eventually not increment the compression counter for those operations. Unbound 1.25.1 contains a patch with a fix that increments the compression counter regardless of the compression tree lookup. This is a complement fix to CVE-2024-8508.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-44390"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1050",
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-20T10:16:28Z",
    "severity": "MODERATE"
  },
  "details": "NLnet Labs Unbound up to and including version 1.25.0 has a vulnerability when handling replies with very large RRsets that Unbound needs to perform name compression for. Malicious upstream responses with very large RRsets with records that don\u0027t share a suffix above the root can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. An adversary can exploit the vulnerability by querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. A compression limit was introduced in 1.21.1 for this but it didn\u0027t account for the case where records would not share any suffix above the root. That causes Unbound to go in a different code path because of the compression tree lookup failure and eventually not increment the compression counter for those operations. Unbound 1.25.1 contains a patch with a fix that increments the compression counter regardless of the compression tree lookup. This is a complement fix to CVE-2024-8508.",
  "id": "GHSA-6522-r5fq-99gw",
  "modified": "2026-06-30T03:36:45Z",
  "published": "2026-05-20T12:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44390"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-44390"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480130"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44390.json"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-44390.txt"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/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:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-68JQ-C3RV-PCRR

Vulnerability from github – Published: 2026-04-14 01:05 – Updated: 2026-06-08 23:09
VLAI
Summary
graphql-php is affected by a Denial of Service via quadratic complexity in OverlappingFieldsCanBeMerged validation
Details

The OverlappingFieldsCanBeMerged validation rule exhibits quadratic time complexity when processing queries with many repeated fields sharing the same response name. An attacker can send a crafted query like { hello hello hello ... } with thousands of repeated fields, causing excessive CPU usage during validation before execution begins.

This is not mitigated by existing QueryDepth or QueryComplexity rules.

Observed impact (tested on v15.31.4): - 1000 fields: ~0.6s - 2000 fields: ~2.4s - 3000 fields: ~5.3s - 5000 fields: request timeout (>20s)

Root cause: collectConflictsWithin() performs O(n²) pairwise comparisons of all fields with the same response name. For identical repeated fields, every comparison returns "no conflict" but the quadratic iteration count causes resource exhaustion.

Fix: Deduplicate structurally identical fields before pairwise comparison, reducing the complexity from O(n²) to O(u²) where u is the number of unique field signatures (typically 1 for this attack pattern).

Credit: Ashwak N (ashwakn04@gmail.com)

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/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= 15.31.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "webonyx/graphql-php"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "15.31.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T01:05:05Z",
    "nvd_published_at": "2026-04-17T22:16:33Z",
    "severity": "MODERATE"
  },
  "details": "The `OverlappingFieldsCanBeMerged` validation rule exhibits quadratic time complexity when processing queries with many repeated fields sharing the same response name. An attacker can send a crafted query like `{ hello hello hello ... }` with thousands of repeated fields, causing excessive CPU usage during validation before execution begins.\n\nThis is not mitigated by existing QueryDepth or QueryComplexity rules.\n\n**Observed impact (tested on v15.31.4):**\n- 1000 fields: ~0.6s\n- 2000 fields: ~2.4s\n- 3000 fields: ~5.3s\n- 5000 fields: request timeout (\u003e20s)\n\n**Root cause:** `collectConflictsWithin()` performs O(n\u00b2) pairwise comparisons of all fields with the same response name. For identical repeated fields, every comparison returns \"no conflict\" but the quadratic iteration count causes resource exhaustion.\n\n**Fix:** Deduplicate structurally identical fields before pairwise comparison, reducing the complexity from O(n\u00b2) to O(u\u00b2) where u is the number of unique field signatures (typically 1 for this attack pattern).\n\n**Credit:** Ashwak N (ashwakn04@gmail.com)",
  "id": "GHSA-68jq-c3rv-pcrr",
  "modified": "2026-06-08T23:09:48Z",
  "published": "2026-04-14T01:05:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/webonyx/graphql-php/security/advisories/GHSA-68jq-c3rv-pcrr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40476"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/webonyx/graphql-php"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webonyx/graphql-php/releases/tag/v15.31.5"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "graphql-php is affected by a Denial of Service via quadratic complexity in OverlappingFieldsCanBeMerged validation"
}

GHSA-6PX8-752J-C2VV

Vulnerability from github – Published: 2024-07-23 18:31 – Updated: 2024-11-26 18:38
VLAI
Details

In lj_str_hash.c in OpenResty 1.19.3.1 through 1.25.3.1, the string hashing function (used during string interning) allows HashDoS (Hash Denial of Service) attacks. An attacker could cause excessive resource usage during proxy operations via crafted requests, potentially leading to a denial of service with relatively few incoming requests. This vulnerability only exists in the OpenResty fork in the openresty/luajit2 GitHub repository. The LuaJIT/LuaJIT epository. is unaffected/

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": [],
  "aliases": [
    "CVE-2024-39702"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-23T16:15:05Z",
    "severity": "MODERATE"
  },
  "details": "In lj_str_hash.c in OpenResty 1.19.3.1 through 1.25.3.1, the string hashing function (used during string interning) allows HashDoS (Hash Denial of Service) attacks. An attacker could cause excessive resource usage during proxy operations via crafted requests, potentially leading to a denial of service with relatively few incoming requests. This vulnerability only exists in the OpenResty fork in the openresty/luajit2 GitHub repository. The LuaJIT/LuaJIT epository. is unaffected/",
  "id": "GHSA-6px8-752j-c2vv",
  "modified": "2024-11-26T18:38:46Z",
  "published": "2024-07-23T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39702"
    },
    {
      "type": "WEB",
      "url": "https://openresty.org/en/ann-1025003002.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-6R92-CGXC-R5FG

Vulnerability from github – Published: 2022-01-21 23:35 – Updated: 2024-01-03 22:29
VLAI
Summary
Denial of service in CBOR library
Details

Impact

Due to this library's use of an inefficient algorithm, it is vulnerable to a denial of service attack when a maliciously crafted input is passed to DecodeFromBytes or other CBOR decoding mechanisms in this library.

Affected versions include versions 4.0.0 through 4.5.0.

This vulnerability was privately reported to me.

Patches

This issue has been fixed in version 4.5.1. Users should use the latest version of this library. (The latest version is not necessarily 4.5.1. Check the NuGet page to see the latest version's version number.)

Workarounds

Again, users should use the latest version of this library.

In the meantime, note that the inputs affected by this issue are all CBOR maps or contain CBOR maps. An input that decodes to a single CBOR object is not capable of containing a CBOR map if—

  • it begins with a byte other than 0x80 through 0xDF, or
  • it does not contain a byte in the range 0xa0 through 0xBF.

Such an input is not affected by this vulnerability and an application can choose to perform this check before passing it to a CBOR decoding mechanism.

For more information

If you have any questions or comments about this advisory: * Open an issue in the CBOR repository.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "PeterO.Cbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-18T22:57:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nDue to this library\u0027s use of an inefficient algorithm, it is vulnerable to a denial of service attack when a maliciously crafted input is passed to `DecodeFromBytes` or other CBOR decoding mechanisms in this library.\n\nAffected versions _include_ versions 4.0.0 through 4.5.0.\n\nThis vulnerability was privately reported to me.\n\n### Patches\nThis issue has been fixed in version 4.5.1.  Users should use the latest version of this library. (The latest version is not necessarily 4.5.1.  Check the [NuGet page](https://www.nuget.org/packages/PeterO.Cbor) to see the latest version\u0027s version number.)\n\n### Workarounds\n\nAgain, users should use the latest version of this library.\n\nIn the meantime, note that the inputs affected by this issue are all CBOR maps or contain CBOR maps.  An input that decodes to a single CBOR object is not capable of containing a CBOR map if\u0026mdash;\n\n- it begins with a byte other than 0x80 through 0xDF, or\n- it does not contain a byte in the range 0xa0 through 0xBF.\n\nSuch an input is not affected by this vulnerability and an application can choose to perform this check before passing it to a CBOR decoding mechanism.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the CBOR repository](https://github.com/peteroupc/CBOR).\n",
  "id": "GHSA-6r92-cgxc-r5fg",
  "modified": "2024-01-03T22:29:30Z",
  "published": "2022-01-21T23:35:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/peteroupc/CBOR/security/advisories/GHSA-6r92-cgxc-r5fg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peteroupc/CBOR/commit/b4117dbbb4cd5a4a963f9d0c9aa132f033e15b95"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/peteroupc/CBOR"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peteroupc/CBOR/compare/v4.5...v4.5.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Denial of service in CBOR library"
}

GHSA-6V5V-WF23-FMFQ

Vulnerability from github – Published: 2026-06-15 20:41 – Updated: 2026-06-15 20:41
VLAI
Summary
markdown-it: Quadratic complexity DoS in smartquotes rule via replaceAt string operations
Details

Summary

A quadratic time complexity vulnerability exists in markdown-it's smartquotes rule (enabled via the typographer: true option). An attacker can craft a markdown input consisting of consecutive quotation marks that causes the parser to consume excessive CPU time, leading to denial of service.

Details

The vulnerability is in the replaceAt() helper function used by the smartquotes rule in lib/rules_core/smartquotes.mjs:

function replaceAt (str, index, ch) {
  return str.slice(0, index) + ch + str.slice(index + 1)
}

When markdown-it processes a text token containing many quotation marks (either " or ') with typographer: true, the smartquotes rule iterates through each quote character and calls replaceAt() to substitute it with a typographic (curly) quote. Each call to replaceAt() creates three new string slices and concatenates them, which is an O(n) operation where n is the length of the string.

Since this is called once per quote character in the token, and there are n quote characters, the total time complexity becomes O(n^2).

The root cause is that the smartquotes rule modifies token.content in place using string slicing rather than building the result incrementally. The process_inlines() function (line 14) processes each quote in the text token, and for matching quote pairs, calls replaceAt() on both the opening and closing token's content (lines 151-152). When the entire input is a single text token of quote characters, this results in quadratic behavior.

PoC

const md = require('markdown-it');
const instance = md({ typographer: true });

// 160,000 consecutive double-quote characters
const payload = '"'.repeat(160000);

console.time('render');
instance.render(payload);
console.timeEnd('render');
// Output: render: ~21000ms (21 seconds)

// Compare with typographer disabled:
const safe = md({ typographer: false });
console.time('render-safe');
safe.render(payload);
console.timeEnd('render-safe');
// Output: render-safe: ~8ms

Measured timing on a modern system: - 10,000 quotes: ~19ms - 20,000 quotes: ~51ms - 40,000 quotes: ~212ms - 80,000 quotes: ~5,430ms - 160,000 quotes: ~21,198ms

The scaling is clearly superlinear (quadratic), with the 80K->160K step showing a ~3.9x increase for a 2x input increase, consistent with O(n^2).

Impact

Applications that render user-supplied markdown with typographer: true are vulnerable to denial of service. An attacker can submit a relatively small payload (160KB of quote characters) that causes the server to spend over 21 seconds processing a single request. Repeated submissions can exhaust server CPU resources and prevent legitimate users from being served.

The impact is mitigated by the fact that the typographer option defaults to false and must be explicitly enabled. However, the typographer feature is commonly enabled in production applications that want smart typography, and the markdown-it documentation prominently suggests enabling it.

A suggested fix would be to replace the replaceAt() approach with an array-based or StringBuilder-style approach that collects all replacements and applies them in a single pass, reducing the time complexity to O(n).

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= 14.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "markdown-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:41:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA quadratic time complexity vulnerability exists in markdown-it\u0027s smartquotes rule (enabled via the `typographer: true` option). An attacker can craft a markdown input consisting of consecutive quotation marks that causes the parser to consume excessive CPU time, leading to denial of service.\n\n### Details\n\nThe vulnerability is in the `replaceAt()` helper function used by the smartquotes rule in `lib/rules_core/smartquotes.mjs`:\n\n```javascript\nfunction replaceAt (str, index, ch) {\n  return str.slice(0, index) + ch + str.slice(index + 1)\n}\n```\n\nWhen markdown-it processes a text token containing many quotation marks (either `\"` or `\u0027`) with `typographer: true`, the smartquotes rule iterates through each quote character and calls `replaceAt()` to substitute it with a typographic (curly) quote. Each call to `replaceAt()` creates three new string slices and concatenates them, which is an O(n) operation where n is the length of the string.\n\nSince this is called once per quote character in the token, and there are n quote characters, the total time complexity becomes O(n^2).\n\nThe root cause is that the smartquotes rule modifies `token.content` in place using string slicing rather than building the result incrementally. The `process_inlines()` function (line 14) processes each quote in the text token, and for matching quote pairs, calls `replaceAt()` on both the opening and closing token\u0027s content (lines 151-152). When the entire input is a single text token of quote characters, this results in quadratic behavior.\n\n### PoC\n\n```javascript\nconst md = require(\u0027markdown-it\u0027);\nconst instance = md({ typographer: true });\n\n// 160,000 consecutive double-quote characters\nconst payload = \u0027\"\u0027.repeat(160000);\n\nconsole.time(\u0027render\u0027);\ninstance.render(payload);\nconsole.timeEnd(\u0027render\u0027);\n// Output: render: ~21000ms (21 seconds)\n\n// Compare with typographer disabled:\nconst safe = md({ typographer: false });\nconsole.time(\u0027render-safe\u0027);\nsafe.render(payload);\nconsole.timeEnd(\u0027render-safe\u0027);\n// Output: render-safe: ~8ms\n```\n\nMeasured timing on a modern system:\n- 10,000 quotes: ~19ms\n- 20,000 quotes: ~51ms\n- 40,000 quotes: ~212ms\n- 80,000 quotes: ~5,430ms\n- 160,000 quotes: ~21,198ms\n\nThe scaling is clearly superlinear (quadratic), with the 80K-\u003e160K step showing a ~3.9x increase for a 2x input increase, consistent with O(n^2).\n\n### Impact\n\nApplications that render user-supplied markdown with `typographer: true` are vulnerable to denial of service. An attacker can submit a relatively small payload (160KB of quote characters) that causes the server to spend over 21 seconds processing a single request. Repeated submissions can exhaust server CPU resources and prevent legitimate users from being served.\n\nThe impact is mitigated by the fact that the `typographer` option defaults to `false` and must be explicitly enabled. However, the typographer feature is commonly enabled in production applications that want smart typography, and the markdown-it documentation prominently suggests enabling it.\n\nA suggested fix would be to replace the `replaceAt()` approach with an array-based or StringBuilder-style approach that collects all replacements and applies them in a single pass, reducing the time complexity to O(n).",
  "id": "GHSA-6v5v-wf23-fmfq",
  "modified": "2026-06-15T20:41:06Z",
  "published": "2026-06-15T20:41:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/security/advisories/GHSA-6v5v-wf23-fmfq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/markdown-it/markdown-it"
    }
  ],
  "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": "markdown-it: Quadratic complexity DoS in smartquotes rule via replaceAt string operations"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list