Backup plugins sit in a uniquely sensitive position on a WordPress site. They have reasons to receive large uploads, they write files to disk. and they frequently include endpoints designed to accept data from other sites. – a “push” from a staging environment, a migration from an old. host, an incremental sync from a parent site. That design surface is exactly whereCVE-2026-1357, a CVSS 9.8 unauthenticated remote code execution flaw inWPvivid Backup & Migration, found its foothold. With more than 900,000 active installations, the plugin is one of the. most broadly deployed backup tools in the ecosystem, and every site running. version 0.9.123 or earlier was reachable by an attacker with nothing more. than an internet connection.
CVE-2026-1357 WPvivid Backup: A Cryptographic Handshake That Failed Open
WPvivid’s site-to-site transfer feature – used when a user chooses to push. a backup from one installation to another – relies on a hybrid. encryption handshake. The sending site encrypts a symmetric AES session key using the receiving. site’s RSA public key, and the receiving site decrypts that session key. with its private key before using it to decrypt the payload that. follows. On paper this is a standard pattern. In WPvivid’s implementation, one small oversight turned the entire scheme into a bypass primitive.
The receiver callsopenssl_private_decrypt()to unwrap the session key. When decryption fails – for example, when the attacker has never actually. obtained the real public key and has simply submitted random bytes -. this function returns.falseand leaves the destination buffer untouched. The vulnerable code did not check the return value. Execution continued, and thefalsevalue was passed directly into the phpseclib AES cipher as if it were a valid key.
CVE-2026-1357 WPvivid Backup: How a Boolean Became a Predictable Encryption Key
phpseclib’s cipher routines coerce their inputs to strings. A PHP booleanfalsecast to a string is an empty string, which the library then. pads or interprets as a key consisting entirely of null bytes. From that moment, the “encrypted” channel between attacker and server was no. longer secret: both sides could derive the exact same all-zero key, because. the attacker knew what would happen when decryption failed. Any payload the attacker encrypted with a null-byte AES key would be. cleanly decrypted by the plugin using the same null-byte key, and the. plugin would treat the result as an authenticated, trusted instruction from a. peer site.
This is the kind of bug that looks innocuous in code review – a missingif ($key === false) return;– but collapses an entire trust boundary. The server believed it was talking to a site that held the matching RSA key. In reality, it was decrypting attacker-chosen plaintext with a key both sides could trivially compute.
From Broken Handshake to Arbitrary PHP on Disk
Bypassing the cryptographic check only gets an attacker into the plugin’s file-receiving routine. The second half of the vulnerability is what that routine did with the filenames it received. The transfer endpoint, reached through thewpvivid_action=send_to_siteparameter, accepted a filename from the decrypted payload and wrote the incoming bytes to disk under the plugin’s upload directory. It did not normalize the path, did not reject../traversal sequences, and did not restrict the extension to known backup formats.
The practical consequence is that an unauthenticated attacker can submit a filename like../../../../wp-content/uploads/shell.phpalong with arbitrary PHP source as the file body. The plugin writes the file. The web server serves it. The attacker now has remote code execution as the PHP user that runs WordPress, which is effectively the site. From there the attacker can readwp-config.php, extract database credentials, create administrator accounts, install persistent backdoors in legitimate theme or plugin files, or exfiltrate customer data.
Preconditions and Blast Radius
Sites face primary risk when the plugin’s “receive backup from another site” capability has been enabled at some point. That option generates a transfer key that remains valid for approximately 24 hours. However, because the cryptographic verification is the broken piece, an attacker does. not need a legitimate key to exercise the file-upload path – they. only need to reach the endpoint with the null-byte-encrypted payload. Any site that has the site-to-site transfer functionality reachable is a candidate.
The impact presents three particular risks for common WPvivid use cases. Agencies running the plugin across client fleets face exposure on every site simultaneously. A single scanner can sweep an entire portfolio. Ecommerce sites using WPvivid for disaster recovery hold order history, customer PII. and payment metadata that an RCE exposes in full. And developers who left the migration feature enabled after a hand-off -. a common oversight – are running a publicly reachable file upload on. behalf of strangers.
The Irony of a Compromised Backup Tool
There is a particular bite to backup plugins being the entry point. These are the tools site owners install expecting a safety net. When the safety net is itself the vector, the attacker has not. only a way in but also, in many cases, access to years. of historical snapshots stored in nearby directories. Those backups often contain full database dumps, API keys committed towp-config.php, and credentials for the very cloud providers the plugin was pushing data to. A successful exploit of CVE-2026-1357 is frequently not a single-site incident; it. is a credential harvest that follows the attacker into Dropbox, Google Drive. amazon S3, and wherever else the plugin shipped offsite backups.
Version 0.9.124 and What Site Owners Should Do
WPvivid’s maintainers released version 0.9.124 on January 28, 2026, with three specific. changes: the plugin now checks the return value of.openssl_private_decrypt()and aborts on failure, filenames from the decrypted payload are sanitized and. resolved before any filesystem write occurs, and uploads now restrict to the expected backup file types (ZIP, GZ, TAR, SQL). The current release at the time of writing is 0.9.125, which layers additional fixes on top. Anything 0.9.123 or earlier is vulnerable and requires an immediate update.
Post-Update Auditing and Remediation
Updating the plugin is the first step but not the only one. Because the vulnerability has had public proof-of-concept code since shortly after disclosure. any site running a vulnerable version for more than a few days should audit as if an attacker may have reached it. That means checkingwp-content/uploadsand the plugin’s backup directory for unexpected.phpfiles, reviewing the administrator user list for accounts that were not created. intentionally, rotating database credentials and any API keys stored in.wp-config.php, and re-issuing tokens for every cloud storage provider the plugin was configured to use. If the site retained backup archives created before the patch, treat those as potentially tampered and rebuild from a known-clean state rather than use for restore.
This is also the class of incident where a vulnerability scanner on the site itself is worth having. Trusti Security’s known vulnerability scanner checks every installed plugin and theme against. a CVE database and flags matches, so a site still running WPvivid. 0.9.123 would show up as a high-severity finding rather than sitting unnoticed. until the next manual audit. The free tier offers on-demand scanning; the premium tier runs the check. on a schedule as often as hourly and can send alerts to. email, Slack, Telegram, or Pushover the moment a vulnerable version appears on the site. For the cleanup phase, the plugin’s core integrity check (premium) compares WordPress. core files against official checksums, which is useful specifically because attackers frequently plant post-exploitation backdoors inside legitimate core files where file-listing audits miss them.
The Lesson Beyond This CVE
CVE-2026-1357 is a clean example of a pattern that keeps appearing in. plugin advisories: the vulnerable code was not the file upload handler, and. it was not obviously the crypto layer either. It was the glue between them – one unchecked return value that let a failed handshake silently succeed. Patching is straightforward; noticing that the patch is needed before an attacker does is the harder problem. Sites that treat plugin version monitoring as continuous rather than occasional are. the ones that close windows like this in hours instead of months.