CVE-2025-5961

What it actually does

The WPvivid Backup & Migration WordPress plugin fails to properly validate uploaded file types in the `wpvivid_upload_import_files` function in versions up to and including 0.9.116. An authenticated user with Administrator-level access can upload arbitrary files into the plugin’s import/upload location. On WordPress deployments served by NGINX, those uploaded files may be directly reachable and executable, enabling remote code execution if a PHP web shell or similar payload is uploaded. Apache deployments are partially protected by the plugin’s `.htaccess` controls in the target upload folder, but the underlying arbitrary upload weakness still exists.

Why it matters to the business

Compromise of an Administrator account on a vulnerable WordPress site can escalate into full server-side code execution, allowing attackers to deface the site, steal data, modify content, deploy malware, create persistence, or use the server for further attacks. Because the exploit is described as weaponized and has a high EPSS probability, organizations running the affected plugin should treat exposure as a priority even though it is not currently listed in CISA KEV and is not specifically associated with ransomware campaigns.

How an attack unfolds

An attacker first obtains WordPress Administrator-level credentials through phishing, credential stuffing, session theft, or abuse of an already-compromised admin account. They then access the WPvivid Backup & Migration plugin’s import upload functionality and submit a file type that should not be accepted, such as a PHP web shell, because the vulnerable `wpvivid_upload_import_files` code path does not enforce sufficient file type validation. If the WordPress site is hosted behind NGINX and the uploaded file is placed in a web-accessible plugin upload directory, the attacker browses directly to the uploaded file and executes server-side commands through it. From there, the attacker can inspect WordPress configuration files, access database credentials, add backdoor users, modify themes or plugins, stage additional tools, exfiltrate content, or pivot further into the hosting environment. On Apache, direct execution from the upload folder is typically impeded by the existing `.htaccess`, reducing practical exploitability but not eliminating the need to patch.

How to fix it

Upgrade the Migration, Backup, Staging – WPvivid Backup & Migration plugin to a version newer than 0.9.116 as soon as the vendor-provided fixed release is available through the WordPress plugin repository or vendor distribution channel. If an immediate upgrade is not possible, disable or remove the plugin until it can be updated. Restrict WordPress Administrator access to trusted users only, enforce MFA, and review all current administrator accounts. On NGINX, add explicit deny rules to prevent execution of PHP or other active content from WPvivid backup/import/upload directories and WordPress upload paths. Consider blocking direct web access to backup/import storage locations entirely. Ensure file permissions prevent the web server user from writing executable code where possible. Apache users should not rely solely on `.htaccess` as a mitigation; patching remains required because the upload validation flaw persists.

How to confirm the fix worked

Confirm the installed WPvivid Backup & Migration plugin version is greater than 0.9.116 or that the plugin has been disabled/removed. In WordPress Admin, review the plugin inventory and update status; on disk, inspect the plugin metadata under `wp-content/plugins/wpvivid-backuprestore/`. Validate web server controls by attempting to access or execute a benign test PHP file placed only in a controlled non-production test location under relevant upload/import directories; execution should be denied. For NGINX, verify configuration blocks PHP execution in WordPress upload, backup, import, and plugin-generated storage directories. Review file system contents for unexpected `.php`, `.phtml`, `.phar`, `.shtml`, or script files in WPvivid-related upload/import paths. Confirm that no unauthorized administrator accounts, suspicious plugins, modified themes, or unknown scheduled tasks remain after remediation.

Typical attack path

1. Acquire or compromise a WordPress Administrator-level account.
2. Log in to the WordPress administrative dashboard.
3. Navigate to WPvivid Backup & Migration import or upload functionality.
4. Upload an arbitrary payload, commonly a PHP web shell disguised as an import-related file.
5. On NGINX-hosted sites, request the uploaded file directly over HTTP/S.
6. Execute commands through the uploaded payload and establish persistence.
7. Access WordPress configuration, database credentials, plugins, themes, and site content.
8. Use the compromised server for data theft, defacement, malware hosting, spam, or further lateral movement.

How to detect it

Investigate both WordPress application activity and host-level artifacts. Review WordPress audit logs, if available, for Administrator users interacting with WPvivid import, migration, restore, or upload features, especially followed by new files appearing on disk. Examine web server access logs for POST requests to WordPress admin AJAX endpoints or WPvivid upload/import actions, followed by GET requests to newly uploaded `.php`, `.phtml`, `.phar`, or other executable files under WPvivid, backup, import, or upload directories. On NGINX-hosted systems, pay particular attention to successful HTTP 200 responses for PHP files in writable directories. Inspect file creation and modification times under `wp-content/plugins/wpvivid-backuprestore/`, `wp-content/uploads/`, and WPvivid backup/import storage paths for executable files, obfuscated PHP, or files with image/archive-like names but PHP content. Review PHP-FPM, web server error logs, EDR telemetry, and process accounting for web server child processes spawning shells or command-line utilities such as `sh`, `bash`, `curl`, `wget`, `python`, `perl`, `nc`, or `chmod`. Check WordPress for new administrator users, unexpected plugin installations, modified theme files, suspicious scheduled tasks, and changes to `wp-config.php`. If known threat actor context is unavailable, treat generic web shell behavior, direct execution from upload paths, and post-authentication admin activity as the primary detection opportunities.

• wpvivid_upload_import_files
• wp-content/plugins/wpvivid-backuprestore/
• wp-content/uploads/wpvivid
• /wp-admin/admin-ajax.php
• action=wpvivid_upload_import_files
• .php in wp-content/uploads/
• /wp-content/uploads/*.php
• /wp-content/uploads/*.phtml
• /wp-content/uploads/*.phar
• /wp-content/plugins/wpvivid-backuprestore/**/*.php
• GET /wp-content/uploads/
• POST /wp-admin/admin-ajax.php
• nginx access log status 200 for PHP under /wp-content/uploads/
• <?php system($_
• <?php shell_exec($_
• <?php passthru($_
• <?php eval($_
• base64_decode(
• gzinflate(
• FilesMan
• WSO_VERSION
• c99shell
• r57shell
• cmd=
• whoami
• uname -a
• /bin/sh
• /bin/bash
• curl http
• wget http

What your security team should do

• Inventory WordPress sites for the WPvivid Backup & Migration plugin and identify any installations running version 0.9.116 or earlier.
• Prioritize remediation for internet-facing WordPress sites, especially those served by NGINX.
• Upgrade the plugin to a fixed version newer than 0.9.116, or disable/remove it until a fixed version is deployed.
• Harden NGINX to deny PHP execution in `wp-content/uploads/`, WPvivid backup/import directories, and other writable web paths.
• Audit WordPress Administrator accounts for unauthorized users, stale accounts, weak credentials, and lack of MFA.
• Search web roots and WPvivid directories for recently created executable files or web shells.
• Review web access logs for direct requests to suspicious uploaded PHP or script files under WPvivid and upload directories.
• Rotate WordPress administrator passwords and relevant hosting/database credentials if exploitation is suspected.
• Check for persistence through rogue plugins, modified theme files, injected admin users, cron jobs, and unexpected PHP files.
• Increase monitoring of vulnerable assets because exploit maturity is weaponized and EPSS is high despite no current KEV listing.