Notifications
Clear all
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.
NHIMG editorial — based on content published by Gecko Security: April 2026 SQL injection CVEs, WAF bypasses, and ORM escape hatches
By the numbers:
Questions worth separating out
Q: What breaks when SQL injection reaches authentication flows?
A: Authentication breaks when the application treats a database response as proof of identity rather than one step in the verification chain.
Q: Why do WAFs miss some modern SQL injection attacks?
A: WAFs miss them when they rely on signatures that do not understand the request format the application actually uses.
Q: How do teams know whether ORM defaults are really protecting them?
A: Teams know by testing the full execution path, not by assuming parameterisation covers every case.
Practitioner guidance
- Review authentication queries for bypass paths Inspect every login, reset, and token validation query for always-true logic, comment truncation, and error handling that can return success without proving identity.
- Validate WAF coverage against structured payloads Test the WAF with the exact JSON, encoding, and nested parameter formats your APIs accept, then confirm whether it parses request bodies the same way the application does.
- Eliminate raw query escape hatches where possible Inventory whereRaw(), $queryRaw, query(), and similar methods in your codebase, then require justification and review for every use.
What's in the full article
Gecko Security's full article covers the operational detail this post intentionally leaves for the source:
- Reproduction details for each April 2026 CVE, including the exact request patterns and affected endpoints.
- WAF bypass examples showing how JSON, encoding, and comment-based payloads evade signature rules.
- ORM-specific sink patterns such as raw query methods, nested filters, and second-order execution paths.
- Semantic analysis guidance for tracing data across microservices and database calls.
👉 Read Gecko Security's analysis of the April 2026 SQL injection CVEs and WAF bypasses →
April 2026 SQLi CVEs: where are your detection controls failing?
Explore further
02/08/2026 12:57 pm
SQL injection in 2026 is increasingly an identity-adjacent governance failure, not just an input-validation defect. When attacks succeed through authentication flows, management APIs, or database-backed control planes, the result is often unauthorised access to systems that define who can do what. That pushes the problem into IAM, PAM, and application governance territory, where query trust becomes access trust. Practitioners should treat login and authorisation paths as part of the identity attack surface.
A few things that frame the scale:
- At least one is already seeing active exploitation in the wild, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
A question worth separating out:
Q: Which controls matter most for second-order SQL injection and delayed execution?
A: The most important controls are end-to-end data flow tracing, strict validation at reuse points, and monitoring for stored values that later become query syntax. Second-order SQLi succeeds because the payload looks safe when entered and malicious only when reused, so point-in-time scanning is not enough.
👉 Read our full editorial: April 2026 SQLi CVEs expose where WAFs and ORMs fail
