Vulnerability-Lookup

GHSA-J828-28RJ-HFHP

Vulnerability from github – Published: 2025-05-28 17:50 – Updated: 2025-05-28 17:50

Summary

vLLM vulnerable to Regular Expression Denial of Service

Details

Summary

A recent review identified several regular expressions in the vllm codebase that are susceptible to Regular Expression Denial of Service (ReDoS) attacks. These patterns, if fed with crafted or malicious input, may cause severe performance degradation due to catastrophic backtracking.

1. vllm/lora/utils.py Line 173

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/lora/utils.py#L173 Risk Description: - The regex r"$(.*?)$\$?$" matches content inside parentheses. If input such as ((((a|)+)+)+) is passed in, it can cause catastrophic backtracking, leading to a ReDoS vulnerability. - Using .*? (non-greedy match) inside group parentheses can be highly sensitive to input length and nesting complexity.

Remediation Suggestions: - Limit the input string length. - Use a non-recursive matching approach, or write a regex with stricter content constraints. - Consider using possessive quantifiers or atomic groups (not supported in Python yet), or split and process before regex matching.

2. vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py Line 52

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py#L52

Risk Description: - The regex r'functools\[(.*?)\]' uses .*? to match content inside brackets, together with re.DOTALL. If the input contains a large number of nested or crafted brackets, it can cause backtracking and ReDoS.

Remediation Suggestions: - Limit the length of model_output. - Use a stricter, non-greedy pattern (avoid matching across extraneous nesting). - Prefer re.finditer() and enforce a length constraint on each match.

3. vllm/entrypoints/openai/serving_chat.py Line 351

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/serving_chat.py#L351

Risk Description: - The regex r'.*"parameters":\s*(.*)' can trigger backtracking if current_text is very long and contains repeated structures. - Especially when processing strings from unknown sources, .* matching any content is high risk.

Remediation Suggestions: - Use a more specific pattern (e.g., via JSON parsing). - Impose limits on current_text length. - Avoid using .* to capture large blocks of text; prefer structured parsing when possible.

4. benchmarks/benchmark_serving_structured_output.py Line 650

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/benchmarks/benchmark_serving_structured_output.py#L650

Risk Description: - The regex r'\{.*\}' is used to extract JSON inside curly braces. If the actual string is very long with unbalanced braces, it can cause backtracking, leading to a ReDoS vulnerability. - Although this is used for benchmark correctness checking, it should still handle abnormal inputs carefully.

Remediation Suggestions: - Limit the length of actual. - Prefer stepwise search for { and } or use a robust JSON extraction tool. - Recommend first locating the range with simple string search, then applying regex.

Fix

https://github.com/vllm-project/vllm/pull/18454

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": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.3"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-28T17:50:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA recent review identified several regular expressions in the vllm codebase that are susceptible to Regular Expression Denial of Service (ReDoS) attacks. These patterns, if fed with crafted or malicious input, may cause severe performance degradation due to catastrophic backtracking.\n\n#### 1. vllm/lora/utils.py [Line 173](https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/lora/utils.py#L173)\n\nhttps://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/lora/utils.py#L173\n**Risk Description:**\n- The regex `r\"\\((.*?)\\)\\$?$\"` matches content inside parentheses. If input such as `((((a|)+)+)+)` is passed in, it can cause catastrophic backtracking, leading to a ReDoS vulnerability.\n- Using `.*?` (non-greedy match) inside group parentheses can be highly sensitive to input length and nesting complexity.\n\n**Remediation Suggestions:**\n- Limit the input string length.\n- Use a non-recursive matching approach, or write a regex with stricter content constraints.\n- Consider using possessive quantifiers or atomic groups (not supported in Python yet), or split and process before regex matching.\n\n---\n\n#### 2. vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py [Line 52](https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py#L52)\n\nhttps://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py#L52\n\n**Risk Description:**\n- The regex `r\u0027functools\\[(.*?)\\]\u0027` uses `.*?` to match content inside brackets, together with `re.DOTALL`. If the input contains a large number of nested or crafted brackets, it can cause backtracking and ReDoS.\n\n**Remediation Suggestions:**\n- Limit the length of `model_output`.\n- Use a stricter, non-greedy pattern (avoid matching across extraneous nesting).\n- Prefer `re.finditer()` and enforce a length constraint on each match.\n\n---\n\n#### 3. vllm/entrypoints/openai/serving_chat.py [Line 351](https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/serving_chat.py#L351)\n\nhttps://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/serving_chat.py#L351\n\n**Risk Description:**\n- The regex `r\u0027.*\"parameters\":\\s*(.*)\u0027` can trigger backtracking if `current_text` is very long and contains repeated structures.\n- Especially when processing strings from unknown sources, `.*` matching any content is high risk.\n\n**Remediation Suggestions:**\n- Use a more specific pattern (e.g., via JSON parsing).\n- Impose limits on `current_text` length.\n- Avoid using `.*` to capture large blocks of text; prefer structured parsing when possible.\n\n---\n\n#### 4. benchmarks/benchmark_serving_structured_output.py [Line 650](https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/benchmarks/benchmark_serving_structured_output.py#L650)\n\nhttps://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/benchmarks/benchmark_serving_structured_output.py#L650\n\n**Risk Description:**\n- The regex `r\u0027\\{.*\\}\u0027` is used to extract JSON inside curly braces. If the `actual` string is very long with unbalanced braces, it can cause backtracking, leading to a ReDoS vulnerability.\n- Although this is used for benchmark correctness checking, it should still handle abnormal inputs carefully.\n\n**Remediation Suggestions:**\n- Limit the length of `actual`.\n- Prefer stepwise search for `{` and `}` or use a robust JSON extraction tool.\n- Recommend first locating the range with simple string search, then applying regex.\n\n### Fix\n\n* https://github.com/vllm-project/vllm/pull/18454\n\n---",
  "id": "GHSA-j828-28rj-hfhp",
  "modified": "2025-05-28T17:50:06Z",
  "published": "2025-05-28T17:50:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-j828-28rj-hfhp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/18454"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/4fc1bf813ad80172c1db31264beaef7d93fe0601"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    }
  ],
  "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"
    }
  ],
  "summary": "vLLM vulnerable to Regular Expression Denial of Service"
}

GHSA-J8PM-GJ4C-RQ4X

Vulnerability from github – Published: 2026-09-01 20:17 – Updated: 2026-09-01 20:17

Summary

league/commonmark: Denial of service via crafted code fences, reference links, and emphasis delimiters

Details

Impact

Affected versions of league/commonmark perform super-linear work on three independent parsing paths, all of which are reachable on a stock new CommonMarkConverter() with default configuration and no extensions registered. Each trigger fits on a single line of input, so no complex Markdown structure is required.

The three paths were introduced at different times. This advisory's version range is their union; the individual ranges are:

Path	Affected from	Affected through
1. Fenced code block detection	`0.6.0`	`2.9.0`
2. Reference link label lookup	`0.6.0`	`2.9.0`
3. Emphasis / strikethrough delimiters (`*`, `_`, `~`)	`2.6.0`	`2.9.0`
3. Highlight delimiters (`=`)	`2.9.0`	`2.9.0`

1. Fenced code block detection — quadratic, affected from 0.6.0.

FencedCodeStartParser matches the following pattern:

/^[ \t]*(?:`{3,}(?!.*`)|~{3,})/

The lookahead enforces the CommonMark rule that a backtick fence's info string may not itself contain a backtick, but neither the lookahead nor the backtick run it guards is atomic or possessive. On a line consisting of a long backtick run, filler text, and a single trailing backtick, the quantifier gives back one character at a time and re-runs the lookahead across the remainder of the line on every candidate fence length.

A 320 KB single line takes roughly 27 seconds to convert. The identical payload with one x character prefixed — which fails the parser's own leading-character guard — takes 0.011 seconds. preg_last_error() returns 0 at every input size tested, including runs of 160,000 characters, so PCRE never reaches pcre.backtrack_limit and this is sustained CPU consumption rather than an early bail-out.

2. Reference link label lookup — effectively quadratic, affected from 0.6.0.

When a shortcut or collapsed reference link is attempted, CloseBracketParser::tryParseReference() copies the entire span between the brackets and passes it to ReferenceMap::get(), which normalizes the label — up to four full passes over its length (trim, preg_replace, mb_check_encoding, and strtolower, or mb_convert_case on the non-ASCII path). Nested brackets produce one such lookup per closing bracket, each on a span two characters longer than the last.

In 2.x the normalization sits behind an early return for an empty reference map, so a single 8-byte reference definition anywhere in the document ([x]: y) is enough to unlock the path. At n = 64,000 nested brackets the same input takes 22.0 seconds with that line present versus 0.59 seconds without it. A single non-ASCII character inside the brackets forces the mb_convert_case branch, costing roughly 2.5x more again.

3. Emphasis, strikethrough, and highlight delimiter processing — super-linear, affected from 2.6.0.

DelimiterStack::processDelimiters() remains linear only because of the openersBottom memo, which bounds the backward opener scan — an argument that holds only if the memo's key space is O(1). EmphasisDelimiterProcessor::getCacheKey(), and the equivalents in StrikethroughDelimiterProcessor and MarkDelimiterProcessor, embed the closer's raw current run length in the key, leaving that space unbounded. An attacker spends O(n) bytes minting a growing number of distinct run lengths; each distinct length is a fresh key whose recorded bound starts at zero, forcing a full backward re-scan of the entire pile of openers.

The resulting work grows as roughly n^1.5. This is sub-quadratic, but the amplification over linear growth itself scales with input size, so it worsens as inputs grow: 800 KB of ordinary asterisks, letters, and spaces costs roughly 27 seconds on a stock converter.

This path is a regression introduced in 2.6.0. Before that release the cache key was the bare delimiter character — a bounded key space that amortized correctly. * and _ are affected on any default configuration from 2.6.0 onward. ~ (StrikethroughExtension, included in GithubFlavoredMarkdownConverter and GithubFlavoredMarkdownExtension) is affected from 2.6.0. = (HighlightExtension) is affected only from 2.9.0, when MarkDelimiterProcessor was declared cacheable.

Overall impact. An unauthenticated attacker who can submit Markdown for conversion can use a comparatively small request to consume disproportionate CPU time. Repeated or concurrent requests can occupy all available PHP workers and prevent legitimate requests from completing. The impact is limited to availability: no data is disclosed, rendered output is unchanged, and no rendering restriction is bypassed. Applications that process only trusted Markdown are not remotely exploitable.

Settings such as html_input, allow_unsafe_links, and max_nesting_level do not mitigate any of these, because the expensive work occurs during parsing, before rendering. max_delimiters_per_line bounds the third path only, and does so lossily — it silently discards emphasis once the cap is exhausted.

Patches

The issues are patched in 2.9.1 and later:

The fenced code block quantifier is now possessive, which is behavior-identical here: any character given back moves a backtick into the lookahead's scan range, so every retry was guaranteed to fail regardless.
Reference link lookups now apply the CommonMark 999-character link label limit before copying and normalizing the label, matching the limit already enforced when parsing reference definitions. Because a definition can never exceed that length, an over-length lookup label cannot match one directly. One edge case does change: a label longer than 999 characters that collapses to a shorter match once whitespace is normalized — for example [a followed by 998 spaces and b] against a [a b]: /url definition — previously rendered as a link and now renders literally. This follows cmark, which applies its own label-length cap before normalizing (cmark_reference_lookup()), and matches how this library has always handled the equivalent [text][label] form via LinkParserHelper::parseLinkLabel(). commonmark.js normalizes first and still resolves such labels.
Delimiter processor cache keys now clamp the run length to the coarsest bucket that can change behavior — min(length, 2) for emphasis, min(length, 3) for strikethrough and highlight — restoring a bounded key space while preserving byte-identical output.

Versions from 0.6.0 through 2.9.0 are affected by at least one of these paths; see the table above for which paths apply to which releases. The 0.x and 1.x release lines are no longer supported, so their users must upgrade to 2.9.1 or later.

Workarounds

If you cannot upgrade immediately, enforce a maximum length for individual lines before passing input to the converter, in addition to a total request-size limit. A per-line limit matters because every trigger described above fits within a single line. Because the cost grows super-linearly, the cap must be genuinely small to bound worst-case CPU.

Setting max_delimiters_per_line reduces exposure to the delimiter path only, and does so by silently dropping emphasis from the rendered output. It has no effect on the fenced code or reference link paths.

Restricting conversion to trusted users, applying strict execution-time limits, rate-limiting requests, and limiting concurrent conversions all reduce exposure, but none is a complete substitute for upgrading.

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": "Packagist",
        "name": "league/commonmark"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "2.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1050",
      "CWE-1333",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-01T20:17:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAffected versions of `league/commonmark` perform super-linear work on three independent parsing paths, all of which are reachable on a stock `new CommonMarkConverter()` with default configuration and no extensions registered. Each trigger fits on a single line of input, so no complex Markdown structure is required.\n\nThe three paths were introduced at different times. This advisory\u0027s version range is their union; the individual ranges are:\n\n| Path | Affected from | Affected through |\n|---|---|---|\n| 1. Fenced code block detection | `0.6.0` | `2.9.0` |\n| 2. Reference link label lookup | `0.6.0` | `2.9.0` |\n| 3. Emphasis / strikethrough delimiters (`*`, `_`, `~`) | `2.6.0` | `2.9.0` |\n| 3. Highlight delimiters (`=`) | `2.9.0` | `2.9.0` |\n\n**1. Fenced code block detection \u2014 quadratic, affected from 0.6.0.**\n\n`FencedCodeStartParser` matches the following pattern:\n\n```\n/^[ \\t]*(?:`{3,}(?!.*`)|~{3,})/\n```\n\nThe lookahead enforces the CommonMark rule that a backtick fence\u0027s info string may not itself contain a backtick, but neither the lookahead nor the backtick run it guards is atomic or possessive. On a line consisting of a long backtick run, filler text, and a single trailing backtick, the quantifier gives back one character at a time and re-runs the lookahead across the remainder of the line on every candidate fence length.\n\nA 320 KB single line takes roughly 27 seconds to convert. The identical payload with one `x` character prefixed \u2014 which fails the parser\u0027s own leading-character guard \u2014 takes 0.011 seconds. `preg_last_error()` returns `0` at every input size tested, including runs of 160,000 characters, so PCRE never reaches `pcre.backtrack_limit` and this is sustained CPU consumption rather than an early bail-out.\n\n**2. Reference link label lookup \u2014 effectively quadratic, affected from 0.6.0.**\n\nWhen a shortcut or collapsed reference link is attempted, `CloseBracketParser::tryParseReference()` copies the entire span between the brackets and passes it to `ReferenceMap::get()`, which normalizes the label \u2014 up to four full passes over its length (`trim`, `preg_replace`, `mb_check_encoding`, and `strtolower`, or `mb_convert_case` on the non-ASCII path). Nested brackets produce one such lookup per closing bracket, each on a span two characters longer than the last.\n\nIn 2.x the normalization sits behind an early return for an empty reference map, so a single 8-byte reference definition anywhere in the document (`[x]: y`) is enough to unlock the path. At n = 64,000 nested brackets the same input takes 22.0 seconds with that line present versus 0.59 seconds without it. A single non-ASCII character inside the brackets forces the `mb_convert_case` branch, costing roughly 2.5x more again.\n\n**3. Emphasis, strikethrough, and highlight delimiter processing \u2014 super-linear, affected from 2.6.0.**\n\n`DelimiterStack::processDelimiters()` remains linear only because of the `openersBottom` memo, which bounds the backward opener scan \u2014 an argument that holds only if the memo\u0027s key space is O(1). `EmphasisDelimiterProcessor::getCacheKey()`, and the equivalents in `StrikethroughDelimiterProcessor` and `MarkDelimiterProcessor`, embed the closer\u0027s raw current run length in the key, leaving that space unbounded. An attacker spends O(n) bytes minting a growing number of distinct run lengths; each distinct length is a fresh key whose recorded bound starts at zero, forcing a full backward re-scan of the entire pile of openers.\n\nThe resulting work grows as roughly n^1.5. This is sub-quadratic, but the amplification over linear growth itself scales with input size, so it worsens as inputs grow: 800 KB of ordinary asterisks, letters, and spaces costs roughly 27 seconds on a stock converter.\n\nThis path is a regression introduced in **2.6.0**. Before that release the cache key was the bare delimiter character \u2014 a bounded key space that amortized correctly. `*` and `_` are affected on any default configuration from 2.6.0 onward. `~` (`StrikethroughExtension`, included in `GithubFlavoredMarkdownConverter` and `GithubFlavoredMarkdownExtension`) is affected from 2.6.0. `=` (`HighlightExtension`) is affected only from **2.9.0**, when `MarkDelimiterProcessor` was declared cacheable.\n\n**Overall impact.** An unauthenticated attacker who can submit Markdown for conversion can use a comparatively small request to consume disproportionate CPU time. Repeated or concurrent requests can occupy all available PHP workers and prevent legitimate requests from completing. The impact is limited to availability: no data is disclosed, rendered output is unchanged, and no rendering restriction is bypassed. Applications that process only trusted Markdown are not remotely exploitable.\n\nSettings such as `html_input`, `allow_unsafe_links`, and `max_nesting_level` do not mitigate any of these, because the expensive work occurs during parsing, before rendering. `max_delimiters_per_line` bounds the third path only, and does so lossily \u2014 it silently discards emphasis once the cap is exhausted.\n\n### Patches\n\nThe issues are patched in `2.9.1` and later:\n\n- The fenced code block quantifier is now possessive, which is behavior-identical here: any character given back moves a backtick into the lookahead\u0027s scan range, so every retry was guaranteed to fail regardless.\n- Reference link *lookups* now apply the CommonMark 999-character link label limit before copying and normalizing the label, matching the limit already enforced when parsing reference *definitions*. Because a definition can never exceed that length, an over-length lookup label cannot match one directly. One edge case does change: a label longer than 999 characters that *collapses* to a shorter match once whitespace is normalized \u2014 for example `[a` followed by 998 spaces and `b]` against a `[a b]: /url` definition \u2014 previously rendered as a link and now renders literally. This follows cmark, which applies its own label-length cap before normalizing (`cmark_reference_lookup()`), and matches how this library has always handled the equivalent `[text][label]` form via `LinkParserHelper::parseLinkLabel()`. commonmark.js normalizes first and still resolves such labels.\n- Delimiter processor cache keys now clamp the run length to the coarsest bucket that can change behavior \u2014 `min(length, 2)` for emphasis, `min(length, 3)` for strikethrough and highlight \u2014 restoring a bounded key space while preserving byte-identical output.\n\nVersions from `0.6.0` through `2.9.0` are affected by at least one of these paths; see the table above for which paths apply to which releases. The 0.x and 1.x release lines are no longer supported, so their users must upgrade to `2.9.1` or later.\n\n### Workarounds\n\nIf you cannot upgrade immediately, enforce a **maximum length for individual lines** before passing input to the converter, in addition to a total request-size limit. A per-line limit matters because every trigger described above fits within a single line. Because the cost grows super-linearly, the cap must be genuinely small to bound worst-case CPU.\n\nSetting `max_delimiters_per_line` reduces exposure to the delimiter path only, and does so by silently dropping emphasis from the rendered output. It has no effect on the fenced code or reference link paths.\n\nRestricting conversion to trusted users, applying strict execution-time limits, rate-limiting requests, and limiting concurrent conversions all reduce exposure, but none is a complete substitute for upgrading.",
  "id": "GHSA-j8pm-gj4c-rq4x",
  "modified": "2026-09-01T20:17:59Z",
  "published": "2026-09-01T20:17:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-j8pm-gj4c-rq4x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/commit/0768217751fbfaeb8d76762f6944e9af7114295e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/commit/d9375fadc308a63a02950a68d822417a6e4c33b2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/commit/e0036ef031fd36ec1c3c82db8743fc928b5271c8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thephpleague/commonmark"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/releases/tag/2.9.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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "league/commonmark: Denial of service via crafted code fences, reference links, and emphasis delimiters"
}

GHSA-J8X9-QC9M-RMHJ

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32

Details

A vulnerability in lunary-ai/lunary, as of commit be54057, allows users to upload and execute arbitrary regular expressions on the server side. This can lead to a Denial of Service (DoS) condition, as certain regular expressions can cause excessive resource consumption, blocking the server from processing other requests.

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-2024-8764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-285"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:43Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in lunary-ai/lunary, as of commit be54057, allows users to upload and execute arbitrary regular expressions on the server side. This can lead to a Denial of Service (DoS) condition, as certain regular expressions can cause excessive resource consumption, blocking the server from processing other requests.",
  "id": "GHSA-j8x9-qc9m-rmhj",
  "modified": "2025-03-20T12:32:48Z",
  "published": "2025-03-20T12:32:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/7ff89b0304d191534b924cf063f3648206d497fa"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/088c04a1-d23a-47f2-9d7c-b84d7332868d"
    }
  ],
  "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-J8XG-FQG3-53R7

Vulnerability from github – Published: 2023-06-22 06:30 – Updated: 2025-02-13 19:00

Summary

word-wrap vulnerable to Regular Expression Denial of Service

Details

All versions of the package word-wrap are vulnerable to Regular Expression Denial of Service (ReDoS) due to the usage of an insecure regular expression within the result variable.

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": "word-wrap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-23T21:36:40Z",
    "nvd_published_at": "2023-06-22T05:15:09Z",
    "severity": "MODERATE"
  },
  "details": "All versions of the package word-wrap are vulnerable to Regular Expression Denial of Service (ReDoS) due to the usage of an insecure regular expression within the result variable.",
  "id": "GHSA-j8xg-fqg3-53r7",
  "modified": "2025-02-13T19:00:43Z",
  "published": "2023-06-22T06:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26115"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/word-wrap/commit/420dce9a2412b21881202b73a3c34f0edc53cb2e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jonschlinkert/word-wrap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/word-wrap/blob/master/index.js#L39"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/word-wrap/blob/master/index.js%23L39"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/word-wrap/releases/tag/1.2.4"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0006"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-4058657"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-WORDWRAP-3149973"
    }
  ],
  "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": "word-wrap vulnerable to Regular Expression Denial of Service"
}

GHSA-J934-XHV5-FG8F

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

Summary

Soup Sieve: Polynomial-time ReDoS (O(n²)) in the whitespace/comment trimming regex `RE_WS_END` (triggers on VALID selectors)

Details

Summary

Before tokenizing, selector_iter trims leading/trailing whitespace and comments by running two regexes over the whole raw selector with .search(). The trailing one, RE_WS_END = re.compile(r'{WSC}*$'), is anchored only at the end ($), not the start. Because .search() retries the pattern at every offset, a long run of whitespace or CSS comments that is not sitting exactly at the end of the string makes each retry greedily consume the run and then fail $, producing O(n²) time. This triggers on perfectly valid selectors — e.g. a descendant combinator with a long whitespace gap, a + " "*n + b — so no malformed input is required. A single valid ~20 KB selector stalls the interpreter for ~10 s of CPU.

Trust model (Q0)

The selector string is the input, reaching this code via soupsieve.compile(), the soupsieve.select/iselect/match/filter helpers, and BeautifulSoup's soup.select(selector) / soup.select_one(selector). Exploitable wherever an application passes a user-controlled CSS selector to BeautifulSoup/soupsieve. Applications using only hard-coded selectors are unaffected.

Root cause (exact anchors) — `src/soupsieve/css_parser.py`

# line 185-186
RE_WS_BEGIN = re.compile(fr'^{WSC}*')   # anchored at start -> .search() only tries pos 0 -> linear (safe)
RE_WS_END   = re.compile(fr'{WSC}*$')   # NOT anchored at start -> .search() tries every offset

# selector_iter, lines ~1322-1326
m = RE_WS_BEGIN.search(pattern)
index = m.end(0) if m else 0
m = RE_WS_END.search(pattern)                     # <-- O(n^2) here
end = (m.start(0) - 1) if m else (len(pattern) - 1)

WSC = (?:{WS}|{COMMENTS}). For RE_WS_END = (?:WS|COMMENTS)*$, .search() walks start offsets 0..n. Whenever the offset lands inside a long whitespace/comment run, (?:WS|COMMENTS)* greedily consumes to the run's end, then $ fails (a non-whitespace char follows), the engine backtracks the whole run, the offset advances by one, and the work repeats — O(n) offsets × O(n) per attempt = O(n²). RE_WS_BEGIN avoids this because ^ pins it to a single start offset.

The intent (trim trailing whitespace/comments) can be met with an anchored/loopless approach; the current unanchored .search() of a *$ pattern is the defect.

Reproduction environment (discipline #12 — published artifact)

git HEAD 751c57b (2.9, PYTHONPATH=src): cd src && python3 ../poc/poc_redos_ws_trim.py.
Published PyPI soupsieve 2.8.4 (fresh uv pip install soupsieve beautifulsoup4): cd poc && ../.venv-published/bin/python poc_redos_ws_trim.py → same O(n²) (evidence: poc/evidence_redos_ws_trim_PUBLISHED_2.8.4.log).
Python 3.11.15 and 3.14.6 both reproduce.

PoC (`poc/poc_redos_ws_trim.py`)

import sys, time
sys.path.insert(0, ".")
import soupsieve as sv

def ct(sel):
    t0 = time.perf_counter()
    try:
        sv.compile(sel); st = "ok"
    except Exception as e:
        st = type(e).__name__
    return time.perf_counter() - t0, st

print(f"soupsieve {sv.__version__}\n")

print("VALID selector 'a' + ' '*n + 'b'  (descendant combinator, lots of whitespace):")
for n in (2000, 4000, 8000, 16000):
    dt, st = ct("a" + " " * n + "b")
    print(f"  n={n:<6} len={n+2:<7} {dt*1000:9.1f} ms  [{st}]")

payload = "a" + " " * 20000 + "b"
dt, st = ct(payload)
print(f"\n[+] Single call: compile('a' + ' '*20000 + 'b')  (len={len(payload)})")
print(f"[+] wall time = {dt:.2f} s   [{st}]")

Isolated confirmation that the cost is in RE_WS_END.search specifically (poc/isolate_ws_trim.py): RE_WS_END on "div"+" "*n+">" is O(n²) (2000→100 ms, 4000→448 ms, 8000→1622 ms, 16000→6719 ms), while the start-anchored RE_WS_BEGIN on " "*n+"x" stays linear (32000→1.5 ms). Profiling compile shows the entire wall time in 2 re.Pattern.search calls, not .match.

Evidence — HEAD 2.9 (verbatim `poc/evidence_redos_ws_trim.log`)

soupsieve 2.9

VALID selector 'a' + ' '*n + 'b'  (descendant combinator, lots of whitespace):
  n=2000   len=2002        112.3 ms  [ok]
  n=4000   len=4002        411.5 ms  [ok]
  n=8000   len=8002       1602.9 ms  [ok]
  n=16000  len=16002      6464.1 ms  [ok]

VALID-looking 'a' + '/*x*/'*n + 'b'  (CSS comment run):
  n=1000   len=5002         48.9 ms  [SelectorSyntaxError]
  n=2000   len=10002       194.8 ms  [SelectorSyntaxError]
  n=4000   len=20002       780.2 ms  [SelectorSyntaxError]
  n=8000   len=40002      3145.3 ms  [SelectorSyntaxError]

[+] Single call: compile('a' + ' '*20000 + 'b')  (len=20002)
[+] wall time = 10.23 s   [ok]

Evidence — published 2.8.4 (verbatim `poc/evidence_redos_ws_trim_PUBLISHED_2.8.4.log`)

soupsieve 2.8.4

VALID selector 'a' + ' '*n + 'b':
  n=2000   len=2002        102.7 ms  [ok]
  n=4000   len=4002        404.3 ms  [ok]
  n=8000   len=8002       1618.2 ms  [ok]
  n=16000  len=16002      6457.9 ms  [ok]
[+] Single call: compile('a' + ' '*20000 + 'b')  wall time = 10.11 s   [ok]

Impact — calibrated

Confirmed: quadratic CPU per compile()/select() call on an attacker-controlled selector, triggered by a long internal whitespace or CSS-comment run. ~8 KB → ~1.6 s; ~20 KB → ~10 s; scaling ~×4 per input doubling. Notably fires on WELL-FORMED selectors, so it does not depend on a parser error path.
Realistic exposure: services that accept user-supplied CSS selectors and feed them to BeautifulSoup/soupsieve.
NOT claimed: exponential blowup, memory corruption, or code execution. Availability (DoS) only, and only where selectors are attacker-influenced.

Distinction from the IDENTIFIER/VALUE ReDoS

This is a separate root cause and a separate fix: the cost here is entirely in the RE_WS_END = {WSC}*$ trim step run with .search() before tokenizing (measured in re.Pattern.search), whereas the IDENTIFIER/VALUE issue is adjacent-quantifier backtracking during token .match(). They can be fixed independently.

Remediation

Anchor or de-loop the trailing-trim step: instead of .search() of {WSC}*$, scan trailing whitespace/comments from the end directly (e.g. reverse scan, or re.compile(r'^{WSC}*').match on a reversed-equivalent), so no per-offset retry occurs.
Alternatively strip whitespace/comments in a single forward tokenizing pass rather than with a pre-pass *$ search.
Defense-in-depth: cap selector length before compiling.

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": "PyPI",
        "name": "soupsieve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-85999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T20:32:53Z",
    "nvd_published_at": "2026-09-17T16:18:16Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nBefore tokenizing, `selector_iter` trims leading/trailing whitespace and comments by running two regexes over the whole raw selector with `.search()`. The trailing one, `RE_WS_END = re.compile(r\u0027{WSC}*$\u0027)`, is anchored only at the end (`$`), not the start. Because `.search()` retries the pattern at every offset, a long run of whitespace or CSS comments that is not sitting exactly at the end of the string makes each retry greedily consume the run and then fail `$`, producing O(n\u00b2) time. This triggers on perfectly valid selectors \u2014 e.g. a descendant combinator with a long whitespace gap, `a` + `\" \"*n` + `b` \u2014 so no malformed input is required. A single valid ~20 KB selector stalls the interpreter for ~10 s of CPU.\n\n## Trust model (Q0)\n\nThe selector string is the input, reaching this code via `soupsieve.compile()`, the `soupsieve.select/iselect/match/filter` helpers, and BeautifulSoup\u0027s `soup.select(selector)` / `soup.select_one(selector)`. Exploitable wherever an application passes a user-controlled CSS selector to BeautifulSoup/soupsieve. Applications using only hard-coded selectors are unaffected.\n\n## Root cause (exact anchors) \u2014 `src/soupsieve/css_parser.py`\n\n```python\n# line 185-186\nRE_WS_BEGIN = re.compile(fr\u0027^{WSC}*\u0027)   # anchored at start -\u003e .search() only tries pos 0 -\u003e linear (safe)\nRE_WS_END   = re.compile(fr\u0027{WSC}*$\u0027)   # NOT anchored at start -\u003e .search() tries every offset\n\n# selector_iter, lines ~1322-1326\nm = RE_WS_BEGIN.search(pattern)\nindex = m.end(0) if m else 0\nm = RE_WS_END.search(pattern)                     # \u003c-- O(n^2) here\nend = (m.start(0) - 1) if m else (len(pattern) - 1)\n```\n\n`WSC = (?:{WS}|{COMMENTS})`. For `RE_WS_END = (?:WS|COMMENTS)*$`, `.search()` walks start offsets 0..n. Whenever the offset lands inside a long whitespace/comment run, `(?:WS|COMMENTS)*` greedily consumes to the run\u0027s end, then `$` fails (a non-whitespace char follows), the engine backtracks the whole run, the offset advances by one, and the work repeats \u2014 O(n) offsets \u00d7 O(n) per attempt = O(n\u00b2). `RE_WS_BEGIN` avoids this because `^` pins it to a single start offset.\n\nThe intent (trim trailing whitespace/comments) can be met with an anchored/loopless approach; the current unanchored `.search()` of a `*$` pattern is the defect.\n\n## Reproduction environment (discipline #12 \u2014 published artifact)\n\n- git HEAD `751c57b` (2.9, `PYTHONPATH=src`): `cd src \u0026\u0026 python3 ../poc/poc_redos_ws_trim.py`.\n- Published PyPI `soupsieve 2.8.4` (fresh `uv pip install soupsieve beautifulsoup4`): `cd poc \u0026\u0026 ../.venv-published/bin/python poc_redos_ws_trim.py` \u2192 same O(n\u00b2) (evidence: `poc/evidence_redos_ws_trim_PUBLISHED_2.8.4.log`).\n- Python 3.11.15 and 3.14.6 both reproduce.\n\n## PoC (`poc/poc_redos_ws_trim.py`)\n\n```python\nimport sys, time\nsys.path.insert(0, \".\")\nimport soupsieve as sv\n\ndef ct(sel):\n    t0 = time.perf_counter()\n    try:\n        sv.compile(sel); st = \"ok\"\n    except Exception as e:\n        st = type(e).__name__\n    return time.perf_counter() - t0, st\n\nprint(f\"soupsieve {sv.__version__}\\n\")\n\nprint(\"VALID selector \u0027a\u0027 + \u0027 \u0027*n + \u0027b\u0027  (descendant combinator, lots of whitespace):\")\nfor n in (2000, 4000, 8000, 16000):\n    dt, st = ct(\"a\" + \" \" * n + \"b\")\n    print(f\"  n={n:\u003c6} len={n+2:\u003c7} {dt*1000:9.1f} ms  [{st}]\")\n\npayload = \"a\" + \" \" * 20000 + \"b\"\ndt, st = ct(payload)\nprint(f\"\\n[+] Single call: compile(\u0027a\u0027 + \u0027 \u0027*20000 + \u0027b\u0027)  (len={len(payload)})\")\nprint(f\"[+] wall time = {dt:.2f} s   [{st}]\")\n```\n\nIsolated confirmation that the cost is in `RE_WS_END.search` specifically (`poc/isolate_ws_trim.py`): `RE_WS_END` on `\"div\"+\" \"*n+\"\u003e\"` is O(n\u00b2) (2000\u2192100 ms, 4000\u2192448 ms, 8000\u21921622 ms, 16000\u21926719 ms), while the start-anchored `RE_WS_BEGIN` on `\" \"*n+\"x\"` stays linear (32000\u21921.5 ms). Profiling `compile` shows the entire wall time in 2 `re.Pattern.search` calls, not `.match`.\n\n## Evidence \u2014 HEAD 2.9 (verbatim `poc/evidence_redos_ws_trim.log`)\n\n```\nsoupsieve 2.9\n\nVALID selector \u0027a\u0027 + \u0027 \u0027*n + \u0027b\u0027  (descendant combinator, lots of whitespace):\n  n=2000   len=2002        112.3 ms  [ok]\n  n=4000   len=4002        411.5 ms  [ok]\n  n=8000   len=8002       1602.9 ms  [ok]\n  n=16000  len=16002      6464.1 ms  [ok]\n\nVALID-looking \u0027a\u0027 + \u0027/*x*/\u0027*n + \u0027b\u0027  (CSS comment run):\n  n=1000   len=5002         48.9 ms  [SelectorSyntaxError]\n  n=2000   len=10002       194.8 ms  [SelectorSyntaxError]\n  n=4000   len=20002       780.2 ms  [SelectorSyntaxError]\n  n=8000   len=40002      3145.3 ms  [SelectorSyntaxError]\n\n[+] Single call: compile(\u0027a\u0027 + \u0027 \u0027*20000 + \u0027b\u0027)  (len=20002)\n[+] wall time = 10.23 s   [ok]\n```\n\n## Evidence \u2014 published 2.8.4 (verbatim `poc/evidence_redos_ws_trim_PUBLISHED_2.8.4.log`)\n\n```\nsoupsieve 2.8.4\n\nVALID selector \u0027a\u0027 + \u0027 \u0027*n + \u0027b\u0027:\n  n=2000   len=2002        102.7 ms  [ok]\n  n=4000   len=4002        404.3 ms  [ok]\n  n=8000   len=8002       1618.2 ms  [ok]\n  n=16000  len=16002      6457.9 ms  [ok]\n[+] Single call: compile(\u0027a\u0027 + \u0027 \u0027*20000 + \u0027b\u0027)  wall time = 10.11 s   [ok]\n```\n\n## Impact \u2014 calibrated\n\n- Confirmed: quadratic CPU per `compile()`/`select()` call on an attacker-controlled selector, triggered by a long internal whitespace or CSS-comment run. ~8 KB \u2192 ~1.6 s; ~20 KB \u2192 ~10 s; scaling ~\u00d74 per input doubling. Notably fires on WELL-FORMED selectors, so it does not depend on a parser error path.\n- Realistic exposure: services that accept user-supplied CSS selectors and feed them to BeautifulSoup/soupsieve.\n- NOT claimed: exponential blowup, memory corruption, or code execution. Availability (DoS) only, and only where selectors are attacker-influenced.\n\n## Distinction from the IDENTIFIER/VALUE ReDoS\n\nThis is a separate root cause and a separate fix: the cost here is entirely in the `RE_WS_END = {WSC}*$` trim step run with `.search()` before tokenizing (measured in `re.Pattern.search`), whereas the IDENTIFIER/VALUE issue is adjacent-quantifier backtracking during token `.match()`. They can be fixed independently.\n\n## Remediation\n\n- Anchor or de-loop the trailing-trim step: instead of `.search()` of `{WSC}*$`, scan trailing whitespace/comments from the end directly (e.g. reverse scan, or `re.compile(r\u0027^{WSC}*\u0027).match` on a reversed-equivalent), so no per-offset retry occurs.\n- Alternatively strip whitespace/comments in a single forward tokenizing pass rather than with a pre-pass `*$` search.\n- Defense-in-depth: cap selector length before compiling.",
  "id": "GHSA-j934-xhv5-fg8f",
  "modified": "2026-09-17T20:32:53Z",
  "published": "2026-09-17T20:32:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/facelessuser/soupsieve/security/advisories/GHSA-j934-xhv5-fg8f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85999"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facelessuser/soupsieve/commit/cf198fcddc9230f06ed39f974eba0ce076b85cda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/facelessuser/soupsieve"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facelessuser/soupsieve/releases/tag/2.9"
    }
  ],
  "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": "Soup Sieve: Polynomial-time ReDoS (O(n\u00b2)) in the whitespace/comment trimming regex `RE_WS_END` (triggers on VALID selectors)"
}

GHSA-J95F-988M-3J2F

Vulnerability from github – Published: 2026-09-08 21:24 – Updated: 2026-09-08 21:24

Summary

Tiptap: Quadratic ReDoS in block and inline Markdown attribute parsing

Details

Summary

@tiptap/core contains two quadratic regular-expression denial-of-service paths in its default Markdown attribute parsers. Pandoc-style block attributes use two unanchored greedy expressions that rescan repeated __QUOTED_0 prefixes. Inline shortcode attributes use another unanchored greedy key expression that rescans a long word-character run when no equals sign follows.

The public createAtomBlockMarkdownSpec and createBlockMarkdownSpec helpers call the vulnerable Pandoc-style parser; createInlineMarkdownSpec calls the separately vulnerable shortcode parser. Using unmodified npm 3.29.2, a complete 20,508-byte atom-block token took approximately 1.40 seconds while an equal-length control took 0.29 ms. A complete 32,776-byte inline token took approximately 2.21 seconds while its equal-length control took 0.19 ms. Current repository main commit 5158212970344952dd9918b6a44bfb400d7fb6c1 retains both expressions.

Block attribute root cause

packages/core/src/utilities/markdown/attributeUtils.ts uses both matchAll and replace with /([a-zA-Z][\w-]*)\s*=\s*(__QUOTED_\d+__)/g. The candidate is '__QUOTED_0'.repeat(n) + '__QUOTED_0__'. There are no quotes, so the preceding replacement leaves it unchanged. At each Q, the greedy key-name expression consumes the remaining word-character run, the required equals sign fails, and the unanchored engine restarts at the next Q. This yields O(n^2) work, and the cleanup pass repeats it.

A complete public-API proof is:

import { createAtomBlockMarkdownSpec } from '@tiptap/core'
const tokenizer = createAtomBlockMarkdownSpec({ nodeName: 'probe' }).markdownTokenizer
const attack = '__QUOTED_0'.repeat(2048) + '__QUOTED_0__'
const source = `:::probe {${attack}} :::\n`
const started = performance.now()
tokenizer.tokenize(source, [], {})
console.log(performance.now() - started)

Measured complete-tokenizer timings were 6.23, 23.12, 88.93, 369.10, and 1,400.17 ms at 1,308, 2,588, 5,148, 10,268, and 20,508 bytes. Equal-length controls took 0.07 to 0.29 ms. The directly exported parser took 5,645.71 ms at 40,972 bytes while its control took 0.64 ms.

Inline attribute root cause

packages/core/src/utilities/markdown/createInlineMarkdownSpec.ts uses /(\w+)=(?:"([^"]*)"|'([^']*)')/g. For a long word-character run without an equals sign, \w+ consumes the remaining suffix, = fails, and the unanchored engine restarts at the next character. The default inline tokenizer extracts this attacker string directly from a syntactically complete [shortcode attributes] token.

import { createInlineMarkdownSpec } from '@tiptap/core'
const tokenizer = createInlineMarkdownSpec({ nodeName: 'probe', selfClosing: true }).markdownTokenizer
const source = `[probe ${'0'.repeat(32768)}]`
const started = performance.now()
tokenizer.tokenize(source, [], {})
console.log(performance.now() - started)

At 1,032, 2,056, 4,104, 8,200, 16,392, and 32,776 bytes, candidates took 3.24, 12.88, 54.82, 136.91, 557.83, and 2,209.47 ms. Equal-length hyphen controls took 0.02 to 0.19 ms.

Impact

Applications parsing attacker-controlled Markdown with these helpers can have a browser main thread, server event loop, or worker blocked by a small input. Persisted documents can repeatedly freeze clients; repeated requests can exhaust server-side parsing capacity. Editors that only consume validated ProseMirror JSON and never invoke the Markdown parsing path are not directly affected through document content.

History and remediation

Commit 35645d94ae9cd73448a564104c2e08f64e9564bc introduced both parsers on 14 October 2025, first released in 3.7.0. Versions 3.7.0 through current 3.29.2 and current main remain affected. Official issue, PR, and repository-advisory searches found no duplicate.

Require a start-of-string or whitespace boundary before both key-value parsers, and preferably replace the multi-pass placeholder and shortcode regex designs with deterministic single-pass tokenizers. Keep quoted values out-of-band so attacker input cannot collide with predictable __QUOTED_n__ placeholders. Add complete block and inline Markdown-tokenizer scaling regressions with equal-length controls.

Please credit GitHub user joostgrunwald as finder/reporter.

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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@tiptap/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.30.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T21:24:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`@tiptap/core` contains two quadratic regular-expression denial-of-service paths in its default Markdown attribute parsers. Pandoc-style block attributes use two unanchored greedy expressions that rescan repeated `__QUOTED_0` prefixes. Inline shortcode attributes use another unanchored greedy key expression that rescans a long word-character run when no equals sign follows.\n\nThe public `createAtomBlockMarkdownSpec` and `createBlockMarkdownSpec` helpers call the vulnerable Pandoc-style parser; `createInlineMarkdownSpec` calls the separately vulnerable shortcode parser. Using unmodified npm 3.29.2, a complete 20,508-byte atom-block token took approximately 1.40 seconds while an equal-length control took 0.29 ms. A complete 32,776-byte inline token took approximately 2.21 seconds while its equal-length control took 0.19 ms. Current repository `main` commit `5158212970344952dd9918b6a44bfb400d7fb6c1` retains both expressions.\n\n## Block attribute root cause\n\n`packages/core/src/utilities/markdown/attributeUtils.ts` uses both `matchAll` and `replace` with `/([a-zA-Z][\\w-]*)\\s*=\\s*(__QUOTED_\\d+__)/g`. The candidate is `\u0027__QUOTED_0\u0027.repeat(n) + \u0027__QUOTED_0__\u0027`. There are no quotes, so the preceding replacement leaves it unchanged. At each `Q`, the greedy key-name expression consumes the remaining word-character run, the required equals sign fails, and the unanchored engine restarts at the next `Q`. This yields `O(n^2)` work, and the cleanup pass repeats it.\n\nA complete public-API proof is:\n\n```js\nimport { createAtomBlockMarkdownSpec } from \u0027@tiptap/core\u0027\nconst tokenizer = createAtomBlockMarkdownSpec({ nodeName: \u0027probe\u0027 }).markdownTokenizer\nconst attack = \u0027__QUOTED_0\u0027.repeat(2048) + \u0027__QUOTED_0__\u0027\nconst source = `:::probe {${attack}} :::\\n`\nconst started = performance.now()\ntokenizer.tokenize(source, [], {})\nconsole.log(performance.now() - started)\n```\n\nMeasured complete-tokenizer timings were 6.23, 23.12, 88.93, 369.10, and 1,400.17 ms at 1,308, 2,588, 5,148, 10,268, and 20,508 bytes. Equal-length controls took 0.07 to 0.29 ms. The directly exported parser took 5,645.71 ms at 40,972 bytes while its control took 0.64 ms.\n\n## Inline attribute root cause\n\n`packages/core/src/utilities/markdown/createInlineMarkdownSpec.ts` uses `/(\\w+)=(?:\"([^\"]*)\"|\u0027([^\u0027]*)\u0027)/g`. For a long word-character run without an equals sign, `\\w+` consumes the remaining suffix, `=` fails, and the unanchored engine restarts at the next character. The default inline tokenizer extracts this attacker string directly from a syntactically complete `[shortcode attributes]` token.\n\n```js\nimport { createInlineMarkdownSpec } from \u0027@tiptap/core\u0027\nconst tokenizer = createInlineMarkdownSpec({ nodeName: \u0027probe\u0027, selfClosing: true }).markdownTokenizer\nconst source = `[probe ${\u00270\u0027.repeat(32768)}]`\nconst started = performance.now()\ntokenizer.tokenize(source, [], {})\nconsole.log(performance.now() - started)\n```\n\nAt 1,032, 2,056, 4,104, 8,200, 16,392, and 32,776 bytes, candidates took 3.24, 12.88, 54.82, 136.91, 557.83, and 2,209.47 ms. Equal-length hyphen controls took 0.02 to 0.19 ms.\n\n## Impact\n\nApplications parsing attacker-controlled Markdown with these helpers can have a browser main thread, server event loop, or worker blocked by a small input. Persisted documents can repeatedly freeze clients; repeated requests can exhaust server-side parsing capacity. Editors that only consume validated ProseMirror JSON and never invoke the Markdown parsing path are not directly affected through document content.\n\n## History and remediation\n\nCommit `35645d94ae9cd73448a564104c2e08f64e9564bc` introduced both parsers on 14 October 2025, first released in 3.7.0. Versions 3.7.0 through current 3.29.2 and current `main` remain affected. Official issue, PR, and repository-advisory searches found no duplicate.\n\nRequire a start-of-string or whitespace boundary before both key-value parsers, and preferably replace the multi-pass placeholder and shortcode regex designs with deterministic single-pass tokenizers. Keep quoted values out-of-band so attacker input cannot collide with predictable `__QUOTED_n__` placeholders. Add complete block and inline Markdown-tokenizer scaling regressions with equal-length controls.\n\nPlease credit GitHub user `joostgrunwald` as finder/reporter.",
  "id": "GHSA-j95f-988m-3j2f",
  "modified": "2026-09-08T21:24:09Z",
  "published": "2026-09-08T21:24:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ueberdosis/tiptap/security/advisories/GHSA-j95f-988m-3j2f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ueberdosis/tiptap/commit/d0d499be3cce633cf54ca9aa9f3d8a5a1f98bd74"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ueberdosis/tiptap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ueberdosis/tiptap/releases/tag/v3.30.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": "Tiptap: Quadratic ReDoS in block and inline Markdown attribute parsing"
}

GHSA-J9M2-H2PV-WVPH

Vulnerability from github – Published: 2022-06-03 00:00 – Updated: 2024-11-12 14:55

Summary

Regular expression denial of service in jquery-validation

Details

An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the jquery-validation npm package, when an attacker is able to supply arbitrary input to the url2 method

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jquery-validation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-03T22:26:59Z",
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "LOW"
  },
  "details": "An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the jquery-validation npm package, when an attacker is able to supply arbitrary input to the url2 method",
  "id": "GHSA-j9m2-h2pv-wvph",
  "modified": "2024-11-12T14:55:23Z",
  "published": "2022-06-03T00:00:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43306"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jquery-validation/jquery-validation/pull/2428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jquery-validation/jquery-validation/commit/69cb17ed774b427f7e2ffcdf197968231725c30e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jquery-validation/jquery-validation"
    },
    {
      "type": "WEB",
      "url": "https://research.jfrog.com/vulnerabilities/jquery-validation-redos-xray-211348"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Regular expression denial of service in jquery-validation"
}

GHSA-JC97-H3H9-7XH6

Vulnerability from github – Published: 2023-04-03 17:18 – Updated: 2023-04-03 17:18

Summary

Regular Expression Denial of Service in Deno.upgradeWebSocket API

Details

Impact

Versions of the package deno before 1.31.0 are vulnerable to Regular Expression Denial of Service (ReDoS) due to the upgradeWebSocket function, which contains regexes in the form of /s,s/, used for splitting the Connection/Upgrade header. A specially crafted Connection/Upgrade header can be used to significantly slow down a web socket server.

Patches

It is recommended that users upgrade to Deno 1.31.0.

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": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "1.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26103"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-03T17:18:51Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nVersions of the package deno before 1.31.0 are vulnerable to Regular Expression Denial of Service (ReDoS) due to the upgradeWebSocket function, which contains regexes in the form of /s*,s*/, used for splitting the Connection/Upgrade header. A specially crafted Connection/Upgrade header can be used to significantly slow down a web socket server. \n\n### Patches\nIt is recommended that users upgrade to Deno 1.31.0.\n\n",
  "id": "GHSA-jc97-h3h9-7xh6",
  "modified": "2023-04-03T17:18:51Z",
  "published": "2023-04-03T17:18:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-jc97-h3h9-7xh6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26103"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/pull/17722"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/commit/cf06a7c7e672880e1b38598fe445e2c50b4a9d06"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/blob/2b247be517d789a37e532849e2e40b724af0918f/ext/http/01_http.js#L395-L409"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/releases/tag/v1.31.0"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-RUST-DENO-3315970"
    }
  ],
  "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": "Regular Expression Denial of Service in Deno.upgradeWebSocket API"
}

GHSA-JCPV-G9RR-QXRC

Vulnerability from github – Published: 2018-07-31 22:52 – Updated: 2021-09-14 19:39

Summary

Regular Expression Denial of Service in hawk

Details

Versions of hawk prior to 3.1.3, or 4.x prior to 4.1.1 are affected by a regular expression denial of service vulnerability related to excessively long headers and URI's.

Recommendation

Update to hawk version 4.1.1 or later.

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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hawk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "hawk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-2515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:43:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions of `hawk` prior to 3.1.3, or 4.x prior to 4.1.1 are affected by a regular expression denial of service vulnerability related to excessively long headers and URI\u0027s.\n\n\n\n## Recommendation\n\nUpdate to hawk version 4.1.1 or later.",
  "id": "GHSA-jcpv-g9rr-qxrc",
  "modified": "2021-09-14T19:39:20Z",
  "published": "2018-07-31T22:52:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-2515"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hueniverse/hawk/issues/168"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hueniverse/hawk/commit/0833f99ba64558525995a7e21d4093da1f3e15fa"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1309721"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-jcpv-g9rr-qxrc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hueniverse/hawk"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/77"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/02/20/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2016/02/20/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Regular Expression Denial of Service in hawk"
}

GHSA-JFM2-HQ55-PXGQ

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32

Details

Lunary-ai/lunary version git 105a3f6 is vulnerable to a Regular Expression Denial of Service (ReDoS) attack. The application allows users to upload their own regular expressions, which are then executed on the server side. Certain regular expressions can have exponential runtime complexity relative to the input size, leading to potential denial of service. An attacker can exploit this by submitting a specially crafted regular expression, causing the server to become unresponsive for an arbitrary length of time.

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-2024-8789"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:44Z",
    "severity": "HIGH"
  },
  "details": "Lunary-ai/lunary version git 105a3f6 is vulnerable to a Regular Expression Denial of Service (ReDoS) attack. The application allows users to upload their own regular expressions, which are then executed on the server side. Certain regular expressions can have exponential runtime complexity relative to the input size, leading to potential denial of service. An attacker can exploit this by submitting a specially crafted regular expression, causing the server to become unresponsive for an arbitrary length of time.",
  "id": "GHSA-jfm2-hq55-pxgq",
  "modified": "2025-03-20T12:32:49Z",
  "published": "2025-03-20T12:32:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8789"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/7ff89b0304d191534b924cf063f3648206d497fa"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/e32f5f0d-bd46-4268-b6b1-619e07c6fda3"
    }
  ],
  "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"
    }
  ]
}

CWE-1333

Inefficient Regular Expression Complexity

Summary

1. vllm/lora/utils.py Line 173

2. vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py Line 52

3. vllm/entrypoints/openai/serving_chat.py Line 351

4. benchmarks/benchmark_serving_structured_output.py Line 650

Fix

Impact

Patches

Workarounds

Summary

Trust model (Q0)

Root cause (exact anchors) — src/soupsieve/css_parser.py

Reproduction environment (discipline #12 — published artifact)

PoC (poc/poc_redos_ws_trim.py)

Evidence — HEAD 2.9 (verbatim poc/evidence_redos_ws_trim.log)

Evidence — published 2.8.4 (verbatim poc/evidence_redos_ws_trim_PUBLISHED_2.8.4.log)

Impact — calibrated

Distinction from the IDENTIFIER/VALUE ReDoS

Remediation

Summary

Block attribute root cause

Inline attribute root cause

Impact

History and remediation

Impact

Patches

Recommendation

Mitigation

Mitigation

Mitigation

Mitigation

CAPEC-492: Regular Expression Exponential Blowup

Root cause (exact anchors) — `src/soupsieve/css_parser.py`

PoC (`poc/poc_redos_ws_trim.py`)

Evidence — HEAD 2.9 (verbatim `poc/evidence_redos_ws_trim.log`)

Evidence — published 2.8.4 (verbatim `poc/evidence_redos_ws_trim_PUBLISHED_2.8.4.log`)