SQL parsers are critical components of the modern data stack. They validate queries before they reach the database, transpile between dialects, and lint codebases for style violations. Increasingly, they also power AI-driven SQL generation in LLM-integrated data tools.
Our research focused on two popular Python-based parsers: SQLGlot and SQLFluff, both with around 10k GitHub stars each. These libraries sit at the foundation of the data ecosystem, trusted by thousands of projects, and we believe the underlying issues are relevant to other parsers and other programming languages as well.
But these parsers carry a hidden flaw. They are highly susceptible to resource exhaustion from seemingly “simple,” syntactically valid SQL queries. Not injection. Not malformed input. Just normal-looking SQL that happens to be shaped in the wrong way.
In this post, we describe our findings of new vulnerabilities stemming from two root causes: Recursive Stack Overflow and Parser AST Object-Inflation. We show how these flaws cascade into downstream applications, giving concrete examples from several major projects we found vulnerable, with many more still to be explored. We then explain the underlying mechanics and conclude with practical fix suggestions for both parser maintainers and application developers. We reported every issue to the respective maintainers and contributed to the fixes that now ship upstream; the SQLFluff findings were assigned CVE-2026-46373 and CVE-2026-46374.
The First Clue: A Query That Crashes the Interpreter
Our research began with a simple question: what happens when you feed a deeply nested query to a SQL parser?
The answer: the Python interpreter crashes with a RecursionError. At higher concurrency, it segfaults.
This isn’t a contrived edge case. The query is syntactically valid SQL. Any database would reject it for being absurd, but a parser’s job is to parse it – and both SQLGlot and SQLFluff attempt to do so without any depth limit. At 50+ levels of nesting, the recursive descent parser exhausts the call stack.
The fix seems obvious in hindsight: enforce a maximum recursion depth (e.g., 30 levels) and abort gracefully. But neither parser does this.
Going Wider: AST Object Inflation
The recursion crash was just the beginning. As we explored further, we discovered a more insidious problem: AST amplification.
SQL parsers work by converting raw SQL text into an Abstract Syntax Tree (AST) – a structured representation where each token (literal, identifier, operator, dot) becomes a Python object. These objects carry metadata: type information, position tracking, parent references. They’re heavyweight.
The question became: what if we crafted a query that was short but produced an enormous number of AST nodes?
The result was striking. In SQLGlot, a SQL string under 2MB in size demanded over 1.5GB of RAM to parse – roughly a 750x amplification ratio. SQLFluff showed the same pattern: at width=5000, it consumed over 1GB.
This is the core vulnerability: each SQL token gets wrapped in a heavy Python object. A compact input with thousands of columns and deep expression chains generates millions of AST nodes, far exceeding what any reasonable container or server can handle. The process is killed by the OOM killer – or simply hangs until it starves out everything else on the machine.
The Amplification Chain
To see where the cost comes from, it helps to follow the input through each stage of parsing. The payload starts small, but every step multiplies it: tokenization splits the string into hundreds of thousands of pieces, AST construction wraps each one in a heavyweight Python object, and the resulting tree balloons into gigabytes of memory. The diagram below traces that roughly 750x expansion from a 2MB string to a 1.5GB+ footprint.
The key insight is that object inflation is the root cause. It isn’t about the input being “large”, it’s about the multiplicative cost of turning each token into a rich object. A 2MB string is a perfectly normal payload by any standard. But the parser amplifies it by orders of magnitude.
The Cascade: From Parser to Platform – Examples
A vulnerability in a parser library is concerning on its own. But parsers don’t exist in isolation, they’re embedded deep in application stacks. When the parser crashes, the application may crash with it.
We traced this cascade through several major projects.
Apache Superset: Complete Service Outage
Apache Superset (~75k stars) uses SQLGlot under the hood. Its SQL Lab feature allows authenticated users to write and execute queries.
The weakness lives in the pre-execution phase. When a user submits a query through SQL Lab, Superset hands the raw SQL to SQLGlot for parsing and validation before it ever reaches the database and before any complexity checks are applied. There is no limit on query size, nesting depth, or AST node count at this boundary. An authenticated user with ordinary SQL Lab access is enough; the query never has to run.
Depending on the payload size, the attack produces two distinct denial-of-service states:
- Memory exhaustion (OOM crash): Large payloads (roughly 5 MB and up) drive AST allocation past available system RAM. The worker is terminated with a SIGKILL and restarted, dropping in-flight requests.
- CPU/thread exhaustion (zombie hang): Moderate payloads (around 1.5 MB) don’t trip the OOM killer but saturate CPU and hold the GIL, so parsing never completes. The GIL (Global Interpreter Lock) is a mutex in CPython that lets only one thread execute Python bytecode at a time; a thread stuck in a long, pure-Python parse keeps the lock and starves every other thread in the process. Every user sees persistent timeouts while the worker is pinned.
The attack is simple: authenticate as a normal user, then send a batch of concurrent requests to /api/v1/sqllab/execute/, each carrying a payload built from a large number of columns of a deeply nested x=x=x… expression. The number of columns determines which failure mode you hit:
- A wide payload (on the order of tens of thousands of columns) makes container memory climb steadily until the worker is killed within a few minutes, emitting the tell-tale log line:
-
[ERROR] Worker (pid:14) was sent SIGKILL! Perhaps out of memory?
- A smaller payload hangs the server with consistent timeouts for all users without triggering the OOM killer.
The exact thresholds depend on available memory – a 16 GB host behaves differently from a 4 GB container – but either way, a single authenticated user takes down SQL Lab, and the shared worker pool, for everyone.
Dify: Plugin Framework Collapse
Dify (~150k stars) Uses SQLGlot within its plugin ecosystem. We found two vulnerable plugins – db-client-node and dify-bigquery-plugin – and that the plugin framework’s architecture amplified the parser vulnerability into a system-wide failure.
A large SQL payload (10,000 columns x 60 depth) executed through a workflow that triggers 5 concurrent database queries caused a 5GB RAM spike. This didn’t just kill the plugin – it destroyed the IPC bridge between Dify’s Go-based daemon and its Python workers.
PluginDaemonInternalServerError: write |1: file already closed failed to write request
The daemon lost track of healthy workers. The system entered a “Blackout” state for approximately 60 seconds, during which all tool calls across the entire framework returned errors – not just those involving the parser.
SQLFluff Online: Backend Exhaustion via Missing Input Limit
SQLFluff Online (source) exposes the parser through a web API. The frontend enforces a 3,000-character input limit. The backend does not.
By sending a crafted payload directly to the /fluffed endpoint – bypassing the frontend – a single request consumed 2GB+ of RAM and saturated the CPU. The service locked up entirely.
Pathway: OOM in the SQL Interface
Pathway (~60k stars) uses SQLGlot internally and exposes a pw.sql interface that accepts user queries. We submitted a crafted query (10,000 columns x 70 depth) and watched memory grow unboundedly, consuming 8GB+ of RAM. The server was killed with OOMKilled: true and ExitCode: 137. Pathway produced no error or warning before the crash.
The Bigger Picture: Parser Exhaustion
The security community has spent decades hardening systems against SQL Injection, the manipulation of query structure to execute unauthorized commands. This is a different class of attack entirely.
Parser Exhaustion doesn’t inject anything. It doesn’t exploit string concatenation or missing parameterization. The queries are syntactically valid. They would parse correctly on any SQL grammar. They just happen to be shaped in a way that overwhelms the parser’s resource consumption.
This distinction matters because Parser Exhaustion bypasses many traditional defenses:
- Parameterized queries aren’t relevant for generated queries, where the whole structure is dynamic
- Input sanitization won’t catch it – there are no special characters to escape
- WAFs typically look for injection patterns, not resource-exhausting shapes
As the industry moves toward automated SQL generation and LLM-integrated data tools, this attack surface grows. LLMs can generate arbitrarily complex SQL. If that SQL passes through a parser – for validation, linting, or transpilation – the parser becomes an attack vector. Not because the SQL is malicious in the traditional sense, but because it’s expensive.
The parser is no longer just a utility. It’s a trust boundary.
Practical Mitigations
The good news: these vulnerabilities are straightforward to mitigate. Simple limits on recursion depth and AST size can harden parsers against this entire class of attack.
At the Parser Level
1. Recursion depth limit: abort parsing if nesting exceeds a threshold:
2. AST node limit: count nodes during construction and abort if a threshold is exceeded:
We reported both issues to the maintainers of SQLGlot and SQLFluff and contributed to the fixes. SQLGlot now enforces a configurable recursion/complexity limit during parsing (merged ahead of the v30.5.0 release), and SQLFluff adopted comparable guards. If you depend on either library, upgrade to a patched version and keep the default limits enabled.
At the Application Level
The bad news: not all parsers support limits. If the parser you use enforces a recursion or node limit, enabling it is the best way to mitigate these vulnerabilities. If it doesn’t, defend at the application level:
- Enforce input limits: reject queries before parsing based on cheap, pre-parse metrics: raw byte size, token count, nesting/parenthesis depth, and column count. These caps cost almost nothing to check and stop the pathological shapes before a single AST node is allocated. Apply them on the server, not just the client – the SQLFluff Online case shows that a frontend-only limit is trivially bypassed.
- Set execution timeouts for parsing operations: don’t let a single query consume a worker indefinitely
- Implement memory limits via container constraints (Docker –memory) to contain blast radius
- Rate limit query submissions, especially in multi-tenant environments
- Isolate plugin execution: use network namespaces or sandboxed processes so a plugin crash doesn’t cascade
Not Only SQL
SQL parsers are not special. The root causes – unbounded recursion and object inflation – are properties of recursive-descent parsers in general. We found the same patterns in query languages built on entirely different grammars.
Cypher (Neo4j)
Neo4j’s Cypher query language (~17k stars) exhibits both failure modes:
- Deep nesting: A query with ~1,500+ nested parentheses, lists, or maps causes the connection to hang for 240 seconds before timing out.
- CPU exhaustion: Parsing exhibits quadratic time on long chains of AND/OR operators. A query with 30,000 chained operators takes 172+ seconds to parse, with a peak heap of ~1.3 GB and worker-thread starvation – a small input that pins a worker for minutes.
GraphQL
GraphQL (~20k stars) is the instructive counter-example: the spec supports a max_tokens limit, but whether it’s enforced by default varies by implementation.
- graphql-java – ships a sensible default 15,000-token limit. But even that budget is enough for ~1,800 fragments (~50 KB) to saturate CPU for several minutes on every request. A default limit helps, but the threshold still has to be tuned to resource cost, not just token count. For further reading, see our write-up on remote DoS attacks against graphql-java.
- Source：https://www.imperva.com/blog/the-hidden-dos-vector-in-sql-parsers/
