What Is SQL Injection — and Why It's the Worst-Case Vulnerability?

The one-sentence version

SQL injection happens when a website takes something a visitor typed in — a search box, a URL parameter, a form field — and pastes it directly into a database command without checking whether it's actually plain data or a disguised instruction, which lets an attacker write their own database commands and have your site run them.

"SQL" is just the language nearly every website's database understands — it's how a page asks the database for a list of posts, checks a username and password, or saves a comment. Normally, whatever a visitor types is treated purely as data: a search term to look for, not an instruction to obey. SQL injection is what happens when that boundary breaks down, and typed text gets interpreted as part of the command itself.

Why this is worse than most other vulnerability types

Your WordPress database is not just "some data" — it is all of your data. Every post and page, every user account and its password hash, every plugin setting, every option that controls how the site behaves lives in that one database. A vulnerability that lets an attacker read from it, write to it, or run arbitrary commands against it isn't a narrow foothold — it's usually the whole site at once.

That's the practical difference between SQL injection and something like a single misconfigured file permission. A successful SQL injection attack can, in one step, let someone read every password hash in the wp_users table, insert a brand-new administrator account directly into that table (skipping the login form, the password reset flow, and any two-factor check entirely), or quietly rewrite a site option to point somewhere malicious. It goes around the front door because it never needed the front door — it talks to the database directly.

A simple, illustrative example

Imagine a plugin's search feature builds a database query by directly stitching a search term into a string, something conceptually like this:

SELECT * FROM wp_posts WHERE post_title LIKE '%searchterm%'

If searchterm is inserted as-is, an attacker can type something that closes out the quote early and appends their own SQL — turning what was supposed to be a search phrase into a second, attacker-authored command that rides along with the original one. The fix is straightforward in principle: never build a query by pasting raw input into it. Treat the input as a parameter the database driver escapes and substitutes safely, not as literal text glued into the command. WordPress's own database layer, $wpdb, provides exactly this via its prepare() method — the vulnerability almost never comes from WordPress lacking a safe way to do this; it comes from code that bypasses the safe way and builds the query by hand instead.

Why this is almost always a plugin problem, not a WordPress problem

WordPress core's own database queries go through $wpdb and have been hardened and reviewed for this exact class of bug for two decades. Core SQL injection vulnerabilities are rare specifically because that code path gets unusually heavy scrutiny. The overwhelming majority of real-world WordPress SQL injection disclosures are in plugins and themes — independently written, independently reviewed (if at all), and only as careful as whichever developer wrote that particular database query. Any plugin feature that builds a custom query — a search filter, an import tool, a reporting dashboard, a custom shortcode with parameters — is a candidate if it doesn't use $wpdb::prepare() correctly.

A real, current example

In March 2024, a critical unauthenticated SQL injection vulnerability was disclosed in Automatic, a WordPress content-import plugin by ValvePress running on roughly 38,000–40,000 sites at the time — tracked as CVE-2024-27956 (CVSS 9.9 critical, CVSS vector AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L; NIST's NVD entry separately scores it 9.8). The flaw lived in the plugin's _inc/csv.php file: supplying a whitespace character to an authentication parameter let an unauthenticated attacker bypass the plugin's own auth check entirely and inject arbitrary SQL, with no login required at any point.

The impact was exactly what makes SQL injection the worst-case scenario described above. Attackers used the bug to insert new administrator accounts directly into the database, upload malicious files, and establish persistent backdoor access — full site takeover, achieved without ever touching a login form. The vulnerability was patched in version 3.92.1, and — as is typical for this class of bug — public proof-of-concept exploit code appeared shortly after disclosure, which is why patching promptly rather than "eventually" matters so much here.

Blind SQL injection: when there's no visible error to give it away

Not every SQL injection bug announces itself with a broken page or a database error message. In a blind SQL injection, the application's response looks identical whether the injected command succeeded or failed — but an attacker can still extract data one bit at a time by asking the database true/false questions ("does the first character of the admin password hash start with 'a'?") and watching for a subtly different response, or a delay, each time. It's slower than an injection that dumps data directly, but it's just as complete an attack — it just requires patience and automation, both of which off-the-shelf attack tooling supplies for free. The lack of an obvious error on the page is not evidence that a query is safe.

What an attacker actually gets out of it

• Every password hash in the database, which can then be cracked offline at the attacker's leisure, with no rate limiting or lockout to slow them down.
• A new administrator account, inserted directly — bypassing registration settings, login forms, and any brute-force protection entirely, exactly as happened in the Automatic case above.
• The ability to rewrite site options and content directly, including options WordPress trusts implicitly, without going through any of the normal validation a form submission would trigger.

What to actually do about it

• Keep every plugin and theme updated, promptly. Virtually every real WordPress SQL injection incident is a disclosed-and-patched plugin bug, not a novel zero-day. The Automatic case above had a fix available from the day of disclosure — sites still hit were sites that hadn't updated.
• Remove plugins with database-writing features you're not actively using. A deactivated plugin can still be reachable depending on how its vulnerable code is triggered; deleting the ones you don't need removes the exposure rather than just hiding it.
• Be extra cautious with plugins that build custom queries — search tools, import/export utilities, reporting or analytics dashboards, anything with its own filter or lookup logic. These are exactly the features where a developer is most likely to have written a raw query by hand instead of using $wpdb::prepare().