Learn SQL injection the way it's actually found — hands-on, against a live target. Detect, exploit, and report SQLi on CorvusBank, a realistic fake fintech portal, in PhantomRed Academy.
SQL injection happens when untrusted input is stitched directly into a database query. Instead of being handled as plain data, the input is parsed as part of the SQL statement — so an attacker who understands the query's shape can rewrite its logic, turning a login box or a search field into a window onto the entire database.
It is one of the oldest vulnerability classes on the web and still one of the most damaging, because it lands squarely on the data layer. A single injectable parameter can expose customer records, credentials, and internal tables that the application was never meant to reveal.
A working injection can return rows far beyond what the feature intended — other users' records, password hashes, entire tables — simply by extending the query the application already runs.
Depending on the flaw, injection can subvert authentication logic, alter or delete stored data, and in some configurations reach the database host itself — escalating a web bug into full data-layer compromise.
SQL injection is the classic example of A03:2021 – Injection in the current OWASP Top 10. Injection has appeared in every edition of the list; it stays near the top because it maps so directly to the data an application is built to protect. The impact classes below are what earn confirmed SQLi a high-severity rating.
| Impact | What the attacker gains | Severity |
|---|---|---|
| Data exfiltration | Read arbitrary rows and tables from the database | High |
| Authentication bypass | Subvert login logic to access accounts | High |
| Data tampering | Modify or delete stored records | High |
| Schema disclosure | Enumerate database structure and metadata | Medium |
SQL injection is one of the vulnerability classes automation handles well: a scanner can send crafted inputs, diff the responses, and flag an injectable parameter with a severity rating in minutes. That is exactly what Room 2 starts with — a real PhantomRed scan against CorvusBank that surfaces the finding for you to read.
But a finding is not a report. The human still confirms the impact, understands why the parameter is injectable, and writes up something a developer can act on. The room walks that full loop:
Prefer to see how the scanning half works on its own? The Nuclei automation workflows guide covers the template-driven detection PhantomRed builds on.
The CorvusBank lab is live and free to play. Run a real autonomous scan, read the SQLi finding it surfaces, then confirm and report the vulnerability end to end.