CWE-1333
AllowedInefficient Regular Expression Complexity
Abstraction: Base · Status: Draft
The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.
866 vulnerabilities reference this CWE, most recent first.
GHSA-J533-2G8V-PMPG
Vulnerability from github – Published: 2023-02-12 15:30 – Updated: 2023-02-22 16:31A vulnerability, which was classified as problematic, was found in simple-markdown 0.6.0. Affected is an unknown function of the file simple-markdown.js. The manipulation with the input <<<<<<<<<<:/:/:/:/:/:/:/:/:/:/ leads to inefficient regular expression complexity. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.6.1 is able to address this issue. The name of the patch is 015a719bf5cdc561feea05500ecb3274ef609cd2. It is recommended to upgrade the affected component. VDB-220638 is the identifier assigned to this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "simple-markdown"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-25102"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-14T00:57:45Z",
"nvd_published_at": "2023-02-12T14:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability, which was classified as problematic, was found in simple-markdown 0.6.0. Affected is an unknown function of the file simple-markdown.js. The manipulation with the input \u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c\u003c:/:/:/:/:/:/:/:/:/:/ leads to inefficient regular expression complexity. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.6.1 is able to address this issue. The name of the patch is 015a719bf5cdc561feea05500ecb3274ef609cd2. It is recommended to upgrade the affected component. VDB-220638 is the identifier assigned to this vulnerability.",
"id": "GHSA-j533-2g8v-pmpg",
"modified": "2023-02-22T16:31:59Z",
"published": "2023-02-12T15:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25102"
},
{
"type": "WEB",
"url": "https://github.com/ariabuckles/simple-markdown/pull/73"
},
{
"type": "WEB",
"url": "https://github.com/ariabuckles/simple-markdown/commit/015a719bf5cdc561feea05500ecb3274ef609cd2"
},
{
"type": "PACKAGE",
"url": "https://github.com/ariabuckles/simple-markdown"
},
{
"type": "WEB",
"url": "https://github.com/ariabuckles/simple-markdown/releases/tag/0.6.1"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.220638"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.220638"
}
],
"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": "Regular Expression Denial of Service in simple-markdown"
}
GHSA-J535-V25Q-VX3Q
Vulnerability from github – Published: 2026-09-10 15:12 – Updated: 2026-09-10 15:12Impact
The Git node's clone operation matched the destination path against the default N8N_BLOCK_FILE_PATTERNS expression, which was written so that a crafted path caused catastrophic backtracking. Evaluation runs synchronously in the main n8n process, so an authenticated user could freeze the instance for everyone with a single workflow execution and no unusual configuration. The patch rewrites the pattern so that matching is linear in the length of the path.
Patches
The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict n8n instance access to fully trusted users only.
- Disable the Git node by adding n8n-nodes-base.git to the NODES_EXCLUDE environment variable.
- Set N8N_BLOCK_FILE_PATTERNS to a backtracking-safe equivalent pattern to replace the vulnerable default.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.123.76"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "2.38.0"
},
{
"fixed": "2.38.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.37.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-86081"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T15:12:00Z",
"nvd_published_at": "2026-09-08T22:19:17Z",
"severity": "HIGH"
},
"details": "## Impact\n\nThe Git node\u0027s clone operation matched the destination path against the default `N8N_BLOCK_FILE_PATTERNS` expression, which was written so that a crafted path caused catastrophic backtracking. Evaluation runs synchronously in the main n8n process, so an authenticated user could freeze the instance for everyone with a single workflow execution and no unusual configuration. The patch rewrites the pattern so that matching is linear in the length of the path.\n\n## Patches\n\nThe issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\n\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict n8n instance access to fully trusted users only.\n- Disable the Git node by adding `n8n-nodes-base.git` to the `NODES_EXCLUDE` environment variable.\n- Set `N8N_BLOCK_FILE_PATTERNS` to a backtracking-safe equivalent pattern to replace the vulnerable default.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
"id": "GHSA-j535-v25q-vx3q",
"modified": "2026-09-10T15:12:00Z",
"published": "2026-09-10T15:12:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-j535-v25q-vx3q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86081"
},
{
"type": "PACKAGE",
"url": "https://github.com/n8n-io/n8n"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@1.123.76"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.37.7"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.38.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "n8n: Regular Expression Denial of Service in the Default Blocked-File-Pattern Match via a Git Node Clone Path"
}
GHSA-J5CC-6RX8-FF96
Vulnerability from github – Published: 2025-06-17 15:31 – Updated: 2025-07-07 18:32The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.
{
"affected": [],
"aliases": [
"CVE-2025-6069"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-17T14:15:33Z",
"severity": "MODERATE"
},
"details": "The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.",
"id": "GHSA-j5cc-6rx8-ff96",
"modified": "2025-07-07T18:32:21Z",
"published": "2025-06-17T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6069"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/issues/135462"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/pull/135464"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/4455cbabf991e202185a25a631af206f60bbc949"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/6eb6c5dbfb528bd07d77b60fd71fd05d81d45c41"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/8d1b3dfa09135affbbf27fb8babcf3c11415df49"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/ab0893fd5c579d9cea30841680e6d35fc478afb5"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/d851f8e258c7328814943e923a7df81bca15df4b"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/f3c6f882cddc8dc30320d2e73edf019e201394fc"
},
{
"type": "WEB",
"url": "https://github.com/python/cpython/commit/fdc9d214c01cb4588f540cfa03726bbf2a33fc15"
},
{
"type": "WEB",
"url": "https://mail.python.org/archives/list/security-announce@python.org/thread/K5PIYLR6EP3WR7ZOKKYQUWEDNQVUXOYM"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-J5P7-JF4Q-742Q
Vulnerability from github – Published: 2022-12-27 09:30 – Updated: 2023-01-10 15:38A vulnerability was found in markdown-it up to 2.x. It has been classified as problematic. Affected is an unknown function of the file lib/common/html_re.js. The manipulation leads to inefficient regular expression complexity. Upgrading to version 3.0.0 is able to address this issue. The name of the patch is 89c8620157d6e38f9872811620d25138fc9d1b0d. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-216852.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "markdown-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2015-10005"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-30T16:27:08Z",
"nvd_published_at": "2022-12-27T09:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in markdown-it up to 2.x. It has been classified as problematic. Affected is an unknown function of the file `lib/common/html_re.js`. The manipulation leads to inefficient regular expression complexity. Upgrading to version 3.0.0 is able to address this issue. The name of the patch is 89c8620157d6e38f9872811620d25138fc9d1b0d. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-216852.",
"id": "GHSA-j5p7-jf4q-742q",
"modified": "2023-01-10T15:38:01Z",
"published": "2022-12-27T09:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-10005"
},
{
"type": "WEB",
"url": "https://github.com/markdown-it/markdown-it/commit/89c8620157d6e38f9872811620d25138fc9d1b0d"
},
{
"type": "PACKAGE",
"url": "https://github.com/markdown-it/markdown-it"
},
{
"type": "WEB",
"url": "https://github.com/markdown-it/markdown-it/releases/tag/3.0.0"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.216852"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.216852"
}
],
"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 vulnerable to Inefficient Regular Expression Complexity"
}
GHSA-J6GC-792M-QGM2
Vulnerability from github – Published: 2023-01-18 18:23 – Updated: 2025-02-18 22:35There is a possible regular expression based DoS vulnerability in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-22796.
Versions Affected: All Not affected: None Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1 Impact
A specially crafted string passed to the underscore method can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability.
This affects String#underscore, ActiveSupport::Inflector.underscore, String#titleize, and any other methods using these.
All users running an affected release should either upgrade or use one of the workarounds immediately. Releases
The FIXED releases are available at the normal locations. Workarounds
There are no feasible workarounds for this issue.
Users on Ruby 3.2.0 or greater may be able to reduce the impact by configuring Regexp.timeout. Patches
To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.
6-1-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 6.1 series
7-0-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 7.0 series
Please note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "activesupport"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.1.7.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "activesupport"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-22796"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-18T18:23:20Z",
"nvd_published_at": "2023-02-09T20:15:00Z",
"severity": "LOW"
},
"details": "There is a possible regular expression based DoS vulnerability in Active Support. This vulnerability has been assigned the CVE identifier CVE-2023-22796.\n\nVersions Affected: All Not affected: None Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1\nImpact\n\nA specially crafted string passed to the underscore method can cause the regular expression engine to enter a state of catastrophic backtracking. This can cause the process to use large amounts of CPU and memory, leading to a possible DoS vulnerability.\n\nThis affects String#underscore, ActiveSupport::Inflector.underscore, String#titleize, and any other methods using these.\n\nAll users running an affected release should either upgrade or use one of the workarounds immediately.\nReleases\n\nThe FIXED releases are available at the normal locations.\nWorkarounds\n\nThere are no feasible workarounds for this issue.\n\nUsers on Ruby 3.2.0 or greater may be able to reduce the impact by configuring Regexp.timeout.\nPatches\n\nTo aid users who aren\u2019t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.\n\n 6-1-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 6.1 series\n 7-0-Avoid-regex-backtracking-in-Inflector.underscore.patch - Patch for 7.0 series\n\nPlease note that only the 7.0.Z and 6.1.Z series are supported at present, and 6.0.Z for severe vulnerabilities. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.",
"id": "GHSA-j6gc-792m-qgm2",
"modified": "2025-02-18T22:35:59Z",
"published": "2023-01-18T18:23:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22796"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/commit/2164d4f6a1bde74b911fe9ba3c8df1b5bf345bf8"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/commit/a7cda7e6aa5334ab41b1f4b0f671be931be946ef"
},
{
"type": "WEB",
"url": "https://discuss.rubyonrails.org/t/cve-2023-22796-possible-redos-based-dos-vulnerability-in-active-supports-underscore/82116"
},
{
"type": "PACKAGE",
"url": "https://github.com/rails/rails"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/releases/tag/v6.1.7.1"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/releases/tag/v7.0.4.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activesupport/CVE-2023-22796.yml"
},
{
"type": "WEB",
"url": "https://rubyonrails.org/2023/1/17/Rails-Versions-6-0-6-1-6-1-7-1-7-0-4-1-have-been-released"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "ReDoS based DoS vulnerability in Active Support\u0027s underscore"
}
GHSA-J828-28RJ-HFHP
Vulnerability from github – Published: 2025-05-28 17:50 – Updated: 2025-05-28 17:50Summary
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
{
"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:17Impact
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
[afollowed by 998 spaces andb]against a[a b]: /urldefinition — 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 viaLinkParserHelper::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.
{
"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:32A 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.
{
"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:00All 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.
{
"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:32Summary
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(freshuv 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, orre.compile(r'^{WSC}*').matchon 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.
{
"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)"
}
Mitigation
Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
Mitigation
Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
Mitigation
Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
Mitigation
Limit the length of the input that the regular expression will process.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.