Topic starter
01/08/2026 10:44 pm
TL;DR: Safe defaults, legacy code and AI-generated code still let SQL Injection survive in modern apps, according to Aikido. Query paths need governance and runtime backstops when prevention cannot be proven complete.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “SQL injection isn't dead”.
By the numbers:
- WordPress shipped an emergency release on July 17 to fix an unauthenticated remote code execution flaw reachable through SQL injection.
- GitHub Advisory Database counts for SQL injection rose from 2,096 in 2023 to 2,850 in 2025.
- SQL injection, command injection and path traversal together made up 13.5% of reports in 2023 and 10.9% in 2025.
Key questions
Q: Why does SQL injection still create serious risk even when parameterised queries are available?
A: Parameterised queries only protect the code paths that actually use them.
Q: What are the signs that an application may be vulnerable to SQL injection?
A: Common warning signs include user input affecting query results, unexpected authentication bypasses, verbose database errors, and responses that change when special characters are tested.
Q: What breaks when SQL injection is not blocked at the application layer?
A: When SQL injection is not blocked, the application boundary between user input and database instructions collapses.
Practitioner guidance
- Audit raw-query escape hatches Identify every code path that bypasses ORM parameterisation, including raw SQL, unsafe helper methods, dynamic field names and JSON-path accessors.
- Map query sinks to impact Classify each database interaction by what it can trigger downstream, especially state changes, file access, command execution and privilege-bearing logic.
- Add runtime blocking on critical services Use application-layer runtime controls to stop exploit payloads at execution time where static scanning and code review cannot prove safety.
Bottom line: SQL injection remains a live application security problem because safe defaults do not consistently survive raw queries, unsafe helper methods and legacy code paths.
Glossary terms: SQL Injection, Parameterized Query, Runtime Application Self-Protection, Secure-Default Drift
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 8 hours ago by NHI Mgmt Group
01/08/2026 10:53 pm
SQL injection is now a governance failure, not just a coding bug. The article shows that the fix has existed for more than 25 years, yet teams still leave exploitable paths in production because safe defaults are unevenly applied. That means the real issue is control consistency across frameworks, legacy code, and runtime layers. Practitioners should treat SQLi reduction as an assurance programme, not a one-time remediation exercise.
A question worth separating out:
Q: When should teams rely on runtime blocking instead of prevention alone?
A: Teams should add runtime blocking whenever they cannot prove that every query path is parameterised, every dependency is safe, and every legacy branch is covered by review. Runtime controls are the right backstop for high-value systems because they can stop a payload even after code review has missed it.
👉 Read our full editorial: SQL injection still breaks modern appsec because safe defaults fail