Malware
SQL injection
Also called SQLi.
SQL injection is a flaw where user input is placed into a database query as code, so the attacker can read or change data the app never meant to expose.
How it is measured
Test inputs that reach queries: search boxes, IDs in URLs, login fields, sort parameters. A single quote that raises a database error, a boolean change like ' OR '1'='1 altering the results, or a time delay from a sleep call signals injection. Logs show patterns such as UNION SELECT.
The fix is measurable in the code: count queries built by string concatenation versus prepared statements with bound parameters. Review database account permissions too, since the damage depends on what the app's account can touch.
Worked example
A WordPress plugin for a ticket site has ?event_id=14. Adding a single quote returns a MySQL syntax error. The log shows 3,000 requests of event_id=14 AND (SELECT ...) from one IP over 20 minutes, extracting the admin password hash one character at a time.
The hash is cracked offline in an hour because the password was short. Changing the plugin to a prepared query stops the leak, and the owner also resets every user password because wp_users was readable.
How it differs
A CWE is a catalog entry that names a class of weakness, and SQL injection is CWE-89. SQL injection is one weakness in that catalog. Saying 'CWE' tells you the category of flaw; saying SQL injection tells you where and how the input goes wrong.
Common errors
Escaping quotes by hand instead of binding parameters. Protecting only the login form. Trusting numeric parameters without casting. Using a database account that can drop tables or write files. Relying on a WAF rule to hide a vulnerable query.
In practice
Search your code for queries built with string concatenation and move them to prepared statements. Give the application's database user only the tables and verbs it needs. Hash passwords with a slow algorithm so a leak is not an instant breach.