Faille critique dans WPvivid Backup : un upload de fichiers arbitraires touche jusqu’à 800 000 sites WordPress (CVE-2026-1357)

Le plugin WPvivid Backup & Migration (slug WordPress.org : wpvivid-backuprestore) est au cœur d’un avis de sécurité publié par Wordfence : une faille critique permet, dans certaines conditions, à un attaquant non authentifié d’uploader un fichier arbitraire (typiquement un fichier PHP) et d’aller jusqu’à l’exécution de code à distance (RCE) – autrement dit, la prise de contrôle complète du site dans les scénarios classiques (webshell, backdoor, etc.).

Point important à garder en tête : l’impact « vraiment critique » dépend d’une fonctionnalité spécifique du plugin, désactivée par défaut. La vulnérabilité concerne surtout les sites sur lesquels une clé temporaire a été générée dans les réglages de WPvivid afin d’autoriser un autre site à envoyer une sauvegarde vers ce site. D’après l’analyse, l’expiration de cette clé ne peut pas dépasser 24 heures.

Résumé de la vulnérabilité (Wordfence Intelligence)

Intitulé : Migration, Backup, Staging <= 0.9.123 - Unauthenticated Arbitrary File Upload
Sévérité : CVSS 9.8 (Critical)
CVE : CVE-2026-1357
Versions affectées : <= 0.9.123
Version corrigée : 0.9.124
Logiciel affecté : Migration, Backup, Staging – WPvivid Backup & Migration
Slug : wpvivid-backuprestore
Chercheur : Lucas Montes (NiRoX)
Prime (bug bounty) : 2 145,00 $

Le vecteur décrit par Wordfence s’appuie sur une chaîne de problèmes : gestion d’erreur insuffisante lors du déchiffrement RSA, combinée à une absence de sanitation de chemin (path sanitization) lors de l’écriture des fichiers uploadés. Résultat : un attaquant peut parvenir à déposer un fichier PHP dans un répertoire web accessible, puis l’appeler pour déclencher la RCE. L’exploitation est associée au paramètre wpvivid_action=send_to_site.

Pourquoi cette faille peut mener à une compromission complète

Une vulnérabilité d’arbitrary file upload est presque toujours synonyme de scénario catastrophe dès lors que l’attaquant arrive à écrire un fichier exécutable (comme *.php) dans une zone servie par le serveur web. Dans ce cas, une fois le fichier en place, il suffit de le requêter pour exécuter du code côté serveur et enchaîner sur : création d’un compte admin, injection de portes dérobées, exfiltration de secrets, pivot vers d’autres systèmes, etc.

Ici, Wordfence insiste néanmoins sur le périmètre : l’exploitation critique cible surtout les installations où l’option permettant de recevoir une sauvegarde d’un autre site a été activée via une clé générée. Cette fonctionnalité est off par défaut et la clé est courte durée (expiration max 24 h).

Analyse technique : ce qui se passe dans le code

WPvivid propose plusieurs fonctionnalités de sauvegarde/restauration. Parmi elles : la possibilité de recevoir un backup depuis un autre site. Le flux de réception passe par la méthode send_to_site() de la classe WPvivid_Send_to_site, qui traite un contenu reçu via $_POST['wpvivid_content'] et utilise une clé (token) stockée dans l’option wpvivid_api_token.

public function send_to_site()
{
    include_once WPVIVID_PLUGIN_DIR . '/includes/class-wpvivid-crypt.php';
    $test_log = new WPvivid_Log();
    $test_log->CreateLogFile('test_backup','no_folder','transfer');
    $test_log->WriteLog('test upload.','notice');

    try
    {
        if (isset($_POST['wpvivid_content']))
        {
            global $wpvivid_plugin;
            $wpvivid_plugin->wpvivid_log = new WPvivid_Log();

            $default = array();
            $option = get_option('wpvivid_api_token', $default);
            if (empty($option))
            {
                die();
            }

            if ($option['expires'] != 0 && $option['expires'] < time())
            {
                die();
            }

            $crypt = new WPvivid_crypt(base64_decode($option['private_key']));
            $body  = base64_decode($_POST['wpvivid_content']);
            $data  = $crypt->decrypt_message($body);
        }
    }
    catch (Exception $e)
    {
        // ...
    }
}

public function send_to_site()
{
    include_once WPVIVID_PLUGIN_DIR . '/includes/class-wpvivid-crypt.php';
    $test_log = new WPvivid_Log();
    $test_log->CreateLogFile('test_backup','no_folder','transfer');
    $test_log->WriteLog('test upload.','notice');

    try
    {
        if (isset($_POST['wpvivid_content']))
        {
            global $wpvivid_plugin;
            $wpvivid_plugin->wpvivid_log = new WPvivid_Log();

            $default = array();
            $option = get_option('wpvivid_api_token', $default);
            if (empty($option))
            {
                die();
            }

            if ($option['expires'] != 0 && $option['expires'] < time())
            {
                die();
            }

            $crypt = new WPvivid_crypt(base64_decode($option['private_key']));
            $body  = base64_decode($_POST['wpvivid_content']);
            $data  = $crypt->decrypt_message($body);
        }
    }
    catch (Exception $e)
    {
        // ...
    }
}

Le point de rupture se situe dans la logique de chiffrement/déchiffrement : le plugin déchiffre une clé de session (RSA), puis l’utilise comme clé pour un chiffrement symétrique (Rijndael/AES via phpseclib). Problème : si le déchiffrement RSA échoue, la valeur retournée peut être false… et ce false est ensuite passé tel quel à l’initialisation du chiffrement symétrique.

public function decrypt_message($message)
{
    $len = substr($message, 0, 3);
    $len = hexdec($len);

    $key = substr($message, 3, $len);

    $cipherlen = substr($message, ($len + 3), 16);
    $cipherlen = hexdec($cipherlen);

    $data = substr($message, ($len + 19), $cipherlen);

    $rsa = new Crypt_RSA();
    $rsa->loadKey($this->public_key);
    $key = $rsa->decrypt($key);

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);

    return $rij->decrypt($data);
}

public function decrypt_message($message)
{
    $len = substr($message, 0, 3);
    $len = hexdec($len);

    $key = substr($message, 3, $len);

    $cipherlen = substr($message, ($len + 3), 16);
    $cipherlen = hexdec($cipherlen);

    $data = substr($message, ($len + 19), $cipherlen);

    $rsa = new Crypt_RSA();
    $rsa->loadKey($this->public_key);
    $key = $rsa->decrypt($key);

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);

    return $rij->decrypt($data);
}

Selon Wordfence, quand openssl_private_decrypt() échoue (dans la chaîne de déchiffrement), l’exécution ne s’arrête pas correctement et le false se propage jusqu’à l’initialisation côté phpseclib. La librairie traiterait alors ce false comme une chaîne de null bytes. Cela rend la clé symétrique prévisible, et permet à un attaquant de construire un payload chiffré qui sera correctement déchiffré côté serveur.

Deuxième problème : en plus de rendre le chiffrement contournable, le plugin acceptait des noms de fichiers issus du payload déchiffré sans sanitation suffisante, ouvrant la voie à la traversée de répertoires (directory traversal) pour sortir du répertoire de sauvegarde supposé protégé. Combiné à l’absence de contrôle strict sur le type/extension, cela permet de déposer un fichier PHP en répertoire public et de déclencher une RCE.

Correctif : ce qui a été changé dans la version 0.9.124

Le correctif livré par l’éditeur se joue à deux endroits : (1) arrêter le processus si la clé déchiffrée est invalide, (2) restreindre les extensions de fichiers acceptées lors de la réception d’un backup.

1) Vérification explicite de la clé déchiffrée

Le patch ajoute un contrôle sur $key dans decrypt_message() : si la clé est false ou vide, la fonction retourne false (au lieu de continuer avec une clé implicite).

public function decrypt_message($message)
{
    $len = substr($message, 0, 3);
    $len = hexdec($len);

    $key = substr($message, 3, $len);

    $cipherlen = substr($message, ($len + 3), 16);
    $cipherlen = hexdec($cipherlen);

    $data = substr($message, ($len + 19), $cipherlen);

    $rsa = new Crypt_RSA();
    $rsa->loadKey($this->public_key);
    $key = $rsa->decrypt($key);

    if ($key === false || empty($key))
    {
        return false;
    }

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);

    return $rij->decrypt($data);
}

public function decrypt_message($message)
{
    $len = substr($message, 0, 3);
    $len = hexdec($len);

    $key = substr($message, 3, $len);

    $cipherlen = substr($message, ($len + 3), 16);
    $cipherlen = hexdec($cipherlen);

    $data = substr($message, ($len + 19), $cipherlen);

    $rsa = new Crypt_RSA();
    $rsa->loadKey($this->public_key);
    $key = $rsa->decrypt($key);

    if ($key === false || empty($key))
    {
        return false;
    }

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);

    return $rij->decrypt($data);
}

2) Filtrage des extensions côté réception (send_to_site)

Le fournisseur a également ajouté un contrôle d’extension et une normalisation du nom (basename + regex de nettoyage). L’upload est limité aux formats de sauvegarde listés : zip, gz, tar, sql. En cas d’extension invalide, le plugin renvoie une erreur JSON et stoppe l’exécution.

$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();
}

Suis-je concerné ? Le scénario d’exploitation à connaître

D’après Wordfence, la faille est particulièrement dangereuse pour les sites ayant généré une clé dans les réglages de WPvivid afin d’autoriser la fonctionnalité « un autre site peut envoyer un backup vers ce site ». Comme cette fonctionnalité est désactivée par défaut, tout le monde n’est pas exposé de la même manière.

Si tu utilises WPvivid mais n’as jamais généré de clé pour la réception de sauvegardes, le scénario critique décrit est moins probable (fonctionnalité non activée).
Si tu as généré une clé (même temporairement), considère que ton site a potentiellement été dans une fenêtre d’exposition, sachant que l’expiration maximale annoncée est de 24 heures.
Dans tous les cas : la recommandation pratique reste la même – mettre à jour vers la version corrigée.

Mesures recommandées : mise à jour et protections côté pare-feu

La correction est disponible dans WPvivid Backup 0.9.124 (version indiquée comme patchée au moment de la publication de l’avis Wordfence). Si ton site est en 0.9.123 ou antérieur, l’action prioritaire est la mise à jour.

Action immédiate

Mets à jour WPvivid Backup & Migration vers 0.9.124 (ou toute version ultérieure) dès que possible si tu as le plugin installé.

Côté protection en défense, Wordfence indique aussi avoir déployé une règle de firewall (pare-feu applicatif) :

Les utilisateurs Wordfence Premium, Wordfence Care et Wordfence Response ont reçu une règle de protection le 22 janvier 2026.
Les sites utilisant Wordfence Free doivent recevoir la même protection 30 jours plus tard, soit le 21 février 2026.

Chronologie de divulgation (Disclosure timeline)

12 janvier 2026 – Soumission de la vulnérabilité Arbitrary File Upload dans WPvivid Backup via le Wordfence Bug Bounty Program.
22 janvier 2026 – Validation du rapport, confirmation du proof-of-concept. Premier contact avec l’éditeur, invitation à utiliser le Wordfence Vulnerability Management Portal : https://www.wordfence.com/threat-intel/vendor/vulnerability-management-portal/
22 janvier 2026 – Déploiement d’une règle firewall pour les clients Wordfence Premium, Care et Response.
23 janvier 2026 – Réponse de l’éditeur (choix de poursuivre par e-mail).
23 janvier 2026 – Envoi des détails complets de divulgation ; accusé de réception et démarrage du correctif côté éditeur.
28 janvier 2026 – Publication de la version corrigée 0.9.124.
21 février 2026 – Date annoncée pour la protection équivalente côté Wordfence Free.

À propos de la découverte (bug bounty)

Wordfence crédite Lucas Montes (NiRoX) pour la découverte et le signalement responsable via son Bug Bounty Program : https://www.wordfence.com/threat-intel/bug-bounty-program/ . Selon l’avis, le report est arrivé cinq jours après l’introduction de la vulnérabilité, et une prime de 2 145,00 $ a été versée.

À noter également : Wordfence rappelle que son programme de bug bounty est ouvert aux plugins et thèmes WordPress « sans coût pour les éditeurs », et que les chercheurs peuvent gagner jusqu’à 31 200 $ par vulnérabilité (selon le périmètre et la sévérité) : https://www.wordfence.com/threat-intel/bug-bounty-program/ .

Conclusion

Cette vulnérabilité CVE-2026-1357 dans WPvivid Backup illustre un classique : une combinaison de gestion d’erreur cryptographique, de validation insuffisante et de contrôle trop permissif sur l’écriture de fichiers peut suffire à ouvrir la porte à une RCE. Même si le scénario critique dépend d’une fonctionnalité optionnelle (réception de backups via clé), la bonne hygiène est simple : si WPvivid est présent, passe en 0.9.124 (ou plus) immédiatement, et vérifie tes couches de défense (pare-feu applicatif, durcissement des permissions, surveillance des fichiers ajoutés).

Faille critique dans WPvivid Backup : un upload de fichiers arbitraires touche jusqu’à 800 000 sites WordPress (CVE-2026-1357)

Résumé de la vulnérabilité (Wordfence Intelligence)

Pourquoi cette faille peut mener à une compromission complète

Analyse technique : ce qui se passe dans le code

Correctif : ce qui a été changé dans la version 0.9.124

1) Vérification explicite de la clé déchiffrée

2) Filtrage des extensions côté réception (send_to_site)

Suis-je concerné ? Le scénario d’exploitation à connaître

Mesures recommandées : mise à jour et protections côté pare-feu

Action immédiate

Chronologie de divulgation (Disclosure timeline)

À propos de la découverte (bug bounty)

Conclusion

Références / Sources

Camille Dubois

Plus d’articles de Camille Dubois

Rejoignez la communauté HelloWP !