5 Million WordPress Sites Vulnerable to SQL Injection in All-in-One WP Migration

Critical Security Alert: All-in-One WP Migration Vulnerability Overview

On August 14, 2026, security researchers received a vulnerability submission detailing a high-severity flaw in All-in-One WP Migration and Backup, one of the most widely used plugins in the WordPress ecosystem. With more than 5 million active installations globally, any weakness in this plugin presents a massive attack surface across the web.

The reported issue is classified as an Unauthenticated Second-Order SQL Injection vulnerability. Because the flaw requires no prior authentication or administrative privileges to exploit initially, unauthorized actors can potentially target exposed endpoints to inject malicious database payloads, putting site data, administrator accounts, and backend infrastructure at risk.

Understanding Unauthenticated Second-Order SQL Injection

SQL Injection (SQLi) vulnerabilities occur when untrusted user input is directly concatenated or concatenated improperly into raw database queries without adequate sanitization or parameterization. However, a second-order SQL injection is distinct from traditional first-order attacks in how and when the payload executes.

• First-Order SQL Injection: The attacker submits a malicious vector in an HTTP request, and the application immediately uses that payload to execute an unintended query in the same request-response cycle.
• Second-Order SQL Injection: The attacker submits input that is initially stored safely or without triggering immediate syntax execution (e.g., in a database record, option field, or temporary file). The actual execution occurs later when a secondary, separate application process retrieves that stored data and incorporates it unsafely into a subsequent SQL query.

The unauthenticated nature of this specific flaw elevates its severity significantly. Attackers do not need valid login credentials, session cookies, or specific role capabilities (such as Subscriber, Editor, or Administrator) to seed the malicious data into the application flow.

Scope and Risk Assessment for WordPress Administrators

The All-in-One WP Migration and Backup plugin is relied upon by millions of site owners, agencies, and hosting providers to export database tables, media files, plugins, and themes into single-file archives for migration or backup purposes. Because backup plugins fundamentally require extensive permissions to read from and write to the WordPress database (`wp_options`, `wp_users`, `wp_posts`, etc.), vulnerabilities within their codebase carry inherently high execution privileges.

If successfully exploited, an unauthenticated second-order SQL injection could allow remote attackers to:

• Extract sensitive information from the database, including password hashes, personal data, and API keys.
• Modify existing database records or insert new administrative users.
• Bypass authentication mechanisms entirely to gain persistent access.
• In specific database configurations, read arbitrary files or achieve remote code execution (RCE) on the underlying host.

Mechanics of SQL Injection Prevention in WordPress Development

To understand how second-order vulnerabilities occur in custom PHP and WordPress code, it is useful to review safe coding patterns versus unsafe database interaction patterns.

In vulnerable implementations, developer code might retrieve previously stored data and pass it into a raw database execution string, assuming that because the data came from the database itself, it is safe to trust:

// UNSAFE: Assuming retrieved database values are safe to concatenate
$stored_user_input = get_option('ai1wm_temporary_import_meta');
$results = $wpdb->get_results("SELECT * FROM {$wpdb->prefix}posts WHERE post_title = '" . $stored_user_input . "'");

To systematically eliminate second-order SQL injection risks, developers must enforce parameterized queries using the global $wpdb abstraction layer across all query locations, regardless of where the data originated:

// SAFE: Using prepared statements even for internally retrieved data
$stored_user_input = get_option('ai1wm_temporary_import_meta');
$prepared_query = $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}posts WHERE post_title = %s",
    $stored_user_input
);
$results = $wpdb->get_results($prepared_query);

Immediate Incident Response and Remediation Steps

System administrators and website maintainers using All-in-One WP Migration and Backup should immediately perform the following security checks and remediation steps:

1. Update Immediately: Check the WordPress dashboard or WP-CLI for updates to the All-in-One WP Migration and Backup plugin and apply the latest patch provided by the developer.
2. Inspect Plugin Logs and Temporary Storage: Review backup directories and options entries associated with migration processes to check for anomalous records or unexplained export/import attempts.
3. Deploy Web Application Firewalls (WAF): Ensure active endpoint firewalls (such as Wordfence or server-level rules like ModSecurity) are fully updated with rules targeting SQL injection patterns.
4. Audit Database Users: Inspect the wp_users table for unauthorized administrative accounts created around or after August 14, 2026.

Hardening the WordPress Ecosystem Against SQL Attacks

Addressing plugin vulnerabilities requires a defense-in-depth approach to site maintenance. Site managers should implement strict operational controls to mitigate exposure to zero-day and unauthenticated flaws:

• Principle of Least Privilege: Limit database user permissions on the MySQL/MariaDB server level. A WordPress database user rarely requires DROP, GRANT, or file-level privileges during normal operations.
• Automated Vulnerability Scanning: Configure continuous monitoring to alert operations teams immediately when new vulnerabilities are disclosed in installed plugins or themes.
• Staging-Environment Updates: Test security updates in isolated staging environments before rolling them out across mission-critical production sites.

Post-Remediation Verification via WP-CLI

After applying plugin updates, system administrators can verify installed plugin versions and update statuses across single or multi-site installations using the WordPress Command Line Interface (WP-CLI):

# Check the current status and version of All-in-One WP Migration
wp plugin status all-in-one-wp-migration

# Force update the plugin to the latest patched release
wp plugin update all-in-one-wp-migration

# Verify core checksums to ensure database and core files remain intact
wp core verify-checksums

Regular security audits, coupled with rapid patch deployment, remain the primary line of defense against wide-scale SQL injection exploits in popular WordPress plugins.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.