SQLi CVE Database: Complete List of SQL Injection Vulnerabilities April 2026

Three new SQLi CVEs dropped in April 2026, and at least one is already seeing active exploitation in the wild. If you're trying to understand whether your code has similar SQLi CVE bypass risks, the pattern is pretty clear: attackers are targeting authentication flows where input validation happens at the wrong layer, ORM raw query methods that developers assume are safe, and second-order injection points that never get flagged by signature-based tools. We're covering what makes CVE-2026-34612, CVE-2026-34717, and CVE-2026-34934 worth immediate attention and what detection gaps let them through in the first place.

TLDR:

• SQL injection CVEs in April 2026 include three critical flaws: Kestra (CVE-2026-34612), OpenProject (CVE-2026-34717), and PraisonAI (CVE-2026-34934)
• JSON-based payloads bypass major WAFs from Palo Alto, AWS, Cloudflare, F5, and Imperva by evading signature-based detection
• Second-order SQLi stores clean payloads that execute later, bypassing input validation and WAF rules entirely
• ORM escape hatches like whereRaw() and $queryRaw reintroduce injection risks despite parameterized query defaults
• Gecko Security finds SQL injection bypasses through semantic analysis that traces data across microservices and missing authorization checks

Understanding SQL Injection CVE Classifications and Severity Scoring

CVE identifiers are the universal naming system for disclosed vulnerabilities. Each follows the format CVE-[year]-[ID], giving security teams a shared reference point across tools, advisories, and patch notes. For SQL injection, the CVE record tells you what software is affected, how the flaw works, and how severe it actually is.

That severity comes from CVSS, the Common Vulnerability Scoring System. Scores run from 0 to 10, with categories that matter in practice:

• Critical (9.0 to 10.0): Remote, unauthenticated exploitation with full system impact
• High (7.0 to 8.9): Often requires some access, but still severe
• Medium (4.0 to 6.9): Limited scope or harder to exploit
• Low (below 4.0): Rarely exploitable without unusual conditions

SQLi CVEs frequently land in the Critical or High range because SQL injection often requires no authentication and can expose entire databases. When assessing bypass risk, look beyond the score itself. Check the attack vector (network vs. local), whether authentication is required, and what the scope impact is. A CVSS 8.1 with network access and no privileges needed is far more urgent than a 9.0 requiring local access.

Critical SQL Injection CVEs from April 2026

Three SQLi CVEs worth flagging from April 2026, each with distinct exploitation profiles and affected systems.

CVE-2026-34612 (Kestra)

Kestra, the open-source orchestration engine, shipped with an authenticated SQL injection flaw allowing remote code execution. Authenticated attackers could manipulate query parameters to execute arbitrary SQL and escalate to RCE, similar to the DB-GPT SQLI via CVE bypass. CVSS scored this at 8.8. Full details on the Kestra RCE via SQL injection.

CVE-2026-34717 (OpenProject)

OpenProject's project management API exposed a critical SQLi vector requiring no authentication. Network-accessible, unauthenticated exploitation puts this firmly in the Critical tier, much like the ONYX authorization bypass in group management. See the OpenProject SQL injection breakdown for reproduction steps.

CVE-2026-34934 (PraisonAI)

PraisonAI, an AI agent framework, carried an injection flaw in its data handling layer. Given how many teams are running agentic workflows against production databases, this one deserves attention even without public exploit code yet.

Authentication Bypass Through SQL Injection Techniques

Authentication bypass through SQLi is one of the oldest tricks in the book, and it still works. The core idea: if a login query returns true regardless of what credentials you supply, you're in.

The classic form looks like this:

' OR '1'='1

Injected into a username field, it turns a query like WHERE username = '' AND password = '' into one that always returns true. No credentials needed.

Comment injection takes a similar approach, truncating the query entirely:

admin'--

Everything after -- gets ignored. The password check never runs.

A few bypass patterns that still appear in CVE write-ups:

• Always-true conditions like ' OR 1=1-- collapse authentication logic by forcing the WHERE clause to resolve true for every row in the table.
• Null byte injection terminates string parsing early, causing some validation layers to treat truncated input as clean.
• Type coercion abuse exploits loose comparisons in certain database drivers, producing unexpected evaluation results without any traditional injection syntax.
• Stacked query injection via semicolons allows a second statement to execute on permissive drivers, often inserting a rogue admin session directly.

What makes these sqli cve bypass cases especially dangerous is the attack vector score. No valid session, no prior knowledge of usernames, often no logging of the failed attempt. CVSS confidentiality and integrity scores go straight to High because the attacker lands directly in an authenticated context.

WAF Bypass Methods for SQL Injection Attacks

WAFs block SQL injection by matching known patterns. The problem is that pattern matching has gaps, and attackers know exactly where those gaps are.

JSON-based SQL injection is one of the more effective evasion methods right now. Major WAF vendors including Palo Alto Networks, AWS, Cloudflare, F5, and Imperva historically did not support JSON syntax in their rule sets, meaning attackers could prepend JSON to SQL syntax and slip past detection entirely. The payload looks unusual enough to avoid signature matches while still executing cleanly against the database. This technique is documented thoroughly in research on WAF bypass via JSON injection, showing exactly why static analysis struggles with business logic.

Beyond JSON, a handful of encoding and obfuscation tricks remain effective against signature-based WAFs:

• Inline comments like SE/**/LECT break up keyword strings that WAF rules scan for literally
• Mixed case variations (SeLeCt, uNiOn) defeat case-sensitive pattern matchers
• URL encoding and double encoding (%27 for a single quote, %2527 for the double-encoded version) turn payloads into sequences WAFs don't flag
• Whitespace substitution using tabs, newlines, or carriage returns in place of spaces evades rules that expect standard formatting

WAFs are reactive by design. They block what they've seen before. A novel encoding combination or syntax variant that wasn't in last month's rule update goes straight through.

Second-Order and Blind SQL Injection Exploitation

Not all SQL injection produces immediate output. Blind and second-order techniques extract data without direct feedback, which is exactly why they evade detection tools built around observable injection signatures.

Blind SQLi comes in two forms. Boolean-based blind injection sends queries that produce different application responses depending on whether a condition is true or false. Time-based blind injection uses database delay functions like SLEEP() or WAITFOR DELAY to signal true/false results through response timing alone. No error messages, no returned data. Just silence or latency.

Second-order injection is the subtler threat. A payload gets stored in the database at insertion time, where it looks clean. It only executes later, when another query retrieves and processes that stored value. Input validation at the entry point passes cleanly. The injection fires on the way out.

"The attack surface isn't where data enters. It's where data gets used."

These techniques bypass WAFs and input filters precisely because the dangerous payload never hits the wire in recognizable form. Time-based extraction especially evades signature matching since no SQL keywords appear in the response. Detection requires behavioral analysis across requests, not pattern matching on a single payload.

CVE-2026-21643: Active Exploitation in FortiClient EMS

CVE-2026-21643 is a SQL injection vulnerability in Fortinet FortiClient EMS with active exploitation already confirmed, despite not appearing on CISA's Known Exploited Vulnerabilities catalog. According to Defused Cyber's data, first exploitation occurred just four days before reporting, meaning defenders had almost no window to act.

FortiClient EMS manages endpoint security deployments across enterprise environments. A SQLi flaw here means attackers can query or manipulate the management database, potentially exposing device configurations, credentials, and enrolled endpoints across an entire organization.

The gap between active exploitation and CISA KEV listing is the real warning. Patch immediately and don't wait for a government catalog to tell you something is being hit.

Why SQL Injection Persists in 2026

SQLi has been on the OWASP Top 10 since its inception. Yet new CVEs keep arriving every month. The reason isn't ignorance. It's the gap between what developers write and what security tools catch.

Three forces keep SQLi alive in 2026. Legacy codebases predate parameterized queries as a default. Rapid shipping cycles skip security review. And AI-generated code introduces injection flaws at scale. Research shows only 10% of AI-generated features meet security standards, and engineers using AI tend to trust the output without auditing it.

Pattern-based scanners catch the obvious cases. Raw string concatenation in a query is easy to flag. What they miss are runtime query builders, framework misuse, ORM raw-query escapes, and second-order sinks where the payload arrives clean but executes dangerous. This is precisely why business logic is AppSec's unsolved problem. Those gaps don't show up in rule sets. They require understanding how data moves through an application, beyond what the query looks like at one point in time.

ORM-Specific SQL Injection Vulnerabilities

ORMs give developers a false sense of safety. Parameterized queries are the default, so the assumption is that SQL injection simply can't happen. That assumption breaks down at the edges.

Most ORMs expose raw query escape hatches for performance or complex filtering. When developers reach for those, they often reintroduce the same concatenation patterns that parameterized queries were meant to eliminate, as seen in the DB-GPT RCE in plugin upload system. MikroORM had a documented case where crafted objects carrying specific internal marker properties bypassed sanitization entirely, with the ORM treating attacker-controlled input as trusted query structure instead of data.

A few patterns that surface repeatedly in ORM-based CVEs:

• Raw query methods like query(), whereRaw(), or $queryRaw called with unsanitized user input
• Object prototype pollution that manipulates how the ORM constructs its WHERE clause
• Batch operations that process arrays without per-element validation
• Nested filter objects where attacker-controlled keys map to query operators

The underlying issue is that ORMs protect the happy path. Developers who go off-script, whether for flexibility or speed, step outside that protection without realizing it.

How AI-Powered SAST Tools Detect Business Logic SQLi Bypasses

Pattern-based SAST flags concatenated strings inside query calls. That catches the obvious cases. What it cannot do is follow a query through three service boundaries and ask whether any authorization check existed along the way.

That's where semantic analysis changes the outcome. Instead of matching syntax, it builds a call graph that traces how data moves from an HTTP parameter into a database call, across microservices, through helper functions, and into raw query methods. When a SQLi bypass exists in a second-order sink or inside an ORM escape hatch that lives far from the entry point, the semantic model still connects them.

AI-powered SAST applies this reasoning to whether security controls are actually enforced, beyond syntactic presence alone. A query may pass through an authentication layer that looks correct in isolation. If the user context gets dropped before reaching the data service, that control is decorative. Traditional SAST never sees the gap, which is exactly Gecko's 30 0-day vulnerabilities discovery. Semantic analysis built on accurate call chains does.

Final Thoughts on SQL Injection CVEs and Bypass Methods

The reason SQLi CVE bypass techniques keep working is simple: defenses are reactive and developers trust frameworks too much. WAFs block last month's payloads, ORMs protect until you call whereRaw(), and AI-generated code ships injection flaws at scale without anyone auditing the output. Semantic SAST changes the equation by tracing how data moves through your application, across services, into database calls, asking whether security controls actually fire instead of merely existing. Grab 30 minutes if you want to see what that looks like on a real call graph.

FAQ

What makes a SQL injection CVE Critical versus High severity?

Critical SQLi CVEs (CVSS 9.0-10.0) allow remote, unauthenticated exploitation with full database access, meaning attackers can execute the attack over the network without any credentials. High severity (7.0-8.9) vulnerabilities typically require some prior access or have slightly limited scope, but both categories demand immediate patching.

How do WAFs miss JSON-based SQL injection attacks?

WAFs block SQL injection by pattern matching against known syntax. JSON-based SQLi wraps SQL payloads inside JSON structures that major vendors like Cloudflare, AWS WAF, and F5 historically didn't parse in their rule sets, letting the attack slip through signature detection while still executing cleanly against the backend database.

Why do ORMs still have SQL injection vulnerabilities?

ORMs protect standard queries through parameterization, but developers frequently use raw query escape hatches like whereRaw() or $queryRaw for complex filters or performance optimization. These methods bypass ORM protections entirely, reintroducing the same string concatenation risks that parameterized queries were designed to prevent.

What is second-order SQL injection and why is it harder to detect?

Second-order SQLi occurs when a malicious payload is stored safely in the database during insertion but executes later when another query retrieves and processes that stored value. Pattern-based scanners miss this because the dangerous payload never appears in a recognizable form at the entry point where input validation occurs.

How can I detect SQLi vulnerabilities that traditional SAST tools miss?

Traditional SAST flags obvious concatenation patterns but can't trace queries across service boundaries or validate whether authorization checks exist along the execution path. Semantic analysis tools that build complete call graphs can follow data from HTTP parameters through multiple microservices to identify second-order sinks and missing security controls that isolated pattern matching cannot see.