CVE-2021-24155

What it actually does

The Backup Guard WordPress plugin before version 1.6.0 fails to properly validate files imported through its backup import functionality. A user with administrator-level access can upload files that are not valid SGBP backup archives, including PHP scripts. If the uploaded PHP file is placed in a web-accessible location or otherwise executed by WordPress/PHP, the attacker can achieve remote code execution with the privileges of the web server process, enabling full compromise of the WordPress application and potentially the underlying host.

Why it matters to the business

Successful exploitation can allow an attacker who has obtained or controls an administrator account to take over the WordPress site, modify content, steal data, install backdoors, redirect visitors, host malware, or disrupt availability. Although exploitation requires high privileges, the vulnerability is weaponized and has a high EPSS likelihood, so exposed sites running vulnerable plugin versions should be treated as high priority, especially where administrator credentials may be phished, reused, or weakly protected.

How an attack unfolds

An attacker first obtains WordPress administrator-level access through phishing, credential stuffing, password reuse, session theft, or abuse of another vulnerability. After authenticating to the WordPress dashboard, the attacker uses the Backup Guard import or restore functionality to upload a crafted file that the plugin should reject because it is not a valid SGBP backup. Due to insufficient validation in versions before 1.6.0, the plugin accepts the file, including PHP content. The attacker then attempts to locate and invoke the uploaded PHP script through the web server or trigger its execution through WordPress/PHP handling. Once executed, the script can provide command execution, web shell access, persistence, data theft, or further lateral movement from the compromised web server.

How to fix it

Upgrade the Backup Guard plugin to version 1.6.0 or later. If an update is not available through the WordPress dashboard, obtain the fixed version from the official WordPress plugin repository or vendor source. If the plugin is not required, remove it entirely rather than leaving it disabled. Until upgraded or removed, restrict administrator access, enforce MFA for WordPress administrators, review administrator accounts, and block direct execution of PHP files from upload, backup, cache, and temporary directories where feasible through web server configuration. Rotate WordPress administrator passwords and any secrets stored in site configuration if compromise is suspected.

How to confirm the fix worked

Confirm the installed Backup Guard plugin version is 1.6.0 or later from the WordPress admin plugin page, WP-CLI, or filesystem metadata. Verify that no vulnerable plugin copy remains under wp-content/plugins. Perform a controlled validation in a non-production environment by attempting to import a non-SGBP file or PHP file and confirming it is rejected. Review web server configuration to ensure PHP execution is disabled in upload, backup, and temporary directories where possible. Run file integrity checks across the WordPress root for unexpected PHP files, recently modified plugin/theme files, and newly created administrator accounts.

Typical attack path

1. Obtain valid WordPress administrator credentials or an authenticated administrator session.
2. Confirm that the Backup Guard plugin is installed and is a vulnerable version before 1.6.0.
3. Access the plugin’s backup import or restore functionality from the WordPress admin interface.
4. Upload a malicious PHP file or crafted archive that is not a valid SGBP backup file.
5. Identify where the uploaded file was written on disk or exposed through the web server.
6. Request the malicious PHP file or otherwise trigger execution.
7. Use the resulting code execution to deploy a web shell, modify site files, steal configuration secrets, or maintain persistence.

How to detect it

To determine whether exploitation already occurred, review WordPress authentication and administrator activity logs, web server access logs, PHP error logs, file modification timestamps, endpoint telemetry, and backup/plugin operation logs where available. Look for successful administrator logins from unusual IP addresses or user agents, followed by backup import or restore actions, file uploads, and HTTP requests to PHP files in upload, backup, temporary, cache, or plugin data directories. Inspect the WordPress filesystem for recently created PHP files outside expected plugin/theme/core locations, obfuscated PHP code using functions such as eval, base64_decode, gzinflate, shell_exec, system, passthru, or assert, and modified wp-config.php, theme files, plugin files, or .htaccess files. Check for newly created WordPress administrator users, unexpected scheduled tasks, suspicious outbound connections from the web server, and web shell behavior such as command parameters in HTTP requests. Because exploitation requires admin privileges, correlate suspicious file activity with privileged account access, including logins from unfamiliar geographies, impossible travel, repeated failed logins followed by success, or reused sessions.

• /wp-content/plugins/backup/
• /wp-content/plugins/backup-guard/
• /wp-content/uploads/backup-guard/
• /wp-content/uploads/sg-backup/
• /wp-content/uploads/*.php
• /wp-content/backup*.php
• /wp-content/*/backup*.php
• POST /wp-admin/admin-ajax.php
• POST /wp-admin/admin.php
• GET /wp-content/uploads/
• GET /wp-content/uploads/*.php
• eval(
• base64_decode(
• gzinflate(
• shell_exec(
• passthru(
• system($_
• assert($_
• cmd=
• exec=
• /wp-admin/plugin-install.php
• /wp-admin/plugins.php

What your security team should do

• Prioritize upgrade or removal of Backup Guard versions before 1.6.0 because exploitation is weaponized and EPSS is high.
• Audit WordPress administrator accounts, remove unused admins, enforce MFA, and reset passwords for privileged users.
• Search web roots and WordPress content directories for unexpected PHP files, especially recently created or modified files near backup, upload, restore, cache, or temporary paths.
• Review access logs for administrator logins followed by backup import activity and subsequent requests to newly uploaded PHP files.
• If suspicious files are found, preserve forensic evidence, isolate the host, rotate credentials and database secrets, and restore from a known-good backup.
• Add detection rules for PHP execution from wp-content/uploads, backup-related directories, and other locations that should not execute server-side code.
• Maintain plugin inventory across WordPress sites and alert on vulnerable or abandoned plugins.