What Is SQL Injection? How It Works and How to Prevent It

SQL injection is an attack that smuggles malicious database commands into a web application through an ordinary input field — a login box, a search bar, a URL parameter — by exploiting code that builds SQL queries out of unfiltered user input. Once it works, an attacker can read data they were never meant to see, bypass login checks entirely, or in the worst cases modify or delete records and take over the underlying database server. It's one of the oldest classes of web vulnerability and, despite decades of known fixes, still shows up in real breaches every year.

What SQL injection actually is

Per the official CWE-89 definition maintained by MITRE, SQL injection occurs when "the product builds all or part of an SQL command using externally influenced input... but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command." In plain terms: a web application takes something a user typed and pastes it straight into a database query, trusting that the input is just data — when it might actually contain SQL syntax designed to change what the query does.

The classic illustration is a login form. A naively written query might look like checking whether a row exists where the username and password match what was typed. If the application builds that check by directly concatenating the user's input into the query text, typing something like ' OR '1'='1 into the username field can turn the query's condition permanently true — a technique OWASP's own documentation describes happening when unescaped quote characters let attacker-supplied text escape the intended data context and start writing SQL logic of its own. The result: the application may let the attacker log in as any user, or return far more data than it was supposed to.

How an attack actually plays through

Most real SQL injection falls into two broad categories. In classic (in-band) injection, the application reflects query results or database error messages directly back to the attacker — making it straightforward to see immediately whether an injected payload worked and what data it returned. In blind SQL injection, the application shows no query results or errors at all, so the attacker has to ask the database "true or false" questions one at a time and infer the answer from how the page behaves. According to OWASP's documentation on blind SQL injection, attackers do this by injecting conditions like and 1=1 (true) versus and 1=2 (false) and watching whether the page's content changes, or by using time-based techniques — functions like MySQL's BENCHMARK(), SQL Server's WAITFOR DELAY, or PostgreSQL's pg_sleep() — that force the database to pause only when a guess is correct, letting an attacker extract data such as passwords one character at a time purely by measuring response time. Automated tools like sqlmap can run this entire process without a human manually guessing each character.

What an attacker can actually do with it

MITRE's CWE-89 entry lists the realistic range of outcomes, and none of them are minor. A successful injection can let an attacker read application data most databases are built specifically to protect, since "databases typically hold sensitive data"; bypass authentication entirely if a login query can be manipulated into always returning true; modify or delete records by injecting write operations instead of reads; and in some configurations, execute unauthorized operating-system-level commands by writing output to a file the server will later execute, or by abusing database features designed for administrative tasks. Which of these is possible in a given case depends on the specific query, the database permissions the application connects with, and the database engine's own feature set — but the starting point for all of them is the same unescaped input.

A real 2026 example: the Metabase SQL injection flaw

SQL injection isn't just a textbook concept — it continues to produce critical, actively exploited vulnerabilities. In August 2026, a flaw tracked as CVE-2026-72898 in Metabase, a widely used open-source analytics and business-intelligence tool, let a remote, unauthenticated attacker inject arbitrary SQL through the application's own /reset_password endpoint and gain full administrator access to the connected Metabase instance, according to the National Vulnerability Database's record for the flaw. NVD scored it a maximum CVSS 10.0, its highest possible severity rating, reflecting that the bug required no credentials, no user interaction, and could be triggered over the network with full impact on confidentiality, integrity, and availability. The fix across every affected Metabase version line was simply to upgrade to the patched release — there was no practical mitigation that let vulnerable versions keep running safely.

SQL injection vs. other injection attacks

SQL injection is the best-known member of a broader family OWASP groups together as "Injection" attacks, and it's worth knowing where the family lines are drawn. NoSQL injection targets non-relational databases like MongoDB, exploiting the way an application builds queries or filter objects from user input rather than SQL text specifically — the underlying mistake (trusting input as code instead of data) is identical, even though the syntax is completely different. Command injection, a separate CWE entry, lets an attacker run operating-system commands through an application that passes unfiltered input to a shell, rather than to a database. LDAP injection applies the same trick to directory-service queries. All of these share SQL injection's root cause and its root fix — treat user input as data, never as part of the command itself — which is why security teams usually train developers on the general principle rather than SQL injection in isolation.

Why this still happens in 2026

If parameterized queries have been standard advice for this long, SQL injection's continued presence in current vulnerability catalogs needs an explanation. In practice, a few patterns keep recurring: legacy codebases written before parameterized queries were the default convention in a given language or framework; database-heavy admin panels and internal tools that get less security scrutiny than customer-facing code, like the Metabase password-reset endpoint above; third-party plugins and extensions bolted onto otherwise well-built applications; and ORMs or query builders that still expose an escape hatch for raw SQL, which developers reach for under time pressure and then forget to parameterize. None of these require a new technical fix — they're organizational and process problems, which is a large part of why a vulnerability class with a known solution for over a decade still shows up in this year's patch advisories alongside entirely different classes of bugs.

How common is SQL injection, really?

OWASP's Top 10 Web Application Security Risks for 2021 ranks "Injection" — the broader category that includes SQL injection — as the third most critical risk category overall (A03:2021), noting that 94% of the applications OWASP's contributors tested were checked for some form of injection, with an average incidence rate of 3.37% and a maximum incidence rate as high as 19.09% across tested applications. OWASP's data also ties the Injection category to 33 distinct CWEs and more than 32,000 individual CVEs reported against it, underscoring that this isn't a rare, theoretical bug class — it's one of the most consistently reported vulnerability families in application security, year after year. For context on how severity scores like the Metabase flaw's 10.0 are calculated in the first place, see our explainer on how CVE IDs and CVSS scores work; the Metabase bug is also a useful case study for our broader guide to zero-day and newly disclosed vulnerabilities, since the gap between disclosure and patching is exactly when attacks tend to spike.

How to actually prevent it

Both MITRE and OWASP converge on the same primary fix: stop building SQL queries by concatenating strings together, and use parameterized queries, prepared statements, or stored procedures that keep user input in a separate channel from the SQL command structure — what the database driver treats strictly as data, never as executable syntax. OWASP's guidance adds that stored procedures aren't automatically safe either, since a procedure that builds its own SQL internally by concatenating strings can still be injectable. As defense in depth, both organizations recommend running the application's database account with the least privilege it needs rather than a broad administrative account, so that even a successful injection has a limited blast radius. Allowlist-based input validation (accepting only known-safe characters) and keeping detailed database errors away from end users round out the standard recommendations — but neither replaces parameterized queries as the primary fix, since validation alone can't account for every way malicious input might be encoded.

Bottom line

SQL injection is a solved problem from an engineering standpoint — the fix (parameterized queries) has been well understood for well over a decade — and it keeps causing real, severe breaches anyway, because legacy code, rushed features, and third-party plugins keep reintroducing the same mistake. If you're a developer, the practical takeaway is simple: never build a SQL query by directly inserting user input into a string, full stop, and treat any code that does otherwise as a bug to fix immediately rather than a style preference. If you're not a developer but run software that touches a database — like the Metabase example above — staying current on vendor security patches is the realistic defense, since this class of bug tends to be both severe and, once public, rapidly weaponized by automated scanning tools across the internet — a pattern that shows up repeatedly in the vulnerabilities covered on this site, including the critical, unauthenticated flaws CISA and vendors disclose on a near-weekly basis.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage