April 2026 SQLi CVEs expose where WAFs and ORMs fail

At a glance

What this is: Gecko Security maps three April 2026 SQLi CVEs to a common failure pattern: detection and ORM safeguards break when payloads move through JSON, raw query paths, and second-order sinks.

Why it matters: IAM and security teams should treat SQLi here as a control-design problem, because authentication boundaries, authorisation checks, and data-flow validation can collapse when application layers disagree about trust.

By the numbers:

• Three SQL injection CVEs were highlighted in April 2026 across Kestra, OpenProject, and PraisonAI.

Context

SQL injection is a control failure, not just a coding bug. It appears when application input is trusted at the wrong layer, then survives into database execution through raw queries, second-order sinks, or validation that happens before the real risk point. In this article's context, the concern is broader than AppSec because broken query boundaries often sit beside authentication and authorisation logic that identity teams also rely on.

April 2026 matters because the article ties active exploitation to multiple products and to bypass patterns that evade signature-based controls. For IAM and NHI programmes, the lesson is that trust decisions embedded in application flows can be as fragile as credential controls when execution paths are not traced end to end.

Key questions

Q: What breaks when SQL injection controls only inspect the first request layer?

A: Controls fail when they validate a request before the application reinterprets the same data later in a different layer, such as a database query, stored field, or service-to-service handoff. The dangerous part is not always the incoming string. It is the later execution context that turns apparently clean input into SQL logic.

Q: Why do JSON payloads still bypass WAFs in SQL injection attacks?

A: JSON payloads bypass WAFs when the detector understands classic SQL syntax but not how the backend actually parses structured request bodies. If the rule set only looks for obvious keyword patterns, attackers can hide the same intent inside valid JSON, encoding tricks, or mixed formatting that still executes downstream.

Q: Where do ORM protections fail in real applications?

A: ORM protections fail at the boundaries where developers leave the safe abstraction and use raw query methods, custom filters, or unreviewed dynamic conditions. Those paths often bypass parameterisation and bring back injection risk even when the framework defaults are sound for ordinary queries.

Q: How should teams respond when second-order SQL injection is suspected?

A: Teams should trace stored inputs through every later read and transformation step, then review the database permissions that make the delayed payload damaging. The priority is to locate where clean data becomes executable logic and to contain the affected query paths before the same value is reused again.

Technical breakdown

Why JSON payloads defeat signature-based WAF detection

WAFs mostly work by matching known patterns, not by understanding intent. When SQL syntax is embedded inside JSON or altered with mixed case, comments, encoding, or whitespace tricks, the payload can remain valid to the backend while looking harmless to a rule engine. That is why rules tuned to classic query strings miss payloads that arrive through APIs and microservices. The core limitation is not that WAFs are useless, but that they are lexical controls. They inspect what the request looks like, not whether the application later interprets the data as executable SQL.

Practical implication: Treat WAFs as a narrow detection layer and validate whether JSON bodies and alternate encodings are actually parsed by your controls.

How second-order SQL injection escapes the entry point

Second-order SQL injection stores payloads safely at the moment of submission and triggers them later when another query consumes the stored value. That means input validation can pass, logging can look clean, and the dangerous behaviour only appears on read or transform, often in a different service. This breaks a common security assumption: that the point of entry is also the point of risk. In distributed systems, the control gap is usually between ingestion and use, not between attacker and application form field.

Practical implication: Trace where stored data is later reused in queries, especially across services, instead of only testing the initial submission path.

Why ORM escape hatches reintroduce injection risk

ORMs reduce risk when developers stay on the safe path, but most frameworks expose raw-query methods for edge cases, performance tuning, or complex filters. Those escape hatches often bypass parameterisation and let user-controlled values re-enter SQL construction as logic rather than data. The result is a false sense of safety: the framework appears secure in general, but the application becomes vulnerable the moment a developer reaches for a low-level query primitive. This is a governance issue as much as a code issue because the organisation must know where the safe defaults end.

Practical implication: Inventory every raw-query or custom-filter path and subject it to the same review as hand-written SQL.

Threat narrative

Attacker objective: The attacker wants to turn trusted application flows into database access, data disclosure, or execution in the application's security context.

1. Entry occurs through authenticated endpoints, unauthenticated APIs, or stored inputs that later feed database queries.
2. Credential or validation controls fail when the payload survives input handling and reaches raw SQL execution or a second-order sink.
3. Escalation happens when the database account or application context can read, modify, or execute beyond the intended scope.
4. Impact is database compromise, data exposure, or in some cases remote code execution through database privileges.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SQLi bypass is now a trust-layer problem, not just an input-validation problem. The article shows that attackers are moving around controls that only inspect a single boundary at a time, especially when authentication, request parsing, and query execution are split across services. That means the real failure mode is fractured trust, where one layer assumes another has already enforced safety. Practitioners should treat control handoff as the attack surface.

ORM convenience creates a governance gap when raw-query paths are invisible to assurance. Parameterised-by-default frameworks reduce risk only until teams use escape hatches like raw SQL methods or custom filter objects. At that point, the organisation no longer has a consistent query-safety model, and review standards usually lag behind implementation reality. Practitioners should map where framework safety stops and where manual review must begin.

Second-order SQL injection exposes a data-flow blind spot that WAFs and SAST often miss. The dangerous payload may arrive clean, persist cleanly, and become malicious only when reused later. That is a strong example of why semantic analysis matters in modern application governance, including where application data feeds identity decisions or privileged automation. Practitioners should trace trust across the full lifecycle of the data, not just at ingress.

Authentication checks do not matter if the query path can be rewritten after the check. The article's bypass patterns show how a request can cross a valid login boundary and still become malicious in the database layer. This is especially relevant to programmes that assume authenticated sessions are the primary trust anchor. Practitioners should align security review to execution context, not just login state.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: IAM and Identity Provider Buyer's Guide

What this signals

Second-order execution changes the defensive model: security teams cannot rely on the request that entered the system, because the harmful behaviour may appear only when a later service consumes the stored value. That makes data-flow tracing and query-path review more important than single-request inspection.

SQLi now tests programme architecture as much as application hygiene: when authentication, parsing, and database execution are split, the assurance model has to follow the full path from ingress to query execution. Identity teams should pay attention wherever application context can influence privileged data access.

WAF coverage is only as strong as its understanding of modern payload structure: JSON bodies, encoding variants, and alternate whitespace can all leave pattern-based tooling blind unless the underlying parser view is aligned with the application view.

For practitioners

• Map raw-query escape hatches Inventory every use of whereRaw(), $queryRaw, query(), custom filter objects, and equivalent low-level query builders across your applications. Require explicit security review wherever developers can move from parameterised access to manually assembled SQL.
• Test JSON and encoded payload handling Run application security tests against JSON bodies, mixed-case keywords, encoded quotes, comment-delimited keywords, and whitespace substitutions to confirm that controls inspect the actual data path, not only textbook SQL strings.
• Trace second-order sinks end to end Follow stored values from ingestion through later read, transform, and reporting steps to find where clean input becomes executable SQL in another service or component.
• Review database privilege scope Check whether application database accounts can do more than the specific workload requires, because SQLi impact expands quickly when query access and privileged database actions are combined.
• Use semantic application analysis for bypass paths Add code-path and data-flow analysis that can see across microservices and helper functions, because pattern matching alone will miss second-order injection and control gaps after authentication.

Key takeaways

• The article's central risk is not only SQL injection itself but the way modern request handling lets malicious input survive past the first control boundary.
• The evidence points to bypasses in JSON payload handling, second-order execution, and ORM escape hatches, which are exactly the places where superficial checks miss the attack.
• Teams need execution-path analysis, tighter raw-query governance, and database privilege review if they want to catch the class of failures described here.

Key terms

• Second-order SQL injection: Second-order SQL injection is when a malicious payload is stored safely at first, then executes later when another query reuses the value. The flaw appears at the reuse point, not the entry point, which makes it harder to detect with request-time filters and ordinary signature-based scanning.
• WAF bypass: A WAF bypass is a request variation that slips past a web application firewall rule while still reaching the vulnerable application logic. It matters because fast defensive rules often target known proof-of-concept patterns, not every encoding, parameter, or legacy behaviour attackers can use.
• Raw query escape hatch: A raw query escape hatch is an ORM or framework method that lets developers bypass parameterised defaults and write custom SQL directly. These methods are useful for complex logic, but they also reintroduce injection risk if user-controlled data reaches the query string without strict handling.
• Semantic Analysis: Semantic analysis is the process of understanding how code behaves in context rather than only matching known patterns. In security review, it helps surface logic flaws, trust-boundary issues, and access problems that signature-based tools often miss.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need a stronger access-control baseline. It helps identity and security teams connect governance decisions to the broader security programme they operate.