SQL Injection in WordPress, Explained
What SQL injection is, why WordPress plugins keep producing it, and what it means when your site has one.
SQL injection is what happens when data you supply gets treated as instructions. It has been the best-understood web vulnerability class for two decades, and WordPress plugins still produce a steady supply of it.
The mechanism, without code
A plugin builds a database query as a string, dropping in a value that arrived from the request — a search term, an ID, a username. If that value is inserted without being escaped or bound, an attacker can supply something that changes the meaning of the query rather than filling in a blank. The database, which cannot tell the difference, complies.
Why WordPress plugins keep getting it wrong
- WordPress provides
$wpdb->prepare(), but it is opt-in. Nothing forces a developer to use it. - Copy-pasted patterns from years-old tutorials and older versions of large plugins propagate the unsafe form.
- Custom tables — analytics, logs, carts, form entries — get less scrutiny than core tables.
- Values that “cannot be dangerous” often are: usernames on a failed login, a referrer, a cart identifier.
Two real examples from this archive
Loginizer < 1.6.4 logged the submitted username on a failed login without neutralising it — unauthenticated injection on the one page every WordPress site exposes, serious enough that WordPress force-updated over a million sites. Abandoned Cart Lite ≤ 5.8.2 put visitor-supplied cart parameters into queries against tables holding customer names and email addresses.
What it means if your site has one
- Read access to anything the WordPress database user can see, including password hashes and email addresses.
- On some configurations, write access — new administrator accounts, injected content.
- A personal-data breach with notification duties if customer data is involved.
What to do
Update to the patched version; where none exists, disable or replace the component. Then rotate administrator passwords, because hashes may already be gone. Hardening does not fix an injection — only the patch does.
Want this checked automatically across every plugin, theme and core file on your site? WPDeeply Risk Monitor is free.
