CVE-2026-1357 is a 9.8-rated unauthenticated remote code execution vulnerability in the WPvivid Backup & Migration plugin, installed on roughly 800,000 WordPress sites. An attacker can write a PHP webshell to a publicly accessible directory — no account, no credentials, one HTTP request. From there it's full server access: read any file, modify anything, install persistent backdoors.
The patch is version 0.9.124. If you're on 0.9.123 or earlier, update before reading the rest of this.
How the Exploit Works
WPvivid has a feature for pushing backups between WordPress installations. It's disabled by default. When enabled, it generates a session key to authenticate the transfer. The vulnerability lives in what happens when authentication fails.
The plugin uses RSA encryption to validate incoming transfers. If openssl_private_decrypt() can't decrypt a message — say, because an attacker deliberately sent garbage — it returns false. That return value gets passed directly to phpseclib v1's setKey() method. phpseclib doesn't throw an error. It converts false to a string of 16 null bytes and uses that as the AES decryption key.
Sixteen null bytes. Predictable. Identical across every vulnerable installation on the internet.
An attacker who knows this — and fourteen public proof-of-concept exploits were indexed by the time Wordfence published its technical disclosure — can pre-encrypt any payload with that fixed key and the RSA check collapses entirely. What was supposed to be the authentication barrier becomes decoration.
The second flaw is what happens to the file once the plugin accepts it. The filename comes from the attacker-controlled decrypted payload. The plugin writes it to the filesystem without calling basename(), without checking the extension, and without restricting the output path. A filename like ../uploads/shell.php walks right out of the intended backup directory and into /wp-content/uploads/ — a location that's publicly reachable by any browser. Drop a PHP file there and request its URL. That's arbitrary code execution as the web server process.
The complete attack: one POST to wpvivid_action=send_to_site. No login. No brute force. Nothing.
Who's Actually Exposed
Not all 800,000 installs. The vulnerable feature — "receive backup from another site" — is off by default, and sites that have never run a migration and never touched that setting are not exposed.
The problem is that migrations are common, and the feature doesn't turn itself off when the job is done. Anyone who used WPvivid to move a site and didn't manually disable receive mode afterward is sitting on an open attack surface. Generated session keys expire every 24 hours, but the feature itself stays enabled until someone goes back into settings and turns it off.
Fourteen public PoCs make mass scanning trivial. Assume exploitation is active.
Timeline
Security researcher Lucas Montes reported the vulnerability on January 12, 2026 and collected a $2,145 bug bounty. Wordfence assigned the CVE and pushed a firewall rule to Premium, Care, and Response subscribers on January 22. The plugin maintainers released the patched version — 0.9.124 — on January 28. Full technical disclosure went public on February 10. Free-tier Wordfence users got the firewall rule on February 21, thirty days after Premium.
Nineteen days between patch and disclosure is a reasonable hold. The gap that matters more is the one between "patch available" and "administrator actually runs the update" — historically, that window can stretch for months across a plugin's install base.
What to Do
Update to 0.9.124. That's the fix. Everything below is for people who can't patch immediately or want to know if they were hit before the patch existed.
If updating isn't possible right now: go into WPvivid settings, disable "receive backup from another site," and revoke any active transfer keys. That removes the exposed endpoint until the patch goes in.
To check for exploitation: review server access logs for POST requests to wpvivid_action=send_to_site between January 12 and January 28. Any hits from unexpected sources during that window are worth investigating. Also check /wp-content/uploads/ for PHP files — nothing with a .php extension should exist there. If you find one that you didn't put there, assume compromise.
A server-level IPS like CrowdSec can catch and block exploit attempts against unpatched plugins by pattern-matching the request structure — it doesn't fix the vulnerability but it raises the cost of opportunistic mass exploitation considerably. Similarly, restricting PHP execution in upload directories is a server hardening step that limits blast radius if a webshell does land: the file exists but can't run. Both of these belong in any baseline VPS configuration regardless of what plugins are installed.
The Longer Problem
This isn't the first serious security issue in WPvivid — it's the worst one, but the codebase has 23 documented vulnerabilities in its history: arbitrary file read, arbitrary file download, authenticated file upload, SQL injection, PHP object injection, reflected and stored XSS. The pattern isn't bad luck. It's a plugin that hasn't been built with security as a design constraint.
If WPvivid is in your WordPress stack because you ran a migration six months ago and never uninstalled it, that's a reasonable thing to fix today. A plugin's attack surface doesn't go dormant just because you're done using its features.
CVE-2026-1357 was discovered by Lucas Montes (NiRoX) and assigned a CVSS v3.1 score of 9.8 (Critical). The full technical writeup is available from Wordfence.
