Kritische File-Upload-Lücke in WPvivid Backup: Bis zu 800.000 WordPress-Installationen potenziell betroffen

Im WordPress-Ökosystem sind Backup-Plugins oft der letzte Rettungsanker – und gleichzeitig ein attraktives Ziel. Für das Plugin WPvivid Backup & Migration (WordPress.org-Slug: wpvivid-backuprestore) wurde eine kritische Arbitrary-File-Upload-Schwachstelle gemeldet, die bei erfolgreicher Ausnutzung in Remote Code Execution (RCE) und damit typischerweise in einer vollständigen Website-Übernahme endet.

Wichtig für die Einschätzung: Laut Analyse betrifft das Problem vor allem Installationen, bei denen in den Plugin-Einstellungen ein Schlüssel („generated key“) erzeugt wurde, um von einer anderen Website ein Backup auf diese Website zu übertragen. Diese Funktion ist standardmäßig deaktiviert, und die Ablaufzeit des Keys lässt sich nur bis maximal 24 Stunden konfigurieren.

Kurzüberblick: CVE, betroffene Versionen, Fix

• Schwachstelle: Unauthenticated Arbitrary File Upload
• CVE: CVE-2026-1357
• CVSS: 9.8 (Critical)
• Betroffene Versionen: ≤ 0.9.123
• Gefixte Version: 0.9.124
• Angriffsvektor laut Advisory: über den Parameter wpvivid_action=send_to_site

Warum das kritisch ist: Unauthentifizierter Upload bis hin zu RCE

Ein „Arbitrary File Upload“ ist in WordPress-Kontexten fast immer eine der unangenehmsten Klassen von Bugs: Wenn Angreifer beliebige Dateien hochladen können – insbesondere PHP-Dateien – ist der Schritt zum Ausführen von Code auf dem Server meist klein. In der Praxis sieht man danach häufig Webshells, Persistenz-Mechanismen und weitere Nachlade-Stufen.

Bei dieser Lücke geht es explizit um nicht angemeldete Angreifer (unauthenticated). Das erhöht den Druck, weil kein bestehendes Konto (z. B. Subscriber) benötigt wird – sofern die betroffene Funktionalität auf der Site aktiv und erreichbar ist.

Was genau passiert technisch? (Analyse der Ursache)

WPvivid bringt u. a. eine Funktion mit, um Backups von einer anderen Site zu empfangen. Dafür wird ein kurzlebiger Key generiert. In der untersuchten Implementierung übernimmt die Methode send_to_site() (Klasse WPvivid_Send_to_site) das Entgegennehmen der Daten, wenn im Request wpvivid_content übergeben wird und eine passende Konfiguration (wpvivid_api_token) existiert.

Im Kern wird der Payload entschlüsselt. Der Knackpunkt: Bei der RSA-Entschlüsselung des Session-Keys kann etwas schiefgehen – und genau dort greift eine Kombination aus fehlerhafter Fehlerbehandlung und fehlender Pfad-/Dateiname-Sanitization.

1) Fehlerbehandlung bei RSA-Decrypt führt zu „Null-Byte-Key“

Laut Advisory kann der RSA-Decryption-Step (u. a. via openssl_private_decrypt() bzw. im gezeigten Codepfad via phpseclib Crypt_RSA()->decrypt()) fehlschlagen. Statt die Verarbeitung sauber abzubrechen, wird ein Boolean false weitergereicht. In der nachfolgenden AES-/Rijndael-Initialisierung (phpseclib Crypt_Rijndael) wird dieses false von der Library als String aus Null-Bytes interpretiert – faktisch ein vorhersehbarer Schlüssel.

Dadurch entsteht ein ungünstiger Effekt: Ein Angreifer kann den weiteren Payload so konstruieren bzw. verschlüsseln, dass er mit diesem vorhersagbaren Null-Byte-Key entschlüsselt wird. Das macht die Schutzannahme „Ohne korrekten Key kein gültiger Inhalt“ angreifbar.

2) Dateiname aus entschlüsseltem Payload + fehlende Sanitisierung = Directory Traversal

Zusätzlich akzeptiert die betroffene Logik Dateinamen aus dem entschlüsselten Payload, ohne sie ausreichend zu bereinigen. Das ermöglicht Directory Traversal (z. B. über ../), wodurch Angreifer aus dem eigentlich vorgesehenen Backup-Verzeichnis „ausbrechen“ können. Ergebnis: Dateien lassen sich in öffentlich erreichbare Verzeichnisse schreiben – und wenn das eine PHP-Datei ist, ist der Weg zur RCE offen.

Das Advisory beschreibt außerdem, dass in der anfälligen Implementierung keine Checks auf Dateityp oder Dateiendung vorhanden waren. Genau das macht Arbitrary-Upload-Bugs meist so fatal: Es gibt keinen zusätzlichen Filter, der das Hochladen ausführbarer Dateien verhindert.

So wurde es gefixt: Abbruch bei ungültigem Key + Whitelist für Dateiendungen

Der Hersteller hat den Fix in zwei zentralen Punkten umgesetzt:

1. In decrypt_message() wird der entschlüsselte Key jetzt geprüft. Wenn decrypt() false liefert oder der Key leer ist, wird sauber abgebrochen und false zurückgegeben – statt mit einem impliziten Null-Byte-Key weiterzumachen.
2. In send_to_site() wurde eine Dateiendungsprüfung ergänzt. Der Dateiname wird u. a. über basename() reduziert und per preg_replace('/[^a-zA-Z0-9._-]/', '', ...) bereinigt. Zusätzlich gibt es eine Whitelist erlaubter Endungen: zip, gz, tar, sql. Alles andere wird mit einer Fehlermeldung abgelehnt.

$key = $rsa->decrypt($key);
if ($key === false || empty($key))
{
    return false;
}
$rij = new Crypt_Rijndael();
$rij->setKey($key);
return $rij->decrypt($data);

$key = $rsa->decrypt($key);
if ($key === false || empty($key))
{
    return false;
}
$rij = new Crypt_Rijndael();
$rij->setKey($key);
return $rij->decrypt($data);

$safe_name = basename($params['name']);
$safe_name = preg_replace('/[^a-zA-Z0-9._-]/', '', $safe_name);
$allowed_extensions = array('zip', 'gz', 'tar', 'sql');
$file_ext = strtolower(pathinfo($safe_name, PATHINFO_EXTENSION));
if (!in_array($file_ext, $allowed_extensions, true))
{
    $ret['result'] = WPVIVID_FAILED;
    $ret['error'] = 'Invalid file type - only backup files allowed.';
    echo wp_json_encode($ret);
    die();
}

$safe_name = basename($params['name']);
$safe_name = preg_replace('/[^a-zA-Z0-9._-]/', '', $safe_name);
$allowed_extensions = array('zip', 'gz', 'tar', 'sql');
$file_ext = strtolower(pathinfo($safe_name, PATHINFO_EXTENSION));
if (!in_array($file_ext, $allowed_extensions, true))
{
    $ret['result'] = WPVIVID_FAILED;
    $ret['error'] = 'Invalid file type - only backup files allowed.';
    echo wp_json_encode($ret);
    die();
}

Was du jetzt konkret tun solltest (Checkliste)

1. Prüfe, ob das Plugin WPvivid Backup & Migration auf der Site aktiv ist (Slug: wpvivid-backuprestore).
2. Prüfe die installierte Version: Wenn ≤ 0.9.123, besteht Handlungsbedarf.
3. Update auf 0.9.124 (gepatchte Version laut Advisory).
4. Wenn du die Funktion zum Empfangen von Backups von anderen Sites nutzt: Prüfe, ob in den Einstellungen ein generated key aktiv/zuletzt aktiv war, und bewerte das Risiko entsprechend (Feature ist standardmäßig aus, Key-Lifetime max. 24 Stunden).
5. Wenn du Wordfence einsetzt: Beachte, dass laut Bericht Premium/Care/Response am 22. Januar 2026 eine Firewall-Regel erhalten haben; Wordfence Free soll die Regel 30 Tage später, am 21. Februar 2026, bekommen.

Disclosure Timeline (laut Bericht)

• January 12, 2026 – Einreichung der Arbitrary-File-Upload-Schwachstelle über das Wordfence Bug Bounty Program.
• January 22, 2026 – Validierung und Bestätigung des Proof-of-Concept; Erstkontakt an den Hersteller inkl. Hinweis auf das Wordfence Vulnerability Management Portal.
• January 22, 2026 – Firewall-Regel für Wordfence Premium/Care/Response wird ausgerollt.
• January 23, 2026 – Hersteller antwortet und wählt E-Mail als Kanal für die weitere Kommunikation.
• January 23, 2026 – Vollständige Disclosure-Details werden an den Hersteller gesendet; Fix wird begonnen.
• January 28, 2026 – Release der vollständig gepatchten Version 0.9.124.
• February 21, 2026 – Wordfence Free soll die gleiche Schutzregel erhalten.

Einordnung: Gute Zusammenarbeit, aber du musst trotzdem schnell reagieren

Positiv ist hier vor allem der schnelle Ablauf: Die Meldung ging laut Bericht nur wenige Tage nach Einführung der Schwachstelle ein, der Fix wurde zeitnah veröffentlicht. Entdeckt und verantwortungsvoll gemeldet wurde das Problem durch Lucas Montes (NiRoX) im Rahmen des Wordfence Bug Bounty Programms; die gemeldete Prämie lag bei $2,145.00.

Für Betreiber:innen bleibt die Kernbotschaft aber simpel: Wenn WPvivid im Einsatz ist und insbesondere die „Backup von anderer Site empfangen“-Funktion genutzt wurde, sollte das Update auf 0.9.124 ganz oben auf die To-do-Liste.