An error is not proof: verifying an exploitable SQL injection

The finding looks finished before you have done any real work. Your scanner — or a single typed quote — lands in a parameter, the page breaks, and a database error spills into the response: a stack trace, a SQLSTATE code, a syntax complaint quoting your input back at you. “SQL injection,” you write, and attach the screenshot. The trouble is that a database error proves exactly one thing: your input reached a place where it could break SQL syntax. It does not prove that an attacker can read a row they should never see, and the distance between those two statements is the entire finding. The costed bug is not a red error page; it is controlled, reproducible evidence that the database returned data — or changed it — because of input you supplied, demonstrated with a value you chose rather than one you hoped was there.

What SQL injection actually is

PortSwigger's Web Security Academy defines it simply: SQL injection “allows an attacker to interfere with the queries that an application makes to its database,” letting them view data they could not normally retrieve and, in many cases, “modify or delete this data, causing persistent changes.” Underneath is CWE-89: untrusted input is concatenated into a query so the parser treats part of your data as query code. The classic shape is a login or search that builds SQL by gluing strings together, but the bug survived the ORM era intact — a raw fragment, a hand-built ORDER BY, an HQL string with a value concatenated in, and the window reopens. It is also not always where you typed: in second-order injection, the application stores your input safely and then builds an unsafe query with it somewhere else entirely, so the request that plants the payload looks completely inert.

Why an error — or a blip — is not proof

Every signal that a parameter is injectable has an innocent twin, and in a single observation you cannot tell them apart. That is the same asymmetry the rest of this series keeps running into, and SQL injection has four costumes worth naming:

• A reflected database error. It proves your input reached a query context and broke the syntax — a genuinely strong lead. But many applications return a generic 500 or a templated error page for any malformed input, and a stack trace that never changes with your payload is noise, not a channel. Reaching a query is not reading from it.
• A reflected quote. Your ' appears in the response, so it looks like it reached SQL. Often the application simply echoed your input into HTML; that is a possible XSS lead, not evidence the character ever touched the database.
• A boolean difference. One request returns “Welcome back” and a slightly altered one does not. Caching, A/B assignment, rate limiting, personalization, and plain unrelated branching all produce two different pages without a database ever evaluating your condition.
• A slow response. You append a SLEEP and the response takes five seconds. Time is the noisiest channel in all of testing — garbage collection, a cold cache, a busy connection pool, network jitter — and a single slow response is one of the weakest signals you can act on.

The way out is the discipline the brand is named for: stop reading the error and make the database return a value you picked. A fact the application had no reason to put in that response — the database version string, the current user, a row you planted yourself — appearing because of your input is the thing a generic error page, a cache, and a jittery network cannot fake.

The proof question, channel by channel

Which proof you reach for depends on what the application hands back. The goal never changes: a differential result keyed on a value you control, reproduced, and scoped to something benign.

In-band: the answer comes straight back

If query results or errors surface in the response, prove it directly. UNION-based: work out the column count (append ORDER BY ordinals until it errors, or union rows of NULL), then return a benign metadata value — the version string, current_user — through the extra columns. Its appearance in the page is the proof that data egressed; keep it to database metadata, never a user table. Error-based: coerce the database to compute a value you chose and surface it inside an error (for example, casting the version string into a type conversion that fails). The differential that matters is your computed value appearing — not a generic error, which any bad input produces.

Blind: you only see behaviour

When results and errors are suppressed, the blind techniques turn the application into a one-bit oracle. Boolean: inject a condition that is true versus one that is false (asking whether the first character of the version is one digit, then another) and confirm the response reliably tracks the predicate — repeated, so an unrelated difference cannot explain it. Time: make the delay conditional and compare against a control — a payload that should not delay must come back fast, the one that should must come back slow, across several trials, with the spread small enough that jitter is not the story. This is the race-condition lesson again: one slow response is luck; a conditional delay that reproduces is a channel.

Out-of-band: make the database call you

If there is no in-band channel and the response timing is unusable, the last resort is OAST: trigger the database to make a DNS or HTTP request to a server you control. A callback arriving proves your input executed; keep that proof of execution separate from any data you exfiltrate, and exfiltrate only a canary. The callback is SSRF-grade evidence on its own.

# One benign canary, proven differentially, then reproduced — not a stack trace.
# Scope every proof to database METADATA (version, current_user) or a row you
# planted yourself. Never dump a real user table to "demonstrate" impact.

# IN-BAND (UNION): find the column count, then return a value you chose.
#   ... ORDER BY 6  -> error,  ORDER BY 5 -> ok      => 5 columns
#   ... UNION SELECT NULL, version(), NULL, NULL, NULL --
#   PROOF = the version string you did not type appears in the page.

# BLIND (boolean): a reproducible true/false oracle on a controlled predicate.
#   true-condition  -> "Welcome back"   (page A)
#   false-condition -> no welcome        (page B)
#   repeat with different predicates -> the page tracks YOUR condition, reliably.

# BLIND (time): a conditional delay WITH a control, across trials.
#   control payload (should not delay)  -> ~50ms, ~55ms, ~50ms
#   conditional delay IF true (5s)      -> ~5.0s, ~5.1s, ~5.0s
#   the gap, reproduced, is the proof; one slow response alone is not.

# OUT-OF-BAND (OAST): make the DB reach a host you control.
#   inject a lookup to <id>.collaborator.example -> a DNS hit arrives = executed.
#   keep the callback (proof) separate from any canary you exfiltrate.

A real one: an unauthenticated query that owned the instance

SQL injection did not stop mattering when prepared statements became common; it keeps producing the year's worst breaches. In August 2026, Metabase — the open-source analytics tool — disclosed GHSA-vwf4-m7j8-wcjf (tracked as CVE-2026-72898), an unauthenticated SQL injection reachable before any login, at the /api/session/reset_password endpoint, that let a remote attacker “inject arbitrary SQL into the Metabase application database” and obtain administrator access. The official advisory scores it CVSS 10.0 and states that Metabase confirmed active exploitation; the advisory and patches were published on 6 August 2026, in versions 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5. CISA added it to its Known Exploited Vulnerabilities catalog, which makes remediation mandatory for US federal agencies. It was exploited in the wild as a zero-day before a patch existed.

For a piece about proof, the detail that matters is that this was never a “possible SQLi” on a scanner's list: the query provably executed in the application database, pre-authentication, and because Metabase holds the connection credentials for the data stores it reports on, proven admin access is a pivot into everything behind it. The severity was not the 10.0 in the abstract — it was what that specific injection reached on that specific deployment. That is exactly why impact is demonstrated per target rather than assumed from the bug class.

Verifying it safely

A real SQL injection is a loaded gun, and the proof must not become the damage. Extract only a non-sensitive canary — the version, the current user, a row you planted — never real customer data, even to make the report land harder. Keep proofs read-only: a conditional SELECT demonstrates the vulnerability without touching a row; stacked queries that UPDATE or DROP real tables are how a test becomes an incident. Reproduce the result — especially the blind and time-based ones — across several trials with a control, and hold the blast radius to your own account or tenant and effects you can reverse.

This is also where automated testing meets an honest ceiling, ours included. A scanner can fire a boolean pair or a timed payload and flag a difference; what it cannot do for free is decide which extracted value proves a real exposure on this system, keep the extraction scoped to something benign, and tell a reproduced channel apart from a lucky blip. That judgement — the gap between detecting a signal and re-exploiting it into proof — leans on the application's business logic, and it is why a confirmed injection still deserves a human-legible demonstration rather than a severity label alone. Proof that the database answered you does not, by itself, tell you how much the answer is worth; that is reachability and impact reasoning layered on top.

The traps

• A 500 is not proof. A generic error page fires on any malformed input. If the error does not change with your payload, you have no channel — make the database return a value you chose.
• A reflected quote is not injection. Your ' echoed back in the HTML may be an XSS lead; it is not evidence anything reached the query.
• One slow response is not time-based SQLi. Prove it with a conditional delay, a fast control, and repetition — otherwise it is just a busy server.
• A WAF block is not a fix. That a request was blocked tells you a filter exists, not that the query is parameterized; filters get bypassed, and the underlying bug is still there.
• Second-order hides from a single request. If the payload is stored now and used in a query later, the request that plants it looks inert. Trace where stored values are concatenated downstream.
• “The ORM protects us” is conditional. ORMs bind parameters only when you let them. Raw fragments, string-built ORDER BY clauses, and concatenated query languages are injectable all the same. And NoSQL injection is a different bug class — operator injection, not SQL — so do not assume a document store is immune.

The fix that holds

You close this in code, and OWASP's prevention cheat sheet is unambiguous about the order. The primary defense is prepared statements with parameterized queries, which treat bound values as data rather than SQL syntax — with the warning that concatenating untrusted values before preparing the query defeats the protection entirely. Stored procedures are not automatically safe: binding the call protects it, but dynamic SQL built inside the procedure is still injectable. For the things a parameter marker cannot represent — table names, column names, ORDER BY direction — use allow-list validation: map the user's choice to an application-owned token and reject anything unknown. Manual escaping is “strongly discouraged” because it depends on the SQL dialect and configuration, and least privilege and a WAF are hardening that limits damage — not a substitute for parameterization.

// Vulnerable: the value becomes part of the SQL text. A ' ends the string and
// the rest of the input is parsed as code.
const q = "SELECT id, email FROM users WHERE handle = '" + handle + "'";

// Fixed: the value is bound as data and can never change the query's structure,
// whatever characters it contains.
db.query("SELECT id, email FROM users WHERE handle = ?", [handle]);

// Identifiers can't be parameterized. Don't concatenate them — allow-list them.
const SORT = { newest: "created_at", name: "display_name" };     // app-owned map
const col = SORT[req.query.sort] ?? "created_at";                // reject unknown
db.query("SELECT id, email FROM users ORDER BY " + col + " ASC");