SQL injection still breaks modern appsec because safe defaults fail

At a glance

What this is: This is an analysis of why SQL injection persists in modern applications, even when parameterised queries and framework defaults exist.

Why it matters: It matters because IAM-adjacent application security teams still need to govern trust boundaries, runtime protection, and developer behaviour where code can turn user input into privileged data access.

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.

👉 Read Aikido's analysis of why SQL injection still breaks modern apps

Context

SQL injection persists because application security is still weakened by assumptions that a framework default or one-time remediation has solved the problem. In practice, any path that turns user-controlled input into query structure can become a direct route to data access, privilege abuse, or remote code execution. For IAM and NHI programmes, the relevance is that application-layer trust decisions often determine which identities, tokens, or backend services become reachable once the injection lands.

The WordPress emergency patch is a reminder that old vulnerability classes remain operationally dangerous when they intersect with scale, legacy code, and incomplete coverage. This is not an unusual edge case, but a familiar pattern: security controls exist, yet unsafe paths still survive in application logic, dependencies, and developer workflows. The same gap affects service accounts and other non-human identities when application flaws expose secrets, backend credentials, or privileged interfaces.

Key questions

Q: What breaks when SQL injection and local file inclusion are not controlled?

A: Application input becomes attacker-controlled logic. SQL injection can expose or modify database content, while local file inclusion can reveal files or execute unintended code paths. In ecommerce, that can mean customer record exposure, session theft, administrative compromise, or a path into other systems that trust the application.

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. Framework defaults help, but they fail when teams drop to raw SQL or trust methods that still pass user-controlled values into query structure. AI-generated code can also reproduce the same mistake at scale.

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. Good signals include consistent parameter binding, no dynamic SQL in sensitive paths, low error disclosure, and alerts for unusual query timing or outbound callbacks. If those signals drift, the protection is failing.

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.

Technical breakdown

How SQL injection still bypasses safe framework defaults

SQL injection occurs when attacker-controlled input alters the structure of a database query instead of remaining data. Modern frameworks and ORMs often parameterise queries by default, but that protection disappears when developers use raw SQL, unsafe helper methods, or language features that interpolate field names or clauses directly. The WordPress flaw described in the article is a good example of a deeper pattern: the dangerous input is not always obvious, and a multi-step code path can bypass the sanitisation teams assumed would apply. That is why the bug class remains alive even in mature stacks.

Practical implication: review every raw-query escape hatch, not just the default ORM path.

Why legacy code and dependency paths keep injection alive

Legacy applications preserve old query patterns for years, and dependency code can introduce injection surfaces that are outside a team’s direct coding standards. Even where parameterised queries are used in most places, a single unreviewed endpoint, admin path, or plugin can reintroduce the issue. The article’s point about runtime backstops is important here: perfect elimination is unrealistic because some vulnerable code will always survive in a large estate. For practitioners, the real question is how much exposure remains when prevention misses something.

Practical implication: pair static scanning with runtime controls that can block exploit payloads in production.

How AI-assisted coding changes injection risk

AI coding assistants do not eliminate injection risk because they learn patterns from code that already contains the flaw. That means they can reproduce vulnerable query construction at scale, especially when prompted by less experienced developers who may not recognise the danger. The article cites research showing that a substantial share of generated code can still be vulnerable, which reinforces a governance point: AI increases output volume faster than security review capacity unless controls are built into the development pipeline. In other words, the attack surface can grow even when the coding experience feels safer.

Practical implication: add automated review and secure coding guardrails before AI-generated code reaches shared branches.

Threat narrative

Attacker objective: The attacker wants to turn ordinary user input into privileged application execution or data access without valid authentication.

1. Entry occurs when an attacker reaches an unauthenticated SQL injection path in a stock application or exposed plugin surface.
2. Escalation follows when injected input changes query logic, revealing data, bypassing checks, or reaching code paths that enable remote execution.
3. Impact is unauthorised database access, backend credential exposure, or full application compromise on systems that assumed the query layer was safe.

NHI Mgmt Group analysis

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.

Runtime backstops matter because prevention will always be incomplete. The article’s discussion of in-app protection reflects a broader control reality: some injection paths emerge through legacy code, dependencies, or unforeseen query construction, and those paths will outlive any single scan or review cycle. That is why application-layer blocking, detection, and containment should be treated as part of the control stack, not as an optional enhancement. For teams, this is a case for layered assurance across build time and runtime.

AI-assisted development is amplifying old mistakes at machine speed. When coding assistants reproduce familiar insecure patterns, the issue is not novelty but scale. Security teams need to treat AI-generated code as a governance input that changes review thresholds, testing coverage, and sign-off expectations. For IAM and NHI programmes, the intersection is direct: vulnerable applications can expose secrets, tokens, and backend service paths that non-human identities rely on, so code insecurity becomes identity exposure.

SQL injection is a direct path from application flaw to identity compromise. Once query injection reaches administrative data, backend configuration, or secrets storage, the blast radius quickly crosses into access control and credential governance. That makes this more than an AppSec issue. For identity teams, the practical conclusion is to watch for injected paths that expose service accounts, tokens, and privileged interfaces, because those are the assets that convert an application bug into a broader compromise.

What this signals

Injection risk now sits at the boundary of application security and identity governance. When a query flaw can expose backend credentials, the control problem extends beyond AppSec into secrets management, service account lifecycle, and privilege containment. That means programmes should link developer testing, runtime protection, and identity oversight rather than treating SQLi as a self-contained bug class.

Secret-bearing applications require shorter response loops than traditional vulnerability management assumes. If an injected path reaches a database or internal service that stores tokens, the issue becomes a credential exposure event, not just a code defect. Teams should align application telemetry with identity response processes so that exposed secrets trigger revocation and offboarding workflows without delay.

AI-generated code increases the need for policy-aware code review and runtime containment. As more code is produced with assistance, organisations need assurance that parameterisation, query construction, and data access patterns are being checked continuously. The operational signal is simple: if review and runtime controls cannot explain why an injected query would fail, the programme is still relying on developer memory more than governance.

For practitioners

• 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. Prioritise privileged paths, JSON field access, and admin features for manual review, because those are the places where safe defaults most often fail.
• 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 this as containment for the paths that static analysis and code review will not catch, especially in legacy code and third-party dependencies.
• 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. Build controls that verify parameterisation and query construction patterns before merge, rather than assuming the model will avoid legacy flaws on its own.
• Map injection findings to identity exposure When SQL injection is discovered, check whether the reachable data stores include secrets, service account material, session data, or backend credentials. That mapping determines whether the issue is a web bug or an identity-control incident requiring broader containment.

Key takeaways

• SQL injection survives because safe defaults are unevenly applied across legacy code, dependencies, and AI-assisted development.
• The evidence still shows material exposure, with advisories rising year over year and tens of thousands of injection-related reports across the category.
• Teams need layered control, combining secure coding, runtime blocking, and identity-aware secrets containment to reduce blast radius.

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.
• 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.
• 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.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.

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.

👉 Aikido's full post covers the WordPress flaw, runtime backstop, and AI-assisted testing detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security decisions that shape application and platform risk.