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.
At a glance
What this is: SQL injection remains an active application security problem, with Aikido highlighting a WordPress emergency patch and persistent advisory growth across recent years.
Why it matters: IAM, appsec and platform teams need to treat SQLi as a control failure across code, runtime and automation, because safe defaults do not reliably stop exploitation.
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.
- WordPress core still runs on more than 500 million sites, according to Searchlight Cyber cited by Aikido.
Context
SQL injection is a code-to-data boundary failure. It happens when untrusted input is treated as part of a query instead of data, which lets an attacker change what the database executes. In modern environments, the problem persists because teams rely on safe defaults, frameworks, and scanners that do not cover every execution path or legacy corner.
The article shows why appsec cannot treat SQLi as a solved issue. The identity intersection is indirect but real: once injection turns into remote code execution, the attacker is no longer just manipulating data but taking control of application behaviour and any service identity the application can reach.
That makes SQLi a governance problem as much as a coding problem. The article's examples are typical, not exceptional, because parameterisation is well understood but not uniformly applied across codebases, dependencies, AI-generated code, and runtime layers.
Key questions
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. Attackers can bypass authentication, enumerate data, modify records, or trigger downstream access through the service account behind the app. The real failure is not only data exposure but the overreach of the database identity that the application uses.
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. Risk remains when developers use raw queries, when dependencies contain unsafe query handling, or when the database result drives more than data retrieval. In those cases, a single missed call site can become a high-impact execution path.
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. Applications that fail basic validation, accept unsanitized input in search or login fields, or return detailed SQL messages deserve immediate review. Manual fuzzing and automated scanners can confirm whether those signals point to a real flaw.
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.
Technical breakdown
Why parameterised queries fail in real codebases
Prepared statements and parameterised queries separate code from data, which is why they stop classic SQL injection. In practice, teams still drop to raw queries, rely on helper methods that are not truly safe, or pass untrusted values into query fragments such as field names, sort clauses, or JSON paths. The result is that the protection exists in principle but disappears in specific call sites. ORM defaults reduce risk, but they do not override unsafe escape hatches, legacy patterns, or framework bugs. Practical implication: review the places where your code leaves the safe abstraction layer, not just the framework configuration.
Practical implication: inventory raw-query paths and unsafe helper methods, then treat them as the highest-priority SQLi exposure points.
How SQL injection becomes remote code execution
SQL injection is not only a database integrity issue. When an application uses the database result to drive file access, command execution, deserialisation, or internal bookkeeping, a query flaw can become a code execution path. That is why some SQLi findings are operationally severe even when the original weakness looks like input handling. The WordPress case in the article shows a chain where malformed input disturbed internal state and enabled unauthenticated remote code execution through the core. Practical implication: assess the downstream consequences of each query sink, especially where database output influences privileged application logic.
Practical implication: map each query sink to the downstream action it controls, and prioritise sinks that can reach code execution or privileged state changes.
Why runtime backstops matter when prevention is incomplete
Static analysis and secure coding standards are necessary, but they do not catch every logic-dependent or dependency-introduced injection path. Runtime controls such as RASP or in-app firewalls inspect behaviour as input moves toward a database or file sink, which gives them a chance to block exploit payloads even when the code path escaped review. This is especially relevant when a vulnerable dependency, a platform default, or an emergency patch window leaves exposure open. Practical implication: pair code review with runtime enforcement so that one missed injection does not become an incident.
Practical implication: deploy runtime blocking at the application layer for high-value services that cannot rely on perfect pre-production detection.
Threat narrative
Attacker objective: The objective is to turn SQL injection into unauthenticated remote code execution on the target application.
- Entry occurs when an anonymous attacker sends crafted input that reaches a vulnerable SQL query on a stock installation.
- The payload abuses query handling to disrupt internal state and turn input control into application control.
- The attacker leverages that control to reach unauthenticated remote code execution on the target system.
- Impact is full compromise of the affected application instance, with the patching window becoming the exposure window.
Breaches seen in the wild
- SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
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
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.
The most important failure mode is trust in abstractions that can be bypassed. ORMs, scanners, and WAFs all reduce risk, but none of them guarantees safety when code drops into raw queries, unsafe helper methods, or dependency-driven edge cases. This is the same pattern we see in broader identity and access governance: a default control only matters if it still holds at the point of enforcement. Practitioners should look for the places where the abstraction boundary breaks.
Runtime backstops are becoming part of baseline appsec governance. The article makes a strong case that prevention alone will never be complete, especially with AI-generated code and legacy systems in the mix. That creates a named control gap we can call safe-default drift: the distance between what teams believe the framework protects and what the application actually executes. Practitioners should close that gap with runtime enforcement and tighter query-sink review.
AI-written code raises the volume of familiar failures, not just novel ones. If models reproduce old patterns at roughly the same rate as human developers, then SQL injection becomes an AI governance issue as well as an application security one. That matters for code provenance, review depth, and accountability for generated output. Practitioners should assume that AI assistance increases the need for verification rather than reducing it.
Large platforms make SQLi a supply-chain and resilience problem. When a core platform like WordPress needs an emergency patch, the operational question changes from 'is the bug known?' to 'how fast can every downstream deployment absorb the fix?' That is a governance problem for patch orchestration, change control, and runtime containment. Practitioners should plan for exposure windows, not just vulnerability disclosure.
What this signals
Safe-default drift is the gap between what teams believe their framework protects and what their code actually executes. That gap matters because SQL injection usually survives at the edges of abstractions, not in the obvious examples that training material covers.
Runtime containment is becoming a baseline requirement for application security programmes that cannot guarantee perfect code hygiene. The practical lesson for practitioners is to govern query safety as a layered control problem, with review, static analysis and in-app blocking working together.
AI-assisted development increases the need for verification because it scales familiar defects as well as good patterns. Security teams should expect more code to arrive with plausible but unsafe data-handling logic, which makes query-sink review and runtime enforcement more important, not less.
For practitioners
- 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.
- Test AI-generated code for injection patterns Run generated code through security review that explicitly checks for SQLi, unsafe string concatenation and bypasses of parameterised statements.
- Track patch exposure windows for core platforms Treat emergency fixes as time-bound exposure events and verify that forced or accelerated update paths exist for internet-facing systems.
Key takeaways
- SQL injection remains a live application security problem because safe defaults do not consistently survive raw queries, unsafe helper methods and legacy code paths.
- The WordPress emergency patch shows how an input-handling flaw can become an unauthenticated remote code execution issue when internal application state is affected.
- Teams reduce exposure by treating query sinks as governed control points and by adding runtime backstops where prevention cannot be proven complete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centres on unsafe query handling and broken defaults in application-layer access paths. |
| Recommendation — Review API and application query paths for unsafe defaults and remove string-built database access. | ||
| OWASP ASVS | V4 — API and Web Service | SQL injection here arises through application and service data access, which ASVS tests directly. |
| Recommendation — Apply ASVS query-handling requirements to verify parameterisation and reject unsafe data-to-query joins. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue is fundamentally untrusted input influencing executable query structure. |
| Recommendation — Enforce SI-10 controls so untrusted input cannot alter query logic or privileged application behaviour. | ||
| MITRE ATT&CK | TA0006;TA0004;TA0040 — Credential Access; Privilege Escalation; Impact | SQL injection commonly enables escalation from input abuse to system impact. |
| Recommendation — Map SQLi detections to TA0006, TA0004 and TA0040 to prioritise high-impact query sinks. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about preventing and detecting insecure application behaviour in production code. |
| Recommendation — Use CIS-16 to govern secure coding, testing and runtime control for injection-prone applications. | ||
Key terms
- SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
- Parameterized Query: A parameterized query separates SQL code from user-supplied values so the database can bind data without treating it as executable logic. This is the primary technical control that prevents input from changing query structure in vulnerable application paths.
- Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
- Secure-Default Drift: Secure-default drift is the gap that appears when a framework’s built-in protections are undermined by custom code, configuration changes, or operational shortcuts. The application still looks protected on paper, but its real behavior no longer matches the intended security model.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity governance with broader security decisions, not just individual vulnerabilities.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org