Topic starter
02/08/2026 11:47 am
TL;DR: April 2026 brought critical SQL injection CVEs in Kestra, OpenProject, and PraisonAI, while JSON payloads, second-order injection, and ORM escape hatches bypassed WAFs from Palo Alto, AWS, Cloudflare, F5, and Imperva, according to Gecko Security. The practical lesson is that signature-based detection and parameterized-by-default frameworks still fail when query logic, validation, and authorisation split across services.
Editorial analysis by NHI Mgmt Group, based on content published by Gecko Security: “SQLi CVE Database: Complete List of SQL Injection Vulnerabilities April 2026”.
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.
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.
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.
Practitioner guidance
- Map raw-query escape hatches Inventory every use of whereRaw(), $queryRaw, query(), custom filter objects, and equivalent low-level query builders across your applications.
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:57 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: April 2026 SQLi CVEs expose where WAFs and ORMs fail