WordPress Guide → Security → SQL Injection Attack

WordPress security basics: What is an SQL injection attack?

WordPress, along with most other content management systems, uses a database to store state. State is the things the content management system knows about, including the content and its organization, and user data. There are many different types of database, but WordPress uses one of the most popular open source SQL-based databases, MySQL.

SQL is a language used to build the databases tables, to put data in them, and to get data out. It looks like this:

INSERT INTO TABLE VALUES (13, 'Phoenix', 'AZ', 33, 112);

As you can imagine, it’s important to make sure only authenticated people and programs are allowed to make queries to a WordPress site’s database. If an attacker can send SQL to the database, they can delete, create, or modify data — and that data is WordPress’s view of its world.

SQL Injection (SQLi) is a type of attack where an attacker exploits a vulnerability in a website’s software (in this case, WordPress) by inserting or injecting malicious SQL code into a web form or URL query. This can allow the attacker to interact with the database in unintended ways, often gaining unauthorized access to sensitive data or manipulating the data stored in the database.

In WordPress, SQL injection vulnerabilities typically occur when user input is not properly sanitized or validated before being used in SQL queries. Since WordPress relies heavily on databases to store and retrieve content (posts, pages, comments, user data, etc.), improper handling of user input can allow attackers to craft malicious SQL queries that manipulate the database, gain unauthorized access, or even execute administrative commands.

Of course, there are many safeguards in place to stop this happening. The database will ignore requests from unauthorized sources. But the content management system needs to be able to make changes to the database.

WordPress stands between the user and the database. Authorized users interact with WordPress, and WordPress sends information to the database. Users never send requests direct to the database.

However, sometimes developers make mistakes. Imagine a developer creates an input box on a WordPress site so that users can enter their email, which is sent to the database to be stored. The only thing the input box should allow to be sent to the database is a valid email address. But a malicious user might try to use the input box to send something different, like an SQL query.

The vast majority of the time, input like that is rejected by validation in the browser, and made safe by escaping and sanitization. If the attacker is very lucky, the developer may have made a mistake, allowing the SQL to be sent directly to the database, which is definitely not something we want to happen.

WordPress-specific SQL injection risks

There are a few WordPress-specific factors that can increase the risks of SQL injection attacks:

• Dynamic query generation: WordPress frequently uses dynamic queries, especially in plugins or themes. For example, queries to fetch posts, users, or comments may not always sanitize input or prepare statements correctly. This could expose the site to SQL injection attacks if malicious input is not properly filtered.
• Plugin vulnerabilities: Many WordPress websites rely on third-party plugins. If a plugin is poorly coded or not updated regularly, it may introduce SQL injection vulnerabilities. Some plugins fail to properly validate or escape user input in SQL queries, making them a common target for attackers.
• Themes: Like plugins, poorly written themes can also introduce vulnerabilities. For example, custom themes that directly interact with the database and do not sanitize user input could expose a website to SQL injection risks.
• Admin panel vulnerabilities: The WordPress admin panel itself may be vulnerable if there is improper sanitization of inputs in admin pages. Attackers could inject malicious queries through form fields or URL parameters, gaining access to sensitive data, such as user accounts, posts, or even options that control the site.
• Search functionality: WordPress sites often have built-in search functions that rely on SQL queries to return results. If these queries are not properly sanitized, attackers can modify search parameters to manipulate the database.
• Weak database permissions: WordPress websites often run on MySQL databases with wide-ranging permissions for the application user. If the database user account has more privileges than necessary (for example, administrative privileges), an attacker can use SQL injection to escalate their access to the system.
• No prepared statements: Many older or poorly coded WordPress themes and plugins may use traditional SQL queries without prepared statements or parameterized queries. These are much more vulnerable to SQL injection because they do not separate SQL logic from user input.

Real-world examples of WordPress SQL injection incidents

In 2022, a major security flaw (CVE-2022-21661) was discovered in WordPress’s core code. This vulnerability allowed attackers who were not logged in (unauthenticated) to access and extract sensitive information from WordPress’s database, which could include user details or site configuration. This is a serious security concern, especially for websites that don’t regularly update their WordPress installation.

Later, in 2024, a vulnerability (CVE-2024-27956) was found in the Automatic plugin used by many WordPress sites. This bug affected around 38,000 websites. While details are sparse, such vulnerabilities can lead to attackers compromising those sites, potentially by accessing private data or modifying site functionality.

Additionally, a vulnerability (CVE-2024-2879) was found in the LayerSlider plugin, which is widely used for creating slideshows on WordPress websites. With a CVSS rating of 9.8 (out of 10), this is considered critical. The high rating indicates that it was an extremely dangerous flaw, which could allow attackers to exploit the plugin and gain unauthorized access to the database or compromise the site further.

Different types of SQL injection

In-band SQL injection (classic SQL injection)

This is the most common type of SQL injection, where the attacker uses the same communication channel (or band) to both launch the attack and gather the results:

• Error-based SQL injection: The attacker forces the database to generate an error message that reveals details about the structure of the database. For example, by passing a malformed query, the attacker might expose database column names or other critical information.
• Union-based SQL injection: This type of attack allows the attacker to combine the results of the original query with results from a second query using the UNION SQL operator. The attacker tries to retrieve additional information, such as database version, table names, or user data, by carefully crafting the queries.

Blind SQL Injection

Blind SQL injection occurs when the attacker does not receive direct feedback or error messages from the database. Instead, the attacker must infer information based on the behavior of the application:

• Boolean-based (content-based) blind SQL injection: The attacker sends a query that asks a question, and based on whether the application responds with a true or false result (e.g., displaying a page or not), the attacker infers details about the database structure or the data. For example, by asking if the first character of a username is ‘a’, the attacker can learn character-by-character.
• Time-based blind SQL injection: In this type, the attacker sends a query that causes a delay (e.g., using the SLEEP() function). The attacker then measures the response time. If the response time is increased, it indicates that the condition in the query was true. By making multiple queries, they can gather information about the structure or contents of the database.

Out-of-band SQL injection

Out-of-band SQL injection occurs when the attacker cannot directly retrieve data from the web application. Instead, the attacker induces the database to send the data to a different server or channel that the attacker controls (for example, via DNS requests or HTTP requests).

The attacker may use a technique like xp_cmdshell (in MS SQL Server) to execute commands or retrieve information indirectly.

This type of injection is less common because it requires more complex configurations and specialized setup, such as a system that allows DNS or HTTP requests initiated from within the database.

Second-order SQL injection

In a second-order SQL injection, the attacker injects malicious SQL code that doesn’t execute immediately. Instead, it stores data in a database field (such as in a user’s profile or a comment). Later, when that data is used in another query, the malicious SQL is executed.

For example, an attacker might input a payload like ‘; DROP TABLE users; — in a form field. This payload does not execute immediately but could execute later when that data is used in a different context.

Stored procedure injection

In this type of attack, an attacker manipulates a stored procedure (a precompiled SQL query) to execute malicious SQL commands. The attacker can either modify an existing stored procedure or inject their own SQL code into one, leading to unauthorized access or manipulation of data.

SQL injection via HTTP request

Some SQL injection attacks are carried out through HTTP request parameters, such as URL parameters, cookies, or HTTP headers. Attackers manipulate these parameters to influence the SQL query in a harmful way.

Tautology-based SQL injection

A tautology is a statement that is always true. In a tautology-based SQL injection, the attacker inserts a condition that is always true into the SQL query (e.g., OR 1=1). This can allow unauthorized access to data, such as retrieving all user records from a database.

Piggy-backed queries (AKA stacked queries)

Piggy-backed queries, or stacked queries, allow an attacker to execute multiple SQL commands in a single query. For example, an attacker could inject an additional SQL statement that would execute after the original query. This type of attack requires that the SQL query execution environment allows multiple queries to be executed in one go, which is less common in modern applications.

How to prevent SQL injections

Use prepared statements and parameterized queries

WordPress provides a $wpdb class to interact with the database in a secure way. Using prepared statements and parameterized queries ensures that user input is treated as data, not executable code. WordPress supports this by using methods like $wpdb->prepare().

Example:

global $wpdb; $results = $wpdb->get_results( $wpdb->prepare( "SELECT * FROM wp_users WHERE user_login = %s", $user_login ) );

In the example above, the %s placeholder is used to safely insert the $user_login variable into the query, preventing SQL injection.

Sanitize and escape user input

Always sanitize user input before using it in SQL queries. WordPress provides functions like sanitize_text_field(), sanitize_email(), and esc_sql() for different types of input. This ensures that only safe data is passed to the database.

Example:

$user_input = sanitize_text_field( $_POST['user_input'] ); $query = $wpdb->prepare( "SELECT * FROM wp_table WHERE column = %s", $user_input ); $wpdb->get_results( $query );

Use WordPress functions to access the database

WordPress provides secure methods to interact with the database, like $wpdb->get_results(), $wpdb->get_var(), $wpdb->insert(), and $wpdb->update(). Always prefer these methods over raw SQL queries to minimize the risk of SQL injection.

Limit database permissions

Ensure that your database user has the least privileges necessary for your application. For example, if your website doesn’t need the ability to delete records, avoid giving the database user DELETE permissions. This limits the potential damage from a successful SQL injection attack.

Use WordPress security plugins

Many security plugins help mitigate SQL injection attacks. Some popular security plugins for WordPress are Wordfence, Sucuri Security, and iThemes Security. These plugins provide features like firewall protection, database query monitoring, and intrusion detection.

Keep WordPress, themes, and plugins updated

Outdated WordPress versions, themes, and plugins often contain security vulnerabilities that can be exploited by attackers. Regularly update WordPress core, your themes, and plugins to protect your site from known exploits.

Disable direct database access

If your WordPress site does not require certain database actions (such as direct modification or access to sensitive data), it is a good idea to disable unnecessary features or harden access to those features. For example, avoid allowing users to upload PHP files to your server, which could be used to execute harmful SQL queries.

Use a Web Application Firewall (WAF)

A Web Application Firewall (WAF) helps protect your WordPress site by filtering out malicious requests, including SQL injection attempts. You can either use a cloud-based WAF (e.g., Cloudflare or Sucuri) or install one on your server.

Use HTTPS

Using HTTPS (SSL/TLS encryption) ensures that all data transmitted between the user’s browser and your server is encrypted. While this doesn’t directly prevent SQL injections, it does prevent attackers from intercepting data (like form submissions) that might contain malicious input.

Monitor and audit database queries

Regularly review and audit the queries running on your site. Monitoring can help identify suspicious activity or potentially harmful database queries, allowing you to respond quickly to any threats.

WordPress security best practices

In general, you should implement the following best practices to keep your site error-free and safe from malicious attacks:

Change your database prefix from the default ‘wp_’

WordPress uses a default prefix (wp_) for its database tables. If a hacker knows this, it makes it easier for them to target your database. Changing the prefix to something unique (e.g., xyz_) makes it more difficult for attackers to guess the structure of your database and attempt SQL injections or other malicious actions.

Configure your site to hide the WordPress version number

WordPress often displays its version number in the page source code. If an attacker knows which version of WordPress you’re using, they can search for known vulnerabilities for that specific version. Hiding or removing the WordPress version prevents attackers from easily identifying the version and targeting specific weaknesses related to it.

Implement strict user permissions following the principle of least privilege

The principle of least privilege means giving users only the minimum level of access they need to perform their tasks. For example, if a user only needs to create content, they shouldn’t have administrative privileges that allow them to install plugins or edit core settings. This reduces the risk of accidental or intentional damage by users with too much access.

Perform regular database maintenance to remove unnecessary data

Over time, WordPress databases can accumulate unnecessary data, like old revisions, spam comments, or unused tables. This clutter could potentially be exploited by attackers. Regularly cleaning your database helps keep it optimized, reducing the attack surface and improving performance.

Never use nulled (pirated) plugins or themes

Nulled plugins or themes are pirated versions that are often distributed for free. These files may contain hidden malicious code, known as “backdoors,” that can be used to exploit your site. It’s important to only use trusted sources to obtain plugins and themes, such as the official WordPress repository or well-known developers, to avoid these risks.

Enable Two-Factor Authentication (2FA) for all administrative accounts

2FA adds an extra layer of security beyond just the username and password. With 2FA enabled, users are required to enter a code sent to their phone or generated by an app, in addition to their password. This makes it much harder for attackers to access administrative accounts, even if they have stolen the password.

Getting started with WordPress security basics

SQL injection vulnerabilities are rare, but serious. From the perspective of the average WordPress user, the best way to avoid SQL injection attacks is to only install themes and plugins from trusted sources, and ensure that the WordPress site and its plugins are regularly updated — updating will fix any SQL injection vulnerabilities that have been discovered and reported to WordPress and plugin developers.