Ce qui s'est passé chez UpdraftPlus en octobre 2026
L'éditeur TeamUpdraft a identifié un accès non autorisé à son propre site les 17 et 18 octobre 2026. Les données concernées comprennent des clés de connexion UpdraftCentral, le service de gestion à distance. Avec une telle clé, un attaquant signe des commandes que le site accepte comme venant de son tableau de bord, dont l'installation d'un plugin. Patchstack a observé la première installation de porte dérobée le 18 octobre à 15:32 UTC et recense au moins 99 plugins malveillants aux noms distincts, déguisés en outils de maintenance. Le point central est ailleurs : il ne s'agit pas d'une faille du plugin de sauvegarde. L'éditeur indique que le plugin et ses téléchargements ne sont pas touchés, ni les sauvegardes conservées dans votre propre stockage distant. Le danger vient d'une clé de gestion à distance volée, pas des sauvegardes WordPress en général.
Versions et situations : où en est chaque site
Faites défiler le tableau
| Situation | Statut | Action |
|---|---|---|
| UpdraftPlus 1.26.13 (gratuit) ou 2.26.13 (Premium), ou plus récent | Les connexions UpdraftCentral existantes sont révoquées, selon l'éditeur | Vérifier quand même clés, plugins et comptes |
| UpdraftPlus 1.26.12 | Selon Nethemba, un bogue empêchait la suppression des clés | Passer en 1.26.13 ou plus récent, puis supprimer les clés |
| Version plus ancienne | Une clé peut rester valide | Mettre à jour, puis supprimer les clés |
| Plugin à jour, faux plugin déjà posé | La mise à jour ne retire pas le faux plugin | Auditer plugins et comptes, voir plus bas |
| Site jamais connecté à UpdraftCentral | Aucune clé attendue | Lire l'option des clés pour en être sûr |
| UpdraftCentral auto-hébergé | Non concerné, d'après l'éditeur | Aucune action propre à cet incident |
| Sauvegardes dans votre stockage distant | Non touchées, d'après l'éditeur | Ré-autoriser le stockage et changer ses clés |
Pourquoi « à jour » ne veut pas dire « sain »
La phrase « mon plugin est à jour, je suis couvert » est fausse pour deux raisons. D'abord, la 1.26.12 devait supprimer les clés mais, selon Nethemba cité par BleepingComputer, un bogue l'en empêchait : seules la 1.26.13 et la 2.26.13 ont réglé ce point. Ensuite, une mise à jour modifie le code du plugin de sauvegarde, elle ne retire ni un faux plugin déjà installé ni un compte administrateur déjà créé. L'éditeur a d'ailleurs signalé, dans une mise à jour de son avis, des sites où un plugin déposé par l'attaquant avait survécu à l'incident initial et créé ensuite un nouvel administrateur, y compris après déconnexion. Un site n'est donc déclaré sain qu'après contrôle des clés, des plugins et des comptes, jamais sur la foi d'un numéro de version.
Les indices à chercher sur chaque site
- Un plugin inconnu — le nom Site Health Cache revient souvent selon Patchstack, mais la liste n'est pas exhaustive : l'éditeur cite aussi Asset Forge 2, Core Smith, Image Forge ou WP Forge.
- Une description type — la chaîne « Small maintenance toolkit: keeps option storage tidy. » est l'indice de fichier le plus fiable selon Patchstack ; ne pas la trouver ne prouve rien.
- Un compte caché — des identifiants du type data-ops43 ou media-staff96, une adresse en example.org, le nom affiché Site Tools ; certains plugins masquent ces comptes de l'écran Utilisateurs.
- Une option en
_sync_token— une entrée dont le nom se termine ainsi dans la table des options accompagne la porte dérobée. - Une installation sans auteur — un plugin apparu sans action d'un administrateur, ou un courriel d'erreur WordPress qui nomme un plugin que personne ne connaît.
- Une clé encore présente — l'option
updraft_central_localkeysn'est pas vide : le site est exposé tant que cette clé existe. - Une ligne de journal — dans le journal UpdraftCentral,
probe.central.updraftplus.comsuivi deCommand received: plugin.upload_plugin.
Auditer chaque site, dans l'ordre
Travailler depuis le site lui-même
Ouvrez le tableau de bord WordPress du site, ou une session SSH, mais pas UpdraftCentral : l'éditeur demande de se connecter à chaque site directement.
Lire les clés existantes
wp option get updraft_central_localkeys
Une sortie non vide signifie que le site est exposé, selon Patchstack, même si vous n'avez jamais utilisé UpdraftCentral. Une erreur « option inexistante » indique l'absence de clé.Mettre à jour puis supprimer les clés
wp plugin update updraftpluswp option delete updraft_central_localkeys
Le chemin graphique est Réglages > UpdraftPlus Backups > Outils avancés > UpdraftCentral, puis « Manage existing keys » ; l'intitulé exact varie selon la version, la commande est le geste de référence. Retirer le site du tableau de bord UpdraftCentral ne suffit pas. Les sauvegardes continuent de fonctionner.Lister les plugins et comparer
wp plugin list --fields=name,status,versionls wp-content/mu-plugins/
Comparez avec la liste attendue du parc : un plugin que personne n'a validé est suspect, y compris dans le dossier des extensions obligatoires (Must-Use), que l'écran Extensions n'affiche pas toujours.Chercher la signature du faux plugin
grep -r "Small maintenance toolkit: keeps option storage tidy." wp-content/plugins/ wp-content/mu-plugins/
Un résultat est une alerte. Une recherche vide ne prouve pas que le site est propre.Lister les comptes à privilèges
wp user list --role=administrator --skip-pluginswp user list --role=editor --skip-plugins
L'option--skip-pluginscompte : elle évite de charger les plugins qui masquent des comptes à l'écran. Comparez avec la liste attendue des personnes qui administrent réellement le site.Chercher l'option de la porte dérobée
wp option list --search="*_sync_token"
Toute entrée trouvée appelle le traitement « site compromis » de la section suivante.Consigner le résultat
Une ligne par site : version d'UpdraftPlus, clés présentes ou non, écart de plugins, écart de comptes, date de l'audit, décision. Ce registre sert de preuve au client et d'état de départ pour le prochain incident.
Les mêmes contrôles selon l'environnement
Faites défiler le tableau
| Environnement | Commande type | Remarque |
|---|---|---|
| Debian ou Ubuntu | `sudo -u www-data wp --path=/var/www/html plugin list` | Adaptez le chemin et l'utilisateur à votre installation |
| RHEL, AlmaLinux ou Rocky | `sudo -u apache wp --path=/var/www/html plugin list` | Utilisateur `nginx` si le serveur web est nginx |
| Docker Compose | `docker compose exec -u www-data wordpress wp plugin list` | Le nom du service dépend de votre fichier ; WP-CLI est souvent absent de l'image WordPress, vérifiez |
| Hébergement mutualisé avec SSH | `wp plugin list` depuis le dossier du site | Sans SSH, passez par le gestionnaire de fichiers ou le SFTP |
| Sans WP-CLI | Examiner `wp-content/plugins/` et `wp-content/mu-plugins/` en SFTP | Comparer chaque dossier à la liste attendue |
| Tous environnements | `wp config shuffle-salts` | Change les clés de sécurité WordPress et ferme les sessions ouvertes |
Au moindre signe, traiter le site comme compromis
Si un compte de porte dérobée existe ou si le déclencheur apparaît dans les journaux, Patchstack recommande de considérer le site comme entièrement compromis. L'ordre compte. Supprimez d'abord la clé UpdraftCentral, sinon l'attaquant garde sa voie d'entrée. Désactivez ensuite le faux plugin, puis supprimez son dossier directement sur le serveur : l'éditeur avertit que certains plugins sont conçus pour effacer leurs traces quand on les supprime depuis le tableau de bord. Ne corrigez pas une erreur de code dans ce plugin pour le « réparer » : Patchstack prévient que cela active la porte dérobée. Retirez le compte et l'option _sync_token, puis préférez la restauration au nettoyage manuel, car rien ne prouve qu'un nettoyage à la main a tout trouvé.
Restaurer proprement
Choisir le point de restauration
Prenez une sauvegarde antérieure au 17 octobre 2026 et vérifiez qu'elle précède bien la compromission : date des fichiers, dernière installation de plugin connue, journaux du serveur.
Restaurer hors production
Montez la sauvegarde sur un site de test ou un serveur jetable, jamais directement en production. Relancez-y les contrôles de la section d'audit : clés, plugins, comptes, signature.
Comparer avec une installation propre
wp core verify-checksumswp plugin verify-checksums --all
Ces commandes comparent les fichiers du cœur et des plugins du répertoire officiel avec leurs sommes de contrôle ; un fichier modifié est signalé.Mettre à jour avant la remise en ligne
Passez UpdraftPlus en 1.26.13 ou 2.26.13 au minimum, mettez à jour le reste, puis supprimez de nouveau les clés : une sauvegarde d'avant l'incident peut en contenir.
Remettre en production et surveiller
Basculez le site restauré, puis relisez plugins et comptes pendant les jours suivants. Un plugin ou un compte réapparu signale une porte encore ouverte ailleurs.
Décider de la reconnexion
TeamUpdraft autorise la reconnexion à UpdraftCentral une fois le site contrôlé et sécurisé. À la date de son article, Patchstack conseillait d'attendre l'explication de la cause. Si vous n'avez pas besoin de la gestion à distance, laissez-la débranchée.
La restauration ne remplace pas la révocation
Restaurer une sauvegarde saine ne dispense ni de supprimer les clés ni de changer les identifiants : l'éditeur le précise lui-même. Faites toujours dans cet ordre : clés supprimées, mots de passe changés, sessions fermées, puis remise en ligne.
Stockage distant, sessions et mots de passe
Les sauvegardes conservées dans votre stockage distant (Google Drive, Dropbox, Amazon S3) ne sont pas touchées, d'après l'éditeur, mais les sites accessibles via UpdraftCentral doivent ré-autoriser ce stockage et en changer les clés d'accès. Faites tourner les clés S3, renouvelez l'autorisation des comptes de type Drive ou Dropbox, puis changez les clés de sécurité WordPress avec wp config shuffle-salts et les mots de passe de tous les comptes administrateur et éditeur légitimes. Côté éditeur, changez votre mot de passe en saisissant l'adresse à la main dans le navigateur, réinitialisez la double authentification, et si vous utilisez UpdraftVault, reconnectez le stockage puis lancez une sauvegarde manuelle : les sites avaient été déconnectés. Les données exposées chez l'éditeur comprennent noms, adresses de courriel, adresses de facturation et historique de commandes ; les mots de passe n'y sont stockés que sous forme hachée.
Pour une agence : un inventaire, pas dix tableaux
Sur des dizaines de sites, le temps ne part pas dans la commande, il part dans la question « qui a quoi ». Tenez un registre vivant par site : version d'UpdraftPlus, présence de clés, liste de plugins attendue, liste d'administrateurs attendue, date du dernier audit, date de la dernière sauvegarde. Sans liste de référence, un plugin n'est jamais « inconnu », seulement « pas encore vu ». Regardez aussi vos points de restauration avant d'en avoir besoin : chez ServOrbit.com, les sauvegardes sont hebdomadaires en entrée de gamme et quotidiennes sur l'offre Pro et sur toutes les offres Agency, et il faut vérifier qu'une copie antérieure au 17 octobre 2026 existe encore. Notre guide sur le test de restauration d'une sauvegarde de VPS client décrit la procédure à répéter à froid, et la logique de mise à jour d'un parc reste celle des deux alertes WordPress récentes.
La documentation officielle
Avis de TeamUpdraft sur l'incident d'octobre 2026 : https://teamupdraft.com/blog/security-incident-october-2026/
Analyse de Patchstack : https://patchstack.com/articles/updraftcentral-key-compromise-wordpress-backdoors/
Article de BleepingComputer : https://www.bleepingcomputer.com/news/security/stolen-updraftcentral-keys-used-to-backdoor-wordpress-sites/
WP-CLI, liste des utilisateurs : https://developer.wordpress.org/cli/commands/user/list/
WP-CLI, vérification des sommes de contrôle des plugins : https://developer.wordpress.org/cli/commands/plugin/verify-checksums/
WP-CLI, renouvellement des clés de sécurité : https://developer.wordpress.org/cli/commands/config/shuffle-salts/
