CVE-2025-10726: WPRecovery WordPress Plugin SQLi Vulnerability

CVE-2025-10726 Overview

CVE-2025-10726 is a critical SQL Injection vulnerability affecting the WPRecovery plugin for WordPress in all versions up to and including 2.0. The vulnerability exists in the data[id] parameter due to insufficient escaping of user-supplied input and inadequate preparation of SQL queries. This flaw allows unauthenticated attackers to inject malicious SQL queries that can extract sensitive database information. More critically, the SQL injection output is passed directly to PHP's unlink() function, enabling attackers to delete arbitrary files on the server by injecting file paths through the crafted SQL query.

Critical Impact

Unauthenticated attackers can exploit this SQL Injection vulnerability to extract sensitive database information and delete arbitrary files on the server, potentially leading to complete site compromise and data destruction.

Affected Products

• WPRecovery Plugin for WordPress version 2.0 and earlier
• WordPress installations with WPRecovery plugin enabled
• All websites using vulnerable WPRecovery plugin versions

Discovery Timeline

• 2025-10-03 - CVE-2025-10726 published to NVD
• 2025-10-06 - Last updated in NVD database

Technical Details for CVE-2025-10726

Vulnerability Analysis

This vulnerability combines two dangerous security flaws in a single attack chain. The primary issue is a classic SQL Injection vulnerability resulting from improper input handling in the data[id] parameter. The plugin fails to properly escape user-supplied input before incorporating it into database queries, and does not utilize parameterized queries or prepared statements.

What elevates this vulnerability to critical severity is the secondary file deletion capability. After the SQL query executes, its result is passed directly to PHP's unlink() function without validation. This creates a chained attack scenario where an attacker can manipulate the SQL query to return arbitrary file paths, which are then deleted from the server filesystem.

The attack requires no authentication, meaning any remote attacker with network access to a vulnerable WordPress installation can exploit this vulnerability. The combination of data exfiltration through SQL Injection and arbitrary file deletion capabilities makes this a particularly severe threat to affected systems.

Root Cause

The root cause is twofold: First, the plugin does not properly sanitize or escape the data[id] parameter before using it in SQL queries, violating secure coding practices for database interactions. Second, the plugin inappropriately trusts the output of the SQL query when passing it to the unlink() function, creating an insecure data flow between the database layer and filesystem operations. The vulnerable code can be found in the delete_backup.php file, specifically around line 5 in version 2.0.

Attack Vector

The attack is executed over the network without requiring any authentication or user interaction. An attacker can craft malicious HTTP requests containing SQL injection payloads in the data[id] parameter. The injected SQL can be designed to either extract sensitive information from the WordPress database (including user credentials, plugin configurations, and site data) or to return specific file paths that will subsequently be deleted by the unlink() function.

The file deletion capability is particularly dangerous as attackers could target critical WordPress files such as wp-config.php, rendering the site inoperable, or delete security plugins and logs to cover their tracks during a broader attack campaign.

Detection Methods for CVE-2025-10726

Indicators of Compromise

• Unusual HTTP requests to WPRecovery plugin endpoints containing SQL metacharacters (quotes, semicolons, UNION statements)
• Unexpected file deletions in WordPress installation directories
• Database query logs showing malformed or injected SQL statements targeting WPRecovery tables
• Web server access logs with suspicious data[id] parameter values containing encoded or plain SQL syntax

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect SQL injection patterns in requests to /wp-content/plugins/wprecovery/ endpoints
• Monitor file integrity on critical WordPress files using tools like AIDE or Tripwire
• Enable and review MySQL/MariaDB query logging for anomalous query patterns
• Deploy intrusion detection systems with signatures for SQL injection attack patterns

Monitoring Recommendations

• Configure real-time alerting for any access to delete_backup.php with suspicious parameter patterns
• Establish baseline file counts and monitor for unexpected file deletions in WordPress directories
• Implement database activity monitoring to detect bulk data extraction attempts
• Review web server logs regularly for requests containing SQL injection indicators targeting plugin endpoints

How to Mitigate CVE-2025-10726

Immediate Actions Required

• Immediately deactivate and remove the WPRecovery plugin from all WordPress installations running version 2.0 or earlier
• Audit WordPress databases for signs of unauthorized data access or modification
• Verify integrity of WordPress core files and restore any deleted files from clean backups
• Review server access logs to determine if exploitation has already occurred

Patch Information

As of the last update, users should check the Wordfence Vulnerability Report for the latest patch availability information. If no patched version is available, the plugin should remain deactivated until a security update is released. The vulnerable code is located in the plugin's delete_backup.php and index.php files.

Workarounds

• Remove or deactivate the WPRecovery plugin entirely until a patched version is released
• Implement WAF rules to block requests containing SQL injection patterns to WPRecovery endpoints
• Restrict access to the /wp-content/plugins/wprecovery/ directory using web server configuration
• Use WordPress security plugins with virtual patching capabilities to protect against SQL injection attacks on this endpoint

# Apache .htaccess rule to block access to vulnerable plugin
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^wp-content/plugins/wprecovery/delete_backup\.php - [F,L]
</IfModule>

# Nginx configuration to block access
location ~* /wp-content/plugins/wprecovery/delete_backup\.php {
    deny all;
    return 403;
}