SQL Injection — Overview

What is SQL Injection#

SQL Injection (CWE-89, OWASP A03:2021) occurs when user-supplied input is concatenated directly into a SQL query instead of being bound as a parameter. The database engine parses attacker-controlled tokens as SQL syntax, executing them with the same privileges as the application's database account. The 2024 Verizon DBIR linked 26% of all data breaches to web application attacks that included SQL injection. OWASP A03:2021 (Injection) records 14,000+ CVEs mapped to CWE-89 and notes that 100% of applications tested showed at least one injection finding.

The vulnerability is not limited to legacy PHP codebases. CVE-2025-25257 (Fortinet FortiWeb, CVSS 9.6) was actively exploited in the wild in July 2025, allowing pre-authenticated attackers to chain SQLi with INTO OUTFILE for root RCE. CVE-2024-43468 (Microsoft SCCM, CVSS 9.8) reached CISA's Known Exploited Vulnerabilities catalog in February 2026. CVE-2024-42005 (Django, CVSS 9.8) demonstrated that even high-level ORM calls — not raw SQL — can be injectable when JSON column aliases are constructed from user input.

The attack surface has expanded beyond classic GET/POST parameters. Injection vectors now include GraphQL arguments, HTTP headers logged to databases, JSON body fields, ORM escape hatch functions, and AI/LLM-generated SQL strings. Classic DAST scanners and WAFs frequently miss these newer vectors.

How SQL Injection Works#

When an application constructs a query by string concatenation, the attacker controls part of the SQL parse tree. The canonical example: a login form that builds SELECT * FROM users WHERE username = ' + input + '. Injecting admin'-- closes the string literal and comments out the password check entirely, bypassing authentication without knowing any credentials.

The injection lifecycle has four stages: (1) identify an injectable parameter by observing response changes to quote characters; (2) fingerprint the database engine via error messages or conditional timing; (3) enumerate schema via information_schema, sysobjects, or DB-native catalog tables; (4) extract target data or escalate to code execution.

SQL Injection Variants#

The six major variants differ in how data reaches the attacker and what in-band or out-of-band channel is available.

Union-based is the fastest for data extraction when query results are reflected. Error-based applies when verbose error messages are enabled. Blind Boolean and Time-based cover cases where no direct output is visible. OOB is used when all in-band channels are suppressed or asynchronous. Second-order injection is systematically missed by automated tools.

Database-Specific Syntax Cheat Sheet#

Understanding database-specific syntax is essential for testing and confirming injection across different backends.

ORM Escape Hatches#

Developers often assume that using an ORM eliminates SQL injection risk. That assumption is correct for standard ORM query methods. It breaks down immediately at escape hatch functions that bypass the parameterization layer.

// Prisma — $queryRawUnsafe IS vulnerable
const users = await prisma.$queryRawUnsafe(
  `SELECT * FROM "User" WHERE email = ${untrustedInput}`  // VULNERABLE
)
 
// Prisma — $queryRaw with tagged template IS safe
const users = await prisma.$queryRaw`SELECT * FROM "User" WHERE email = ${untrustedInput}`

# SQLAlchemy — text() with f-string IS vulnerable
db.execute(text(f"SELECT * FROM users WHERE name = '{user_input}'"))  # VULNERABLE
 
# SQLAlchemy — text() with bound parameters IS safe
db.execute(text("SELECT * FROM users WHERE name = :name"), {"name": user_input})

# Django — raw() with f-string IS vulnerable
User.objects.raw(f"SELECT * FROM users WHERE name = '{name}'")  # VULNERABLE
 
# Django — raw() with parameters IS safe
User.objects.raw("SELECT * FROM users WHERE name = %s", [name])

CVE-2025-64459 (Django, CVSS 9.1) demonstrated that even standard ORM calls can be injectable when user-controlled dictionaries are expanded into filter(**user_input) without validating internal Q() object parameters.

JSON-Based WAF Bypass#

In 2022, Claroty Team82 published research showing that five major WAF vendors — Palo Alto, AWS WAF, Cloudflare, F5, and Imperva — failed to inspect JSON syntax for SQL patterns. Modern SQL databases support JSON operators natively, allowing payloads like the PostgreSQL containment operator (<@) or MySQL JSON_EXTRACT() to pass through WAF inspection untouched.

-- PostgreSQL: containment operator — WAF sees JSON, DB executes SQL context
'{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb
 
-- MySQL: JSON function as injection wrapper
JSON_EXTRACT('{"id": 14}', '$.name') = 'admin' OR 1=1--

All five vendors patched after coordinated disclosure in 2022–2023. Older deployments and custom WAF rule sets may remain vulnerable. This bypass is also effective against content-type switching: many WAFs apply SQL injection rules only to application/x-www-form-urlencoded and skip application/json bodies entirely.

Real-World Breaches#

Heartland Payment Systems (2008) — SQL injection against the payment processor's internal network compromised approximately 130 million credit and debit card records. At the time, it was the largest data breach ever recorded. Attackers used the initial SQLi to gain a foothold, then installed packet-sniffers on the transaction processing network.

Equifax (2017) — The breach affecting 143 million US consumers included SQLi as part of the attack chain exploiting Apache Struts. Equifax had been warned about the vulnerability months before exploitation. The breach resulted in $700 million in settlements.

MOVEit (2023) — Progress Software's MOVEit Transfer file-sharing platform contained a zero-day SQL injection vulnerability (CVE-2023-34362, CVSS 9.8). The Cl0p ransomware group exploited it across 80% of US corporate victims before a patch was available. Amazon employee data was among the records stolen and sold.

CVE-2024-43468 (Microsoft SCCM, CVSS 9.8) — Unauthenticated SQL injection in the MP_Location service of Microsoft Configuration Manager. Exploitation enables xp_cmdshell, granting full OS command execution on the SCCM server. Synacktiv published a public PoC in November 2024; CISA added this to KEV in February 2026.

Second-Order (Stored) SQL Injection#

Second-order SQLi stores the payload safely at one endpoint, then retrieves and executes it at a different endpoint. The attack exploits the false assumption that once data is stored, it is "trusted" for future use.

1. Store:  POST /api/report/ {"dateRange": "2024-08-15'"}  → 200 OK (escaped, stored)
2. Verify: GET /api/report/ExportToExcel                   → 500 Error (SQL executes)
3. Confirm: POST with {"dateRange": "2024-10-06';--"}      → 200 OK on verify
4. Timing:  WAITFOR DELAY '0:0:20' via store               → 20s delay on verify
5. OOB:    xp_dirtree via store                            → DNS callback with DB_NAME()

Common store → verify endpoint pairs include /register → /admin/users, /profile/update → /dashboard, and /api/report/ → /api/report/ExportToExcel. SQLMap handles second-order testing with --second-url.

Detection#

Manual Testing#

1. Send a single quote (') appended to the parameter value and observe whether the response changes in status code, content length, or body content.
2. Send AND 1=1-- (true condition) and AND 1=2-- (false condition). A different response for each confirms boolean-differential injection.
3. Send ' OR SLEEP(3)-- and measure response time. A 3-second delay confirms time-based injection.
4. Check HTTP headers: X-Forwarded-For, User-Agent, Referer, and Cookie values logged to databases are frequently injectable.
5. Test JSON body fields: change {"filter": "value"} to {"filter": "value' OR 1=1--"} and observe differences.

Automated Detection#

# sqlmap baseline scan with authentication
sqlmap -u "https://target.com/search?q=1" --batch --dbs
 
# JSON body injection
sqlmap -u "https://target.com/api/users" \
  --data='{"filter":"*"}' --content-type="application/json" \
  --technique=BEUST --batch
 
# Header injection
sqlmap -u "https://target.com/" \
  --headers="X-Forwarded-For: *" --level=3 --batch
 
# Second-order
sqlmap -u "https://target.com/store" \
  --data="field=*" --second-url="https://target.com/trigger" --batch

BreachVex detects SQL injection through complementary techniques: baseline measurement, quote-appended probing, boolean true/false differential analysis, and proportional timing confirmation for time-based variants.

Prevention#

1. Parameterized Queries (Primary Defense)#

Parameterized queries bind user input as data, never as SQL syntax. This defense works at the protocol level — it cannot be bypassed by any encoding or injection technique.

# Python psycopg2 — safe
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))
 
# Python SQLAlchemy — safe
db.execute(text("SELECT * FROM users WHERE name = :name"), {"name": name})

// Node.js pg library — safe
const result = await client.query(
  'SELECT * FROM users WHERE username = $1', [username]
);

// Java PreparedStatement — safe
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?"
);
stmt.setString(1, username);

2. Allow-List Validation for Non-Parameterizable Inputs#

Table names, column names, and ORDER BY direction cannot be parameterized. Use strict allow-lists.

ALLOWED_COLUMNS = {'id', 'name', 'email', 'created_at'}
ALLOWED_DIRECTIONS = {'ASC', 'DESC'}
 
def safe_sort(column, direction):
    if column not in ALLOWED_COLUMNS or direction not in ALLOWED_DIRECTIONS:
        raise ValueError("Invalid sort parameter")
    return f"ORDER BY {column} {direction}"

3. Least Privilege Database Accounts#

The application's database account should hold only the permissions it needs: SELECT on read-only tables, INSERT/UPDATE on specific write tables. Never grant FILE (MySQL), xp_cmdshell execute rights (MSSQL), or COPY TO PROGRAM access (PostgreSQL superuser). An attacker exploiting SQL injection can only do what the database account is permitted to do.

FAQ#

Is SQL injection still a threat in 2026? CWE-89 ranks #3 on MITRE/CISA CWE Top 25 (2024). CISA catalogued 4 exploited SQLi CVEs in 2024 alone. CVE-2025-25257 (FortiWeb) was actively exploited in the wild in July 2025.

Does using an ORM protect against SQL injection? Standard ORM methods generate parameterized queries and are safe. Escape hatch functions ($queryRawUnsafe, raw(), text() with f-strings) bypass all protections. CVE-2025-64459 (Django, CVSS 9.1) demonstrated that even non-raw ORM calls can be injectable through internal parameter manipulation.

Can SQL injection bypass a WAF? Yes. The 2022 Claroty Team82 research bypassed five major WAFs simultaneously using JSON operators. Additional techniques include comment injection, URL encoding, keyword fragmentation, and HTTP parameter pollution. WAFs are defense-in-depth, not primary prevention.

What is the single most effective defense? Parameterized queries (prepared statements) at the application layer. CISA's March 2024 Secure by Design Alert explicitly calls on vendors to eliminate SQL injection as a vulnerability class by adopting parameterized queries universally.

Resources#

• OWASP SQL Injection Prevention Cheat Sheet
• PortSwigger SQL Injection Academy
• CISA KEV Catalog — SQLi entries
• NIST NVD — CWE-89