Notifications
Clear all
Topic starter
01/08/2026 10:44 pm
TL;DR: SQL injection remained a live application risk in 2026, with WordPress forcing an emergency core patch for an unauthenticated RCE path and GitHub Advisory Database counts rising from 2,096 to 2,850 across full years from 2023 to 2025, according to Aikido and GitHub Advisory Database reporting. The real failure is not that the fix is unknown, but that safe defaults, legacy code, AI-generated code, and runtime gaps still let old injection patterns survive.
NHIMG editorial — based on content published by Aikido: SQL injection isn't dead
By the numbers:
- The count of SQL injection advisories rose every full year from 2023 to 2025, from 2,096 to 2,850.
- In Mackenzie's scans of closed-source repos, 20% of projects had at least one SQL injection flaw on their first scan.
Questions worth separating out
Q: What breaks when SQL injection and local file inclusion are not controlled?
A: Application input becomes attacker-controlled logic.
Q: Why does SQL injection still appear in modern applications?
A: SQL injection persists because the fix is well known but not universally applied across legacy code, dependency code, and developer shortcuts.
Q: How do security teams know whether SQL injection protections are actually working?
A: Teams should test whether user input is ever interpreted as query logic and whether database accounts are confined to their intended scope.
Practitioner guidance
- Harden every raw-query escape hatch Inventory every place developers can bypass ORM parameterisation, including raw SQL, field-name interpolation, and helper methods that build queries dynamically.
- Add runtime blocking for exploitable payloads Deploy application-layer runtime controls that inspect context before payloads reach query sinks, so a missed injection does not become a production incident.
- Treat AI-generated code as untrusted input Require secure coding review, injection testing, and automated policy checks for code written or modified by AI assistants.
What's in the full article
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- The specific WordPress core flaw and patching context that made the emergency release necessary.
- Aikido Zen's in-app blocking approach for payloads moving toward query and file-read sinks.
- The scan findings and AI pentest workflow used to identify harder-to-spot SQL injection paths.
- The WAF versus RASP comparison and why runtime context changes false-positive behaviour.
👉 Read Aikido's analysis of why SQL injection still breaks modern apps →
SQL injection is still breaking apps. What are teams missing?
Explore further
01/08/2026 10:53 pm
SQL injection is no longer a solved problem, it is a governance problem. The article shows that the technical fix has existed for decades, yet organisations still ship vulnerable query paths because code review, developer habits, and runtime oversight do not fully close the loop. That shifts responsibility from pure remediation into continuous control assurance. For practitioners, the lesson is that the existence of a known fix does not mean the organisation has operationalised it.
A question worth separating out:
Q: Who is accountable when SQL injection exposes secrets or privileged access?
A: Accountability sits across application owners, security engineering, and platform teams because the weakness is both a coding issue and a control-design issue. If the flaw can expose service accounts, tokens, or administrative data, identity and access teams must join the response, because the incident has crossed from app security into access governance.
👉 Read our full editorial: SQL injection still breaks modern appsec because safe defaults fail
