Critical WPvivid Backup Bug (CVE-2026-1357): When “Send to Site” Turns Into Unauthenticated File Upload

WPvivid Backup & Migration is one of those plugins that ends up everywhere-staging, migration, backups, restores. That popularity is exactly why a critical vulnerability like CVE-2026-1357 matters: it was reported as an unauthenticated arbitrary file upload that can be escalated to remote code execution (RCE), the classic path to a full site takeover.

The important nuance: according to the advisory, this issue only becomes critically exploitable on sites where the plugin’s “receive a backup from another site” capability is enabled by generating a key in WPvivid’s settings. That feature is disabled by default, and the key’s expiration can be configured only up to a maximum of 24 hours.

The vulnerability affects WPvivid Backup (plugin slug: wpvivid-backuprestore) in versions <= 0.9.123, and it’s patched in 0.9.124.

Vulnerability summary (Wordfence Intelligence)

• Title: Migration, Backup, Staging <= 0.9.123 - Unauthenticated Arbitrary File Upload
• Severity: CVSS 9.8 (Critical)
• CVE: CVE-2026-1357
• Affected versions: <= 0.9.123
• Patched version: 0.9.124
• Attack precondition: A generated key must exist in plugin settings for receiving backups from another site (feature disabled by default; key expiration max 24 hours).
• Impact: Upload arbitrary files; place PHP in web-accessible locations; trigger Remote Code Execution.

What makes this bug dangerous (and when it’s actually exploitable)

Arbitrary file upload bugs are rarely “just” file upload bugs. If an attacker can upload a .php payload into a publicly reachable directory, execution is typically a single HTTP request away-often followed by a webshell and persistence.

In this case, the exploit path centers on WPvivid’s functionality that lets one WordPress site send a backup to another site. The receiving side uses a short-lived generated key. If your site never enabled that receiving key feature, the advisory notes the vulnerability does not critically impact you in practice.

Root cause: crypto error handling + predictable keying + unsafe paths

The advisory attributes the issue to a combination of three problems:

• Improper error handling in the RSA decryption flow: when a session key decryption fails, the code does not stop execution.
• A predictable encryption key edge case: a failed RSA decrypt results in a boolean false being used where an AES/Rijndael key is expected; the downstream crypto library treats false like a string of null bytes, producing a predictable key scenario attackers can build around.
• Missing path sanitization / unsafe filename handling: filenames coming from the decrypted payload weren’t sanitized, enabling directory traversal out of the intended backup directory and into web-accessible locations.

Put together, the advisory explains an attacker can craft encrypted content using a predictable null-byte key, supply a malicious filename that traverses directories, and then upload arbitrary PHP to a reachable path-leading to RCE.

Where it happens in the plugin

The receiving endpoint is handled in the WPvivid_Send_to_site class via the send_to_site() function. It reads $_POST['wpvivid_content'], loads the key material from the wpvivid_api_token option, and decrypts the payload using WPvivid_crypt.

The advisory also calls out the request parameter used to reach the vulnerable receiving logic: wpvivid_action=send_to_site.

The crypto failure mode (why false matters)

In the affected versions, when the RSA decrypt step fails (e.g., an incorrect key), the decrypted $key can become false. Instead of bailing out, the code proceeds to initialize the Rijndael (AES-like) cipher with that value. The referenced behavior is that the crypto library effectively treats false as a string of null bytes-making the resulting key predictable.

What changed in the patch (0.9.124)

According to the advisory, WPvivid’s fix is twofold:

1. Add a defensive check in decrypt_message() so the function returns early when RSA decryption yields false or an empty value.
2. Add file extension validation in send_to_site() so only expected backup file types can be uploaded.

Patch detail: fail closed on a bad decrypted key

The key hardening is straightforward: if the RSA-decrypted key is false or empty, the function returns false instead of continuing with cipher initialization.

Patch detail: restrict uploads to backup-like extensions

On the upload side, the patch sanitizes the file name using basename() and a conservative character whitelist, then enforces an allow-list of extensions:

• zip
• gz
• tar
• sql

If the extension is not in the allow-list, the function returns an error (Invalid file type - only backup files allowed.) and exits.

Wordfence protection and rollout timing

Wordfence users received mitigation via a firewall rule on different schedules:

• January 22, 2026: Wordfence Premium, Care, and Response users received a firewall rule for added protection.
• February 21, 2026: the same rule is scheduled to reach Wordfence Free users (30 days later).

Action items for site owners and maintainers

1. Update WPvivid Backup & Migration to 0.9.124 (or newer) immediately if you run the plugin.
2. If you use the “send backup to site / receive from another site” workflow, treat this as urgent, because that’s the feature gate that makes exploitation critical.
3. Confirm whether a generated key exists in WPvivid’s settings and review its expiration behavior (the advisory notes expiration can be set only up to 24 hours).
4. If you can’t update right away, reduce exposure by disabling the receiving key feature until you can deploy 0.9.124.
5. If you’re running Wordfence, be aware of the firewall rule timing (Premium/Care/Response vs Free) and don’t treat the firewall as a substitute for patching.

Disclosure timeline (as reported)

• January 12, 2026 – Submission received via the Wordfence Bug Bounty Program.
• January 22, 2026 – Report validated; proof-of-concept confirmed; vendor contacted and invited to use the Wordfence Vulnerability Management Portal.
• January 22, 2026 – Wordfence Premium/Care/Response customers received a firewall rule.
• January 23, 2026 – Vendor responded and opted to use email for disclosure.
• January 23, 2026 – Full disclosure details provided; vendor acknowledged and started working on a fix.
• January 28, 2026 – Patched plugin version 0.9.124 released.
• February 21, 2026 – Wordfence Free users scheduled to receive the same firewall protection.

Why this incident is a good reminder for plugin developers

Even without getting philosophical, this is a textbook example of how security issues tend to be chained rather than singular: a crypto edge case, a failure to halt on errors, and weak file/path handling together turn a “data transfer feature” into an RCE primitive. The patch shows the basics still matter: fail closed on decryption errors, sanitize inputs aggressively, and validate uploads with strict allow-lists.