一、漏洞信息
漏洞编号：CVE-2026-59893
漏洞归属组件：python-sqlparse
漏洞归属的版本：0.3.1,0.4.1,0.4.2,0.4.3,0.4.4,0.5.1,0.5.5
CVSS评分：
BaseScore：7.5 High
Vector：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
漏洞简述：

Summarysqlparse 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.### DetailsThe vulnerable regex is defined in sqlparse/keywords.py as part of SQL_REGEX:python# 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):python# sqlparse/lexer.py:136-138for 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:20 — parse(sql) accepts caller-controlled SQL.2. sqlparse/__init__.py:29 — delegates to parsestream(sql, encoding).3. sqlparse/__init__.py:43 — FilterStack.run(stream, encoding) is invoked.4. sqlparse/engine/filter_stack.py:31 — lexer.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.### PoCPrerequisites: Python 3.x with sqlparse installed (tested against version 0.5.6.dev0, commit c923da9).Using Docker (isolated reproduction):bash# Build from the repository root (parent of vuln-001/)docker build -t sqlparse-vuln001 -f vuln-001/Dockerfile .# Run with no network accessdocker run --rm --network=none sqlparse-vuln001Direct Python reproduction:pythonimport timeimport sqlparsefrom sqlparse.exceptions import SQLParseErrordef 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=okn= 500 bytes= 3889 elapsed=0.144s status=okn= 1000 bytes= 7889 elapsed=0.397s status=okn= 2000 bytes= 16889 elapsed=1.314s status=okKey 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}$xEach 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 commentsReported 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:python# 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²).PoCpythonimport time, sqlparsefor 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.### ImpactThis 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````dockerfileFROM python:3.11-slim# Install build dependenciesRUN 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 codeCOPY repo/ /app/repo/# Install sqlparse from local source in editable modeRUN 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 PoCCMD [ pytho

漏洞公开时间：2026-08-18 02:17:35
漏洞创建时间：2026-08-18 04:19:36
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2026-59893

漏洞分析指导链接：
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
七彩瞬析开源风险感知平台
漏洞补丁信息：

二、漏洞分析结构反馈
影响性分析说明：
sqlparse 的词法分析器在每个输入位置逐条尝试 SQL_REGEX 中的全部正则（sqlparse/lexer.py 的 for pos, char in iterable 主循环）。其中三条正则采用「懒惰 dot-all 量词 + 定界符收尾」的形态:1. ((?<! S) $(?:[_A-ZÀ-Ü] w*)? $)[ s S]? 1 —— dollar-quoted 字面量，用反向引用匹配闭合定界符；2. / * +[ s S]? */ —— 多行 Hint 注释；3. / [ s S]? */ —— 多行注释。当输入包含大量不闭合的开定界符时，每个开定界符都要扫描到字符串末尾才能判定失败，整体退化为 O(n^2)，即 ReDoS。攻击者只需向任何调用 sqlparse.parse() / format() / split() 的接口投递构造的 SQL 文本即可持续占满 CPU，无需认证、无需用户交互。需要说明的是，grouping 阶段的 MAX_GROUPING_TOKENS 限制在词法分析「完成之后」才生效，无法约束正则的 CPU 开销，因此不构成缓解措施。该漏洞属 CWE-1333（Inefficient Regular Expression Complexity），远程可达、无需权限与用户交互，仅影响可用性。修复方案:回合上游 commit d1d80602741f77ec78e5a04ce4719244cf32352e（上游 0.6.0）。该补丁改用两阶段线性算法——先以 re.finditer 一次性定位全部定界符，再在一次从左到右的遍历中配对开闭定界符（新增 keywords.find_delimited_spans() 与 utils.resolve_paired_delimiters()），并从 SQL_REGEX 中移除上述三条正则。sqlparse 自带测试 428 passed, 3 xfailed 全部通过。
openEuler评分：
7.5
Vector：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响)：
1.master(0.5.5):受影响
2.openEuler-20.03-LTS-SP4(0.3.1):受影响
3.openEuler-22.03-LTS-SP4(0.4.2):受影响
4.openEuler-24.03-LTS-Next(0.4.4):受影响
5.openEuler-24.03-LTS-SP1(0.4.4):受影响
6.openEuler-24.03-LTS-SP3(0.4.4):受影响
7.openEuler-24.03-LTS-SP4(0.4.4):受影响

修复是否涉及abi变化(是/否)：
1.master(0.5.5):否
2.openEuler-20.03-LTS-SP4(0.3.1):否
3.openEuler-22.03-LTS-SP4(0.4.2):否
4.openEuler-24.03-LTS-Next(0.4.4):否
5.openEuler-24.03-LTS-SP1(0.4.4):否
6.openEuler-24.03-LTS-SP3(0.4.4):否
7.openEuler-24.03-LTS-SP4(0.4.4):否

原因说明：
1.master(0.5.5):正常修复
2.openEuler-20.03-LTS-SP4(0.3.1):正常修复
3.openEuler-22.03-LTS-SP4(0.4.2):正常修复
4.openEuler-24.03-LTS-Next(0.4.4):正常修复
5.openEuler-24.03-LTS-SP1(0.4.4):正常修复
6.openEuler-24.03-LTS-SP3(0.4.4):正常修复
7.openEuler-24.03-LTS-SP4(0.4.4):正常修复