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. 
• graphql-js (no token limit by default) – a single unauthenticated POST expands a 6.9 MB payload into ~1.77 GB RSS (~256x amplification) and blocks the worker for ~14.6 s. Under –stack-size=65500 (common in production) it crashes outright. Confirmed against Apollo Server v5.5.1. 
• graphql-core (Python, no token limit by default) – ~7 MB expands to ~2 GB RSS (~276x amplification), blocking the worker for ~23.4 s. A payload under 1 KB triggers a RecursionError at depth ~300. 

The takeaway: this is a parser-design problem, not a SQL problem. Any parser that turns untrusted text into a rich object tree without bounding depth or node count is exposed. 

Conclusion 

We disclosed vulnerabilities in SQLGlot, SQLFluff (CVE-2026-46373, CVE-2026-46374), and several downstream applications – all stemming from the same root cause: parsers that trust their input to be reasonable. Beyond reporting, we worked with both maintainer teams and contributed to the fixes that now ship upstream, so every project depending on these libraries benefits by upgrading. The fixes themselves are straightforward: depth limits, node counting, input size validation. But the lesson is broader. 

Parsers have quietly become critical infrastructure. They’re embedded in data platforms, CI/CD pipelines, AI agents, and production workflows. Yet they’ve historically been treated as safe, deterministic utilities that “just work.” Our findings show that even syntactically correct queries can be weaponized to dismantle the systems that depend on them. 

As the industry moves toward automated SQL generation and LLM-integrated data tools, the parser is no longer a passive utility – it’s an active attack surface. Hardening it requires the same discipline we apply to any other trust boundary: validate input, limit resource consumption, and assume that anything coming from outside the system is potentially adversarial. 

It’s time to move beyond SQL Injection. Welcome to Parser Exhaustion. 

The post The Hidden DoS Vector in SQL Parsers appeared first on Blog.

Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCert’s 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.

The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.

Why TLS certificate lifespans are shrinking to 47 days

Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.

How to prepare for 47-day certificates: five things to do, in order

1. Inventory what you actually have. Every certificate, every domain, every site, and who renews it. Cloud WAF reports SSL coverage status for each protected site, so start with your public-facing estate. It is the part with a deadline attached and the part your customers meet first.
2. Automate domain validation now. Manual validation at a 10-day reuse window is not a process, it is a permanent job for somebody. Automatic CNAME validation makes ownership proof continuous, and it is the single change that turns the 2029 schedule from alarming to routine. The payoff starts now, not in 2029: Imperva already requires domain revalidation every 99 days for its managed certificates. We walked through the setup in Effortless certificate management with automated CNAME validation.
3. Find your non-SNI traffic before it finds you. Server Name Indication (SNI) is the TLS extension that tells the server which hostname a client is asking for. Clients that do not send it, usually older HTTP libraries, outdated monitoring tools and misconfigured internal services, cannot be served a site certificate (a site with non-SNI connections is not eligible for one), and they are rejected outright once a site moves to SNI-only mode. That is why this step comes before the next one. Non-SNI clients are also invisible unless you go looking. One custom rule with the filter hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.
4. Isolate the blast radius. A certificate shared across your whole estate means one renewal problem is everyone’s problem. Imperva site certificates give each site its own certificate, its own coverage status and up to 50 domains, so one team’s missed renewal does not become another team’s outage. New SNI-only sites have required site certificates since September 13, 2026, and Imperva recommends migrating existing SNI sites off shared account certificates by December 31, 2026, before automatic migration begins in Q1 2027.
5. Connect the certificate system you already run. If your certificates are governed in a Certificate Lifecycle Management (CLM) platform, the system that issues, tracks and renews certificates centrally, or in your own PKI, those renewals should reach your WAF without a person in between. The SSL Integration Center connects that workflow directly to Imperva Cloud WAF. DigiCert Trust Lifecycle Manager and Keyfactor Command are on the supported vendor list, with further CLM integrations in progress.

What Imperva is already doing: 90-day certificates and the R46 root

Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.

The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.

Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.

Frequently asked questions about 47-day certificates

When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.

How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.

Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.

What happens to clients that don’t support SNI?
A client that doesn’t send SNI can’t be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.

The post 47-Day Certificates Are Coming: Five Things to Do Before They Arrive appeared first on Blog.

Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.

Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.

What shipped: hybrid post-quantum TLS on every Cloud WAF site

Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your users’ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography can’t wait; this post is the update now that both legs are covered.

The second leg: post-quantum TLS from Imperva to your origin

A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the user’s browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin can’t negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.

The honest scope: what hybrid key agreement covers

Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NIST’s ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.

What to do about harvest now, decrypt later

• Nothing, for the client leg. It is already on.
• Check your origin stack for hybrid key-agreement support, and switch on the second leg when it does. That means OpenSSL 3.5 or later. New sites have PQC to origin on by default; existing sites need it switched on once, in the Cloud Security Console or through the API.
• Put one line in your next security review: sessions through Cloud WAF are quantum-safe by default. Boards like sentences that end.

Detail, including how to test PQC and how to switch it on for your origin, is in the Post-Quantum Cryptography (PQC) Support documentation.

The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.

Harvest now, decrypt later: FAQ

What is a harvest now, decrypt later (HNDL) attack?

An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.

Is Imperva Cloud WAF traffic protected against harvest now, decrypt later?

Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.

What is X25519MLKEM768?

It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.

What happens if a client or origin doesn’t support post-quantum TLS?

The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.

The post Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing appeared first on Blog.