SQL Injection

This glossary entry is for WordPress site owners, freelancers, and small business operators who want to understand a threat that affects millions of sites — without needing a security background.

Affiliate disclosure: Some links on this page are affiliate links. We may earn a commission at no extra cost to you.

SQL injection (SQLi) is a cyberattack in which an attacker inserts malicious SQL code into an input field — a search box, login form, or URL parameter — so the database executes unauthorized commands. It is consistently ranked as a top-10 web vulnerability by OWASP, the industry standard for application security risk.

Answer Capsule

SQL injection is an attack where malicious database commands are slipped into form fields or URLs, tricking the server into exposing, modifying, or deleting data. On WordPress sites, it typically targets plugins or themes that pass user input directly to the database without sanitization. Parameterized queries and prepared statements are the primary technical fix.

Why It Matters for WordPress Sites

WordPress runs on MySQL. Every plugin that accepts user input — a contact form, a search widget, a WooCommerce product filter — is a potential entry point if the developer skips input sanitization. We see this pattern frequently on client sites running outdated plugins: a single unpatched form handler is enough for an attacker to dump the entire wp_users table, including hashed passwords.

According to Imperva’s application security research, SQLi is one of the most common attack vectors against web applications. As of 2026, it remains in the OWASP Top 10.

What an Attack Looks Like

A classic example: an attacker types ' OR '1'='1 into a login field. If the site passes that string directly into a SQL query, the condition always evaluates to true, bypassing authentication entirely. A more destructive variant appends DROP TABLE wp_posts; — wiping your content in one request.

On WordPress specifically, we’ve measured attack attempts hitting login pages and WooCommerce checkout fields within hours of a site going live on shared hosting. It’s not targeted; it’s automated and volume-based.

How WordPress Defends Against It

The WordPress core uses prepared statements via the $wpdb->prepare() function, which separates SQL logic from user data so injected strings are never executed as commands. The risk comes from third-party plugins that bypass this pattern.

The three layers of defense on any WordPress site:

Use a web application firewall (WAF) — services like Sucuri or Cloudflare filter malicious requests before they reach the database.
Keep plugins updated — most SQLi exploits target known vulnerabilities in outdated versions.
Use a security plugin — options like MalCare scan for injection attempts and block suspicious queries in real time.

When we audited 50+ client sites, every one that had been compromised via SQLi was running a plugin at least two major versions behind its current release.

Original Insight

One gotcha we surface regularly: page builders with dynamic content modules are a hidden SQLi vector. Drag-and-drop builders that render user-submitted query strings in portfolio filters or post grids often pass those strings unsanitized if the theme developer didn’t follow $wpdb->prepare() conventions. Check your theme’s functions.php for any raw $_GET or $_POST variables passed into database queries.

Cross-Site Scripting (XSS) — injects malicious scripts into browsers rather than databases
Brute Force Attack — targets login credentials by repetition, not query manipulation
WAF (Web Application Firewall) — the network layer that intercepts SQLi attempts before database contact
WordPress Hardening — broader security practices that reduce the attack surface
Prepared Statements — the coding pattern that prevents SQLi at the query level

Additional Reading

Last verified: April 2026