GHSA-5478-66C3-RHXR

Vulnerability from github – Published: 2026-04-08 21:50 – Updated: 2026-04-08 21:50

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

JSON

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-54FX-42GC-7VW4

Vulnerability from github – Published: 2026-08-07 18:36 – Updated: 2026-08-07 18:36

Summary

Hono: Algorithmic Complexity DoS in Language Middleware

Details

Summary

The languageDetector middleware is vulnerable to algorithmic complexity denial of service when processing a crafted language tag containing a large number of hyphen-separated subtags.

Details

To implement progressive language-tag truncation, normalizeLanguage() repeatedly calls parts.slice(0, i).join('-') for every possible prefix. The total amount of string processing grows quadratically with the number of subtags.

Language values may come from a query parameter, cookie, Accept-Language header, or URL path, depending on the detector configuration. The default detector order enables query-string, cookie, and header detection, so applications using languageDetector() may expose this processing to unauthenticated requests.

Request-size limits reduce the maximum cost of a single request but do not eliminate the issue. Inputs accepted by common JavaScript runtimes can still cause noticeable synchronous event-loop blocking.

Impact

An attacker may repeatedly send requests containing long, hyphen-separated language tags, causing excessive CPU consumption and preventing unrelated requests from being processed.

The practical impact depends on the runtime's request-size limits, reverse-proxy configuration, and the detectors enabled by the application.

Resolution

The progressive lookup should avoid reconstructing every shorter prefix. The implementation can instead inspect the configured supported languages and select the longest value that matches the input at a hyphen boundary.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hono"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.12.0"
            },
            {
              "fixed": "4.12.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71848"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-07T18:36:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `languageDetector` middleware is vulnerable to algorithmic complexity denial of service when processing a crafted language tag containing a large number of hyphen-separated subtags.\n\n### Details\n\nTo implement progressive language-tag truncation, `normalizeLanguage()` repeatedly calls `parts.slice(0, i).join(\u0027-\u0027)` for every possible prefix. The total amount of string processing grows quadratically with the number of subtags.\n\nLanguage values may come from a query parameter, cookie, `Accept-Language` header, or URL path, depending on the detector configuration. The default detector order enables query-string, cookie, and header detection, so applications using `languageDetector()` may expose this processing to unauthenticated requests.\n\nRequest-size limits reduce the maximum cost of a single request but do not eliminate the issue. Inputs accepted by common JavaScript runtimes can still cause noticeable synchronous event-loop blocking.\n\n### Impact\n\nAn attacker may repeatedly send requests containing long, hyphen-separated language tags, causing excessive CPU consumption and preventing unrelated requests from being processed.\n\nThe practical impact depends on the runtime\u0027s request-size limits, reverse-proxy configuration, and the detectors enabled by the application.\n\n### Resolution\n\nThe progressive lookup should avoid reconstructing every shorter prefix. The implementation can instead inspect the configured supported languages and select the longest value that matches the input at a hyphen boundary.",
  "id": "GHSA-54fx-42gc-7vw4",
  "modified": "2026-08-07T18:36:31Z",
  "published": "2026-08-07T18:36:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/security/advisories/GHSA-54fx-42gc-7vw4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/commit/f70e2c31684387b3231cc38512a31df6ca76a1c7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/honojs/hono"
    },
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/releases/tag/v4.12.34"
    }
  ],
  "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": "Hono: Algorithmic Complexity DoS in Language Middleware"
}

GHSA-575V-PHRX-CJCP

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

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

JSON

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-5F3W-W96Q-CW2F

Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-07-22 21:32

Details

Certain query operations involving deeply nested $jsonSchema constructs can trigger disproportionate CPU consumption in affected MongoDB deployments, potentially leading to resource exhaustion. The resulting CPU-bound operation cannot be interrupted through standard administrative controls.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-13064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T20:16:44Z",
    "severity": "HIGH"
  },
  "details": "Certain query operations involving deeply nested $jsonSchema constructs can trigger disproportionate CPU consumption in affected MongoDB deployments, potentially leading to resource exhaustion. The resulting CPU-bound operation cannot be interrupted through standard administrative controls.",
  "id": "GHSA-5f3w-w96q-cw2f",
  "modified": "2026-07-22T21:32:06Z",
  "published": "2026-07-22T21:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13064"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-125872"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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-5FXW-8768-V85X

Vulnerability from github – Published: 2026-09-17 15:32 – Updated: 2026-09-17 15:32

Details

roxmltree through 0.21.1 performs quadratic-time attribute and namespace validation during XML parsing without limits on attribute count. Attackers can craft XML documents with tens of thousands of attributes on a single element to consume excessive CPU time and cause denial of service.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-92987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T15:17:02Z",
    "severity": "HIGH"
  },
  "details": "roxmltree through 0.21.1 performs quadratic-time attribute and namespace validation during XML parsing without limits on attribute count. Attackers can craft XML documents with tens of thousands of attributes on a single element to consume excessive CPU time and cause denial of service.",
  "id": "GHSA-5fxw-8768-v85x",
  "modified": "2026-09-17T15:32:19Z",
  "published": "2026-09-17T15:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92987"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RazrFalcon/roxmltree/issues/153"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RazrFalcon/roxmltree"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RazrFalcon/roxmltree/blob/v0.21.1/src/lib.rs#L751-L755"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RazrFalcon/roxmltree/blob/v0.21.1/src/parse.rs#L1014-L1020"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/roxmltree-through-0.21.1-denial-of-service-via-quadratic-parsing"
    }
  ],
  "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: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-5HGR-HG42-57JG

Vulnerability from github – Published: 2026-06-16 13:46 – Updated: 2026-06-16 13:46

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

JSON

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

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

JSON

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-5MJQ-6XVH-RMV2

Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36

Details

A flaw in Elasticsearch allows a low-privileged authenticated user who can index documents to submit a single small document containing a crafted user-supplied input. Processing one such document occupies a worker thread from a bounded pool for a disproportionate amount of time, degrading the availability of indexing operations on the affected node.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-72685"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:29Z",
    "severity": "MODERATE"
  },
  "details": "A flaw in Elasticsearch allows a low-privileged authenticated user who can index documents to submit a single small document containing a crafted user-supplied input. Processing one such document occupies a worker thread from a bounded pool for a disproportionate amount of time, degrading the availability of indexing operations on the affected node.",
  "id": "GHSA-5mjq-6xvh-rmv2",
  "modified": "2026-08-13T21:36:11Z",
  "published": "2026-08-13T21:36:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72685"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-20-9-4-5-security-update-esa-2026-77/389500"
    }
  ],
  "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-5P4M-2WFM-XMQJ

Vulnerability from github – Published: 2026-08-06 20:27 – Updated: 2026-08-06 20:27

Summary

JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported

Details

Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x)

Summary

resolveYamlOmap() enforces key uniqueness for !!omap sequences with a linear scan (objectKeys.indexOf(...)) inside the per-element loop, making resolution O(n²) in the number of entries. A modestly sized YAML document therefore consumes disproportionate CPU inside yaml.load(), giving a denial of service against any consumer that parses untrusted YAML.

!!omap is registered in the default schema (lib/schema/default.js → require('../type/omap')), so a plain yaml.load(untrustedInput) with no options is affected — no custom schema or non-default configuration is required.

This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm, which was fixed in the 5.x line in 5.2.1. That fix was never backported: both currently maintained legacy lines still carry the original implementation.

Affected versions

Line	Latest tested	Status
3.x	3.15.0	Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29`
4.x	4.3.0	Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30`
5.x	5.2.2	Not affected — fixed in 5.2.1 (uses a `Set`)

Both figures are the newest release of each line at the time of writing, so this is not a "you are on an old version" issue.

Details

lib/type/omap.js (js-yaml 4.3.0):

if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)
else return false

objectKeys grows by one element per entry, and Array.prototype.indexOf is a linear scan, so resolving an n-entry !!omap performs roughly 1 + 2 + … + n comparisons — quadratic in n. The work happens synchronously inside yaml.load(), blocking the event loop for its whole duration.

The 5.x line already solves exactly this by tracking seen keys in a Set (src/tag/sequence/omap.ts):

if (carrier.seen.has(key)) return 'duplicate key in ordered map'
carrier.seen.add(key)

Proof of concept

// poc.js  —  node poc.js
const yaml = require('js-yaml');
const doc = n => '!!omap\n' + Array.from({length: n}, (_, i) => `- k${i}: ${i}`).join('\n') + '\n';

for (const n of [10000, 20000, 40000, 80000]) {
  const d = doc(n), t = Date.now();
  yaml.load(d);                      // default schema, no options
  console.log(`n=${n} bytes=${d.length} load=${Date.now() - t}ms`);
}

Measured (node v20.20.2, default heap, no flags)

js-yaml 4.3.0

n=10000  bytes=137787   load=54ms
n=20000  bytes=297787   load=169ms
n=40000  bytes=617787   load=646ms
n=80000  bytes=1257787  load=2607ms

js-yaml 3.15.0

n=10000  bytes=137787   load=53ms
n=20000  bytes=297787   load=166ms
n=40000  bytes=617787   load=641ms
n=80000  bytes=1257787  load=2567ms

Runtime grows by a factor of ~4 for each doubling of n, which is the signature of O(n²) (linear growth would be ~2×).

Scaling further: a 2.48 MB document with 150,000 entries blocked yaml.load() for 10.8 seconds.

Impact

Any service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be stalled with a small input. Because the loop is synchronous, a single request blocks the Node.js event loop and stalls every other request in the process — so the amplification is per-process, not just per-request.

Suggested severity: consistent with CVE-2026-59870 (the same weakness in 5.x), i.e. Availability-only impact, network attack vector, no privileges or user interaction required.

Suggested fix

Mirror the 5.x fix — replace the linear scan with a Set:

// lib/type/omap.js
const seen = new Set()
// ...
if (seen.has(pairKey)) return false
seen.add(pairKey)

This preserves the existing duplicate-key rejection semantics exactly while making resolution O(n). A maxOmapLength-style cap would also work, but the Set matches what 5.x already ships and requires no new option.

References

CVE-2026-59870 / GHSA-724g-mxrg-4qvm — same weakness in 5.0.0–5.2.0, fixed in 5.2.1
lib/type/omap.js (3.x, 4.x) — the affected resolver
lib/schema/default.js — registers !!omap in the default schema

Discovery

Found by an automated static-analysis and executed-proof-of-concept scanner run against js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by executing the proof of concept above. All timings in this report were measured on the current releases of each line, not on the version originally scanned.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "js-yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "js-yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-06T20:27:32Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x)\n\n## Summary\n\n`resolveYamlOmap()` enforces key uniqueness for `!!omap` sequences with a linear\nscan (`objectKeys.indexOf(...)`) inside the per-element loop, making resolution\n**O(n\u00b2)** in the number of entries. A modestly sized YAML document therefore\nconsumes disproportionate CPU inside `yaml.load()`, giving a denial of service\nagainst any consumer that parses untrusted YAML.\n\n`!!omap` is registered in the **default schema**\n(`lib/schema/default.js` \u2192 `require(\u0027../type/omap\u0027)`), so a plain\n`yaml.load(untrustedInput)` with no options is affected \u2014 no custom schema or\nnon-default configuration is required.\n\n**This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm**, which was\nfixed in the 5.x line in 5.2.1. That fix was never backported: both currently\nmaintained legacy lines still carry the original implementation.\n\n## Affected versions\n\n| Line | Latest tested | Status |\n|---|---|---|\n| 3.x | **3.15.0** | Affected \u2014 `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29` |\n| 4.x | **4.3.0** | Affected \u2014 `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30` |\n| 5.x | 5.2.2 | **Not affected** \u2014 fixed in 5.2.1 (uses a `Set`) |\n\nBoth figures are the newest release of each line at the time of writing, so\nthis is not a \"you are on an old version\" issue.\n\n## Details\n\n`lib/type/omap.js` (js-yaml 4.3.0):\n\n```js\nif (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)\nelse return false\n```\n\n`objectKeys` grows by one element per entry, and `Array.prototype.indexOf` is a\nlinear scan, so resolving an `n`-entry `!!omap` performs roughly\n`1 + 2 + \u2026 + n` comparisons \u2014 quadratic in `n`. The work happens synchronously\ninside `yaml.load()`, blocking the event loop for its whole duration.\n\nThe 5.x line already solves exactly this by tracking seen keys in a `Set`\n(`src/tag/sequence/omap.ts`):\n\n```ts\nif (carrier.seen.has(key)) return \u0027duplicate key in ordered map\u0027\ncarrier.seen.add(key)\n```\n\n## Proof of concept\n\n```js\n// poc.js  \u2014  node poc.js\nconst yaml = require(\u0027js-yaml\u0027);\nconst doc = n =\u003e \u0027!!omap\\n\u0027 + Array.from({length: n}, (_, i) =\u003e `- k${i}: ${i}`).join(\u0027\\n\u0027) + \u0027\\n\u0027;\n\nfor (const n of [10000, 20000, 40000, 80000]) {\n  const d = doc(n), t = Date.now();\n  yaml.load(d);                      // default schema, no options\n  console.log(`n=${n} bytes=${d.length} load=${Date.now() - t}ms`);\n}\n```\n\n### Measured (node v20.20.2, default heap, no flags)\n\n**js-yaml 4.3.0**\n\n```\nn=10000  bytes=137787   load=54ms\nn=20000  bytes=297787   load=169ms\nn=40000  bytes=617787   load=646ms\nn=80000  bytes=1257787  load=2607ms\n```\n\n**js-yaml 3.15.0**\n\n```\nn=10000  bytes=137787   load=53ms\nn=20000  bytes=297787   load=166ms\nn=40000  bytes=617787   load=641ms\nn=80000  bytes=1257787  load=2567ms\n```\n\nRuntime grows by a factor of ~4 for each doubling of `n`, which is the\nsignature of O(n\u00b2) (linear growth would be ~2\u00d7).\n\nScaling further: a **2.48 MB** document with 150,000 entries blocked\n`yaml.load()` for **10.8 seconds**.\n\n## Impact\n\nAny service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be\nstalled with a small input. Because the loop is synchronous, a single request\nblocks the Node.js event loop and stalls every other request in the process \u2014\nso the amplification is per-process, not just per-request.\n\nSuggested severity: consistent with **CVE-2026-59870** (the same weakness in\n5.x), i.e. Availability-only impact, network attack vector, no privileges or\nuser interaction required.\n\n## Suggested fix\n\nMirror the 5.x fix \u2014 replace the linear scan with a `Set`:\n\n```js\n// lib/type/omap.js\nconst seen = new Set()\n// ...\nif (seen.has(pairKey)) return false\nseen.add(pairKey)\n```\n\nThis preserves the existing duplicate-key rejection semantics exactly while\nmaking resolution O(n). A `maxOmapLength`-style cap would also work, but the\n`Set` matches what 5.x already ships and requires no new option.\n\n## References\n\n- CVE-2026-59870 / GHSA-724g-mxrg-4qvm \u2014 same weakness in 5.0.0\u20135.2.0, fixed in 5.2.1\n- `lib/type/omap.js` (3.x, 4.x) \u2014 the affected resolver\n- `lib/schema/default.js` \u2014 registers `!!omap` in the default schema\n\n## Discovery\n\nFound by an automated static-analysis and executed-proof-of-concept scanner run\nagainst js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by\nexecuting the proof of concept above. All timings in this report were measured\non the **current** releases of each line, not on the version originally scanned.",
  "id": "GHSA-5p4m-2wfm-xmqj",
  "modified": "2026-08-06T20:27:32Z",
  "published": "2026-08-06T20:27:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodeca/js-yaml/security/advisories/GHSA-5p4m-2wfm-xmqj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodeca/js-yaml"
    }
  ],
  "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": "JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) \u2014 CVE-2026-59870 fix not backported"
}

GHSA-5RVQ-CXJ2-64VF

Vulnerability from github – Published: 2026-06-15 20:24 – Updated: 2026-06-15 20:24

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

JSON

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"
}

CWE-407

Inefficient Algorithmic Complexity

Root Cause

Call chain

Proof of Concept

Impact

Suggested Fix

Summary

Details

Impact

Resolution

Impact

Patches

Workarounds

Quadratic CPU consumption in !!omap resolution (js-yaml 3.x and 4.x)

Summary

Affected versions

Details

Proof of concept

Measured (node v20.20.2, default heap, no flags)

Impact

Suggested fix

References

Discovery

Summary

Details

Impact

Mitigation

Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x)