{"id":222,"date":"2026-02-11T16:39:30","date_gmt":"2026-02-11T15:39:30","guid":{"rendered":"https:\/\/helloblog.io\/de\/kritische-file-upload-luecke-wpvivid-backup-cve-2026-1357\/"},"modified":"2026-02-11T16:39:30","modified_gmt":"2026-02-11T15:39:30","slug":"kritische-file-upload-luecke-wpvivid-backup-cve-2026-1357","status":"publish","type":"post","link":"https:\/\/helloblog.io\/de\/kritische-file-upload-luecke-wpvivid-backup-cve-2026-1357\/","title":{"rendered":"Kritische File-Upload-L\u00fccke in WPvivid Backup: Bis zu 800.000 WordPress-Installationen potenziell betroffen"},"content":{"rendered":"\n

Im WordPress-\u00d6kosystem sind Backup-Plugins oft der letzte Rettungsanker \u2013 und gleichzeitig ein attraktives Ziel. F\u00fcr das Plugin WPvivid Backup & Migration<\/strong> (WordPress.org-Slug: wpvivid-backuprestore<\/code>) wurde eine kritische Arbitrary-File-Upload-Schwachstelle<\/strong> gemeldet, die bei erfolgreicher Ausnutzung in Remote Code Execution (RCE)<\/strong> und damit typischerweise in einer vollst\u00e4ndigen Website-\u00dcbernahme endet.<\/p>\n\n\n\n

Wichtig f\u00fcr die Einsch\u00e4tzung: Laut Analyse betrifft das Problem vor allem Installationen, bei denen in den Plugin-Einstellungen ein Schl\u00fcssel (\u201egenerated key\u201c) erzeugt wurde<\/strong>, um von einer anderen Website ein Backup auf diese Website zu \u00fcbertragen. Diese Funktion ist standardm\u00e4\u00dfig deaktiviert<\/strong>, und die Ablaufzeit des Keys<\/strong> l\u00e4sst sich nur bis maximal 24 Stunden<\/strong> konfigurieren.<\/p>\n\n\n\n

Kurz\u00fcberblick: CVE, betroffene Versionen, Fix<\/h2>\n\n\n\n
    \n\n
  • Schwachstelle: Unauthenticated Arbitrary File Upload<\/strong><\/li>\n\n\n
  • CVE: CVE-2026-1357<\/strong><\/li>\n\n\n
  • CVSS: 9.8 (Critical)<\/strong><\/li>\n\n\n
  • Betroffene Versionen: \u2264 0.9.123<\/strong><\/li>\n\n\n
  • Gefixte Version: 0.9.124<\/strong><\/li>\n\n\n
  • Angriffsvektor laut Advisory: \u00fcber den Parameter wpvivid_action=send_to_site<\/code><\/strong><\/li>\n\n<\/ul>\n\n\n\n

    Warum das kritisch ist: Unauthentifizierter Upload bis hin zu RCE<\/h2>\n\n\n\n

    Ein \u201eArbitrary File Upload\u201c ist in WordPress-Kontexten fast immer eine der unangenehmsten Klassen von Bugs: Wenn Angreifer beliebige Dateien hochladen k\u00f6nnen \u2013 insbesondere PHP-Dateien<\/strong> \u2013 ist der Schritt zum Ausf\u00fchren von Code auf dem Server meist klein. In der Praxis sieht man danach h\u00e4ufig Webshells, Persistenz-Mechanismen und weitere Nachlade-Stufen.<\/p>\n\n\n\n

    Bei dieser L\u00fccke geht es explizit um nicht angemeldete Angreifer<\/strong> (unauthenticated). Das erh\u00f6ht den Druck, weil kein bestehendes Konto (z. B. Subscriber) ben\u00f6tigt wird \u2013 sofern die betroffene Funktionalit\u00e4t auf der Site aktiv und erreichbar ist.<\/p>\n\n\n\n

    Was genau passiert technisch? (Analyse der Ursache)<\/h2>\n\n\n\n

    WPvivid bringt u. a. eine Funktion mit, um Backups von einer anderen Site zu empfangen<\/strong>. Daf\u00fcr wird ein kurzlebiger Key<\/strong> generiert. In der untersuchten Implementierung \u00fcbernimmt die Methode send_to_site()<\/code> (Klasse WPvivid_Send_to_site<\/code>) das Entgegennehmen der Daten, wenn im Request wpvivid_content<\/code> \u00fcbergeben wird und eine passende Konfiguration (wpvivid_api_token<\/code>) existiert.<\/p>\n\n\n\n

    Im Kern wird der Payload entschl\u00fcsselt. Der Knackpunkt: Bei der RSA-Entschl\u00fcsselung des Session-Keys kann etwas schiefgehen \u2013 und genau dort greift eine Kombination aus fehlerhafter Fehlerbehandlung<\/strong> und fehlender Pfad-\/Dateiname-Sanitization<\/strong>.<\/p>\n\n\n\n

    1) Fehlerbehandlung bei RSA-Decrypt f\u00fchrt zu \u201eNull-Byte-Key\u201c<\/h3>\n\n\n\n

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

    Dadurch entsteht ein ung\u00fcnstiger Effekt: Ein Angreifer kann den weiteren Payload so konstruieren bzw. verschl\u00fcsseln, dass er mit diesem vorhersagbaren Null-Byte-Key entschl\u00fcsselt wird. Das macht die Schutzannahme \u201eOhne korrekten Key kein g\u00fcltiger Inhalt\u201c angreifbar.<\/p>\n\n\n\n

    2) Dateiname aus entschl\u00fcsseltem Payload + fehlende Sanitisierung = Directory Traversal<\/h3>\n\n\n\n

    Zus\u00e4tzlich akzeptiert die betroffene Logik Dateinamen aus dem entschl\u00fcsselten Payload, ohne sie ausreichend zu bereinigen. Das erm\u00f6glicht Directory Traversal<\/strong> (z. B. \u00fcber ..\/<\/code>), wodurch Angreifer aus dem eigentlich vorgesehenen Backup-Verzeichnis \u201eausbrechen\u201c k\u00f6nnen. Ergebnis: Dateien lassen sich in \u00f6ffentlich erreichbare Verzeichnisse<\/strong> schreiben \u2013 und wenn das eine PHP-Datei ist, ist der Weg zur RCE offen.<\/p>\n\n\n\n

    Das Advisory beschreibt au\u00dferdem, dass in der anf\u00e4lligen Implementierung keine Checks auf Dateityp oder Dateiendung<\/strong> vorhanden waren. Genau das macht Arbitrary-Upload-Bugs meist so fatal: Es gibt keinen zus\u00e4tzlichen Filter, der das Hochladen ausf\u00fchrbarer Dateien verhindert.<\/p>\n\n\n\n

    \n\n

    Einschr\u00e4nkung, die du ernst nehmen solltest<\/h4>\n\n\n

    Die Schwachstelle wird laut Bericht nur dann kritisch<\/strong>, wenn in WPvivid ein generated key<\/strong> f\u00fcr das Empfangen von Backups von anderen Sites erzeugt wurde (Feature standardm\u00e4\u00dfig aus) \u2013 und die Key-Ablaufzeit ist auf maximal 24 Stunden<\/strong> begrenzt. Dennoch: Wenn diese Funktion aktiv genutzt wird, ist das Risiko hoch.<\/p>\n\n<\/div>\n\n\n\n

    So wurde es gefixt: Abbruch bei ung\u00fcltigem Key + Whitelist f\u00fcr Dateiendungen<\/h2>\n\n\n\n

    Der Hersteller hat den Fix in zwei zentralen Punkten umgesetzt:<\/p>\n\n\n\n

      \n\n
    1. In decrypt_message()<\/code> wird der entschl\u00fcsselte Key jetzt gepr\u00fcft. Wenn decrypt()<\/code> false<\/code><\/strong> liefert oder der Key leer<\/strong> ist, wird sauber abgebrochen und false<\/code> zur\u00fcckgegeben \u2013 statt mit einem impliziten Null-Byte-Key weiterzumachen.<\/li>\n\n\n
    2. In send_to_site()<\/code> wurde eine Dateiendungspr\u00fcfung<\/strong> erg\u00e4nzt. Der Dateiname wird u. a. \u00fcber basename()<\/code> reduziert und per preg_replace('\/[^a-zA-Z0-9._-]\/', '', ...)<\/code> bereinigt. Zus\u00e4tzlich gibt es eine Whitelist erlaubter Endungen: zip<\/code>, gz<\/code>, tar<\/code>, sql<\/code>. Alles andere wird mit einer Fehlermeldung abgelehnt.<\/li>\n\n<\/ol>\n\n\n\n
      <\/circle><\/circle><\/circle><\/g><\/svg><\/span>