SQL Injection to RCE: Understanding the Attack Chain

In 2017, Equifax lost the personal data of 147 million people. In 2008, Heartland Payment Systems leaked over 130 million card numbers. Both breaches trace back, in part, to the same root cause: a web application trusted user input enough to let it become part of a SQL query. What often gets lost in the summary version of these stories is how far that initial flaw can actually go -SQL injection doesn't stop at leaking a database table. Under the right conditions, it can hand an attacker a shell on the server itself.

That escalation -from a single unsanitized input field to full remote code execution (RCE) -is the part most SQLi write-ups skip. This post covers the whole arc: what SQL injection is, how it's used to read data, how in the right conditions it escalates into RCE, and how to close the door at every stage.

I'll walk through this step by step in a legal, local lab, and then fix the vulnerable code so you can see the break and the fix side by side.

What Is SQL Injection?

Every web app that talks to a database eventually has to answer a question: "does this exact input the user typed count as data, or as part of the instructions?" SQL injection is what happens when that line gets blurred -when an application builds a query by directly concatenating user input into the query string, instead of keeping it strictly separate as data.

The database itself isn't confused about this - SQL syntax is SQL syntax, whether it came from a developer or an attacker. The vulnerability lives entirely in the application code; in the moment it stitches a string together and hands it to the database as if every part of it were trustworthy.

Once an attacker can control even a small piece of that string, they can control what the query actually does - read data they shouldn't see, bypass authentication entirely, modify or delete records, and in some configurations, execute commands on the underlying server.

Here's the classic vulnerable pattern, in PHP:

// VULNERABLE — user input is concatenated directly into the query
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

// VULNERABLE — user input is concatenated directly into the query
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

If a user submits admin and password123, the query looks like this — totally normal:

SELECT * FROM users WHERE username = 'admin' AND password = 'password123'

SELECT * FROM users WHERE username = 'admin' AND password = 'password123'

But what if someone submits ' OR '1'='1 as the username?

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''

'1'='1' is always true, so the WHERE clause is satisfied regardless of the actual credentials — the attacker logs in without knowing a valid password. That's the whole idea: the input reshapes the logic of the query itself.

This particular example is a login bypass, but the same principle — attacker-controlled input reshaping query logic — is what powers every variant below. And depending on how the database is configured, that same principle can escalate from "read data I shouldn't see" all the way to "run commands on the server." We'll get to exactly how later in this post.

Types of SQL Injection

In-band SQLi — the attacker gets results directly in the application's response.
Union-based: uses the UNION operator to append a second query and pull extra data (e.g. other tables) into the visible output.
Error-based: deliberately triggers DB errors that leak information (table names, versions) in the error message.
Blind SQLi — no data is returned directly; the attacker infers information from application behavior.
Boolean-based: asks true/false questions (AND 1=1 vs AND 1=2) and watches for a difference in the response.
Time-based: uses functions like SLEEP(5) and measures response delay to confirm an answer.
Out-of-band SQLi — the database sends data out through a different channel entirely (e.g. DNS or HTTP requests), used when in-band responses aren't available.

How the Exploitation Flow Works, Conceptually

Actually, exploiting a union-based SQLi flaw follows a predictable logical sequence — worth understanding even without running it yourself, since the shape of the process is what matters most.

First, confirm the input is unsanitized. An attacker submits something that would break normal query logic if it were treated literally — a stray quote, a tautology like OR 1=1. If the application's behavior changes in a way that only makes sense if that input reshaped the underlying SQL (e.g. a single-record lookup suddenly returns every record), that confirms the input isn't being escaped or parameterized.
Second, map the query's shape. Before an attacker can append their own data to the output, they need to know how many columns the original query returns and which of those columns are actually reflected back in the response. This is usually done by incrementally testing until the query breaks or the injected values become visible — effectively reverse-engineering the query's structure from the outside.
Third, substitute in real data. Once the shape is known, the attacker replaces placeholder values with a query against the tables they actually want — user credentials, personal data, whatever the schema holds. The application, having no way to distinguish this from its own intended query, dutifully returns the result.
Fourth, this fails once the input is properly handled. Where the underlying code binds input as data rather than concatenating it into the query, none of the above works — the "malicious" string is just compared or stored as a literal value, exactly as intended. This is the entire reason parameterized queries close the vulnerability rather than just making it harder to find.

From Data Leak to Remote Code Execution

Reading data out of a database is bad. But SQL injection's worst-case outcome isn't data theft — it's using the database as a foothold to execute arbitrary commands on the underlying server. This doesn't work against every misconfigured app, and it requires specific conditions to line up, but when they do, the escalation path is well documented, and attackers actively look for it.

Here's what typically has to be true:

The database account the app connects with has elevated privileges it doesn't need for normal operation (e.g. FILE privilege in MySQL, or admin rights in MSSQL) — usually because someone connected the app as root/sa instead of a scoped-down user.
A write-capable path exists from the database out to somewhere the attacker can then reach over HTTP (like the web server's document root), or the DB engine itself exposes a way to run OS commands directly.
The relevant feature isn't disabled, since most of these techniques rely on functionality that's meant for legitimate admin use and should be turned off in production.

A few concrete mechanisms, by database engine:

MySQL/MariaDB — INTO OUTFILE: if the connected account has the FILE privilege and file-write restrictions aren't in place, an attacker can use this clause to write arbitrary file contents directly to disk. If that file lands inside the web server's document root and contains web-shell code, the attacker gains a way to execute commands simply by requesting that file over HTTP — at which point they've moved from manipulating a query to running arbitrary commands on the server.
MySQL — User Defined Functions (UDFs): with sufficient privileges, an attacker can load a UDF that wraps a native OS command execution function, turning a SQL query itself into a way to run shell commands — no web shell required.
Microsoft SQL Server — xp_cmdshell: a built-in (but disabled-by-default) stored procedure that runs OS commands directly from a SQL query. If it's been enabled and the app's DB account has permission to call it, this becomes arbitrary command execution with no file write needed at all.
PostgreSQL — COPY ... TO/FROM PROGRAM: a legitimate bulk-import/export feature that, if reachable, can be repurposed to execute arbitrary shell commands via the same mechanism.

Two things worth sitting with here: first, this only works because of a specific, avoidable configuration choice — an overprivileged DB account with a writable path to somewhere the attacker can reach. It's not an inherent property of SQL injection itself; it's what happens when injection meets excessive trust elsewhere in the stack. Second, this is exactly why the "how bad can SQLi really be" question doesn't have a fixed answer — it depends entirely on what the database account is allowed to do, which is also exactly why that privilege boundary is worth defending even if you assume the injection itself might someday slip through.

The Fix: Parameterized Queries

The root cause was never "bad input" — it was treating input as part of the SQL code. The fix is to always separate code from data using parameterized queries (prepared statements), so the database engine knows exactly what's a query and what's a value, no matter what the value contains.

PHP (mysqli, prepared statements):

// FIXED — input is bound as data, never interpreted as SQL
$stmt = $conn->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$result = $stmt->get_result();

// FIXED — input is bound as data, never interpreted as SQL
$stmt = $conn->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$result = $stmt->get_result();

Python (using sqlite3 or any DB-API driver):

# VULNERABLE
query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(query)

# FIXED - parameters are passed separately, never concatenated
cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password)
)

# VULNERABLE
query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(query)

# FIXED - parameters are passed separately, never concatenated
cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password)
)

Run the same ' OR '1'='1 payload against the fixed version, and it's just treated as a literal string being compared against a username — no match, login fails as expected.

Defense in Depth

Parameterized queries fix the root cause, but no single control should be your only line of defense. Good security is layered, so that a mistake in one place doesn't automatically become a breach:

Prepared statements / parameterized queries — the primary defense, always. This should be the default in every new query you write, not something you add after the fact.
ORMs (SQLAlchemy, Eloquent, Prisma, Django ORM, etc.) — parameterize under the hood by default, which removes the temptation to hand-build SQL strings. Worth noting: ORMs still have raw-query escape hatches (.raw(), .extra(), etc.) — those bypass the protection entirely if you're not careful.
Input validation & allowlisting — reject input that clearly doesn't match the expected format before it ever reaches a query (e.g. a numeric ID field should reject anything non-numeric outright). This is a good early filter, but it's a supplement to parameterized queries, not a replacement — validation logic can have gaps that a fixed query structure doesn't.
Least-privilege database accounts — the account your application connects with should only have the permissions it actually needs (e.g. a read-only reporting service shouldn't have DROP rights). If an injection does slip through, this limits how much damage it can do.
Web Application Firewalls (WAFs) — useful as a detection and mitigation layer, especially for catching known attack patterns quickly, but not a substitute for fixing the code. WAF rules are pattern-based and can often be bypassed with obfuscated or encoded payloads — treat it as a safety net, not the fix.
Harden the database configuration itself — this is what actually closes off the RCE path even if an injection point somehow exists. Concretely: strip FILE privilege from application DB accounts, set secure_file_priv to a restricted or empty path in MySQL, leave xp_cmdshell disabled in MSSQL unless there's a specific operational need, and disable UDF loading for standard app accounts. None of this requires the injection to be fixed to be effective — it's a second, independent wall.

The common thread: every layer here assumes the one before it might fail. That's the mindset that actually holds up in production — the difference between a login bypass and a full server compromise usually comes down to which of these walls were actually in place.

Tools Worth Knowing

sqlmap — automates detection and exploitation of SQLi across many database engines; great for testing your own applications
Burp Suite — intercepting proxy for manually crafting and replaying injection payloads against web traffic

Wrapping Up

SQL injection is old, well-documented, and completely preventable — yet it keeps showing up because the fix (parameterized queries) is easy to skip under deadline pressure, and the vulnerable pattern looks fine until someone tests it. What makes it worth taking seriously isn't just the login bypass or the leaked table — it's the ceiling. Under the wrong configuration, the same flaw that lets someone skip a login screen can end with them running commands on your server. That gap — between "seems contained" and "full compromise" — usually comes down to a handful of privilege and configuration decisions made long before any attacker shows up.

If this was useful, I'm planning a hands-on follow-up walking through this same flow in a local lab (DVWA) once I've got that environment properly set up.

References and Resources

SQL Injection Labs | CybersecTools

Sec-88/web-appsec/sql-injection/sql-to-rce.md at main · h0tak88r/Sec-88 · GitHub

From SQLi to RCE — Exploiting LangGraph's Checkpointer — Check Point Research

SQL injection to RCE exploitation | by Bijay Kumar | Medium

Contents