UpdraftPlus piraté : des backdoors installées sur 400 000 sites WordPress via des clés volées

Ce qui s'est passé

Le week-end du 17-18 octobre 2026, un attaquant a obtenu un accès non autorisé à teamupdraft.com, le site officiel de l'éditeur d'UpdraftPlus, le plugin de backup le plus répandu sur le CMS WordPress. La base de données clients a été compromise : noms, adresses email, historique de commandes, mots de passe hachés et, surtout, les clés de connexion UpdraftCentral (source : TeamUpdraft).

WordPress est le CMS le plus déployé au monde : il repose sur un socle PHP et une base de données MySQL (ou MariaDB) pour stocker les contenus, les comptes utilisateurs et les réglages des extensions. UpdraftCentral est le tableau de bord cloud intégré à UpdraftPlus. Il permet de gérer à distance les sauvegardes (backup), les mises à jour et les plugins de plusieurs sites web WordPress depuis un seul panel centralisé. Chaque site connecté stocke dans sa base de données une paire de clés RSA qui autorise les commandes reçues depuis le panel distant. Ces clés n'expirent pas : une clé générée en novembre 2025 fonctionnait encore en octobre 2026.

L'attaquant a utilisé ces clés volées pour envoyer des commandes plugin.upload_plugin légitimement signées aux sites connectés via le canal RPC qui écoute les requêtes POST envoyées à l'URL racine du site. Du point de vue du plugin, les instructions étaient authentiques : chaque vérification cryptographique passait. Selon l'analyse de Patchstack, la première installation de backdoor a été enregistrée le 18 octobre à 15 h 32 UTC, et les installations ont continué pendant 18 heures jusqu'au 19 octobre à 09 h 23 UTC (source : Patchstack).

Ampleur de l'incident

UpdraftPlus revendique plus de 4 millions d'installations actives. Environ 10 % des sites internet utilisant le plugin disposent d'une clé UpdraftCentral ou Migrator, ce qui porte à environ 400 000 sites WordPress le périmètre potentiellement exposé : blogs, vitrines d'entreprise, boutiques e-commerce WooCommerce, sites institutionnels. Patchstack a recensé 99 noms de plugins malveillants différents installés durant la fenêtre d'attaque.

Les plugins backdoor se présentent comme des outils de maintenance anodins. Leur description commune dans l'en-tête PHP est : "Small maintenance toolkit: keeps option storage tidy." Voici les noms les plus fréquemment observés :

Une fois activé, le script PHP backdoor embarqué dans chaque plugin :

• crée un compte administrateur déguisé en éditeur avec un nom d'utilisateur de type data-ops43 ou media-staff96, une adresse email en @example.org et le nom affiché "Site Tools" ;
• lui attribue en secret les capacités manage_options et install_plugins, permissions normalement réservées au rôle administrateur ;
• contourne l'authentification en posant directement un cookie de session via une URL contenant un token secret de 32 caractères : les plugins de protection du login et de double authentification ne se déclenchent pas ;
• persiste même si le plugin est désactivé. Le compte frauduleux et son mot de passe restent dans la base de données MySQL de WordPress.

L'attaque ne repose pas sur une faille dans le code PHP d'UpdraftPlus ni dans le CMS WordPress. Les commandes sont chiffrées et signées avec de vraies clés privées volées. C'est la compromission de l'infrastructure cloud de l'éditeur qui a rendu l'attaque possible.

Indicateurs de compromission (IOC)

Patchstack a publié les indicateurs techniques pour identifier les sites web touchés. Si vous administrez des sites WordPress sur un VPS Linux ou un serveur dédié, voici les éléments à vérifier dans vos logs et vos bases de données.

Adresses IP de l'attaquant

• IPv4 : 43.250.53.42
• IPv6 : 2a09:bac5:4e21:2e3c::49b:9

Cherchez ces adresses IP dans les logs d'accès de votre serveur web :

grep -E "43\.250\.53\.42|2a09:bac5:4e21:2e3c" /var/log/nginx/access.log

Adaptez le chemin si vous utilisez Apache (/var/log/apache2/access.log sur Debian et Ubuntu).

Signature des scripts malveillants

Tous les plugins backdoor partagent la même chaîne dans leur en-tête PHP. Lancez cette commande depuis l'accès root de votre serveur pour scanner tous vos sites :

grep -rl "Small maintenance toolkit: keeps option storage tidy." /var/www/*/wp-content/plugins/

Noms d'utilisateur suspects dans MySQL

Les comptes créés par la backdoor suivent un schéma reconnaissable : deux mots séparés par un tiret et deux chiffres (data-ops43, media-staff96), une adresse email en @example.org et le nom affiché "Site Tools". Lancez cette requête dans MySQL pour les détecter :

mysql -e "SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE user_email LIKE '%@example.org' AND user_registered > '2026-10-17';" wordpress_db

Remplacez wordpress_db par le nom de votre base de données et wp_ par votre préfixe de tables si vous l'avez personnalisé dans le fichier de configuration wp-config.php.

Vérifier si votre site est touché

Connectez-vous en SSH à votre serveur privé virtuel (VPS) ou serveur dédié. Si vous gérez plusieurs sites internet WordPress, répétez ces vérifications sur chaque installation. Ces commandes fonctionnent sur Ubuntu et Debian avec WP-CLI installé.

1. Vérifier la présence de clés UpdraftCentral

Depuis le répertoire racine de votre installation WordPress :

wp option get updraft_central_localkeys

Si la commande renvoie un tableau de clés, votre site était connecté à UpdraftCentral et potentiellement exposé. Si elle renvoie une erreur "Could not get option", aucune clé n'est stockée et votre site n'est pas directement concerné.

2. Chercher des comptes administrateurs suspects

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Recherchez des comptes créés après le 17 octobre 2026 avec des noms d'utilisateur inhabituels (data-ops, media-staff) ou des adresses email en @example.org.

3. Inspecter les plugins installés

wp plugin list --fields=name,status,description

Cherchez tout plugin inconnu, en particulier ceux dont la description contient "maintenance toolkit" ou "option storage". Vérifiez aussi les Must-Use plugins dans le répertoire wp-content/mu-plugins/ : ces scripts PHP s'activent automatiquement sans apparaître dans le panel d'administration de WordPress.

Nettoyer un site infecté

Si vous trouvez des indicateurs de compromission, agissez dans cet ordre depuis un accès SSH (ne vous fiez pas au seul panel WordPress, l'attaquant peut y avoir encore accès).

Supprimer les comptes frauduleux

wp user delete <ID_SUSPECT> --reassign=1

Remplacez <ID_SUSPECT> par l'identifiant du compte et 1 par l'ID de votre administrateur légitime. Changez ensuite le mot de passe de tous les comptes administrateurs existants. Si un attaquant a eu accès à manage_options, il a potentiellement pu lire le contenu du fichier de configuration wp-config.php, y compris les identifiants de connexion à la base de données MySQL et les clés de salage WordPress (salt keys).

Désactiver et supprimer les plugins malveillants

wp plugin deactivate <nom-du-plugin> --uninstall

Inspectez aussi manuellement le répertoire wp-content/mu-plugins/ et supprimez tout fichier PHP non reconnu. Patchstack recommande de déplacer les fichiers suspects hors du répertoire web plutôt que de les supprimer immédiatement, afin de pouvoir les analyser. Si vous avez un doute sur l'intégrité globale de votre site, restaurez une sauvegarde (backup) antérieure au 17 octobre depuis vos copies hors site.

Révoquer les clés UpdraftCentral

C'est l'étape la plus importante. Supprimer la connexion depuis le tableau de bord UpdraftCentral distant ne suffit pas : la clé qui compte est celle stockée dans la base de données de votre site.

wp option delete updraft_central_localkeys

Vous pouvez aussi le faire depuis l'interface graphique : Réglages > UpdraftPlus > Outils avancés, puis supprimez toutes les connexions UpdraftCentral listées.

Renouveler les secrets de WordPress

Si le compte backdoor avait les capacités manage_options, renouvelez les clés de salage dans wp-config.php pour invalider toutes les sessions actives et changez le mot de passe de l'utilisateur MySQL utilisé par WordPress.

Mettre à jour UpdraftPlus

TeamUpdraft a publié les versions 1.26.13 (gratuit) et 2.26.13 (Premium) le 19 octobre 2026 après 22 h BST. Ces mises à jour révoquent automatiquement toutes les connexions UpdraftCentral établies avant le 18 octobre 2026 à 22 h BST. Si votre WordPress utilise PHP 7.4 ou une version antérieure, profitez-en pour mettre à jour vers PHP 8.2+ (requis par les versions récentes du CMS WordPress).

wp plugin update updraftplus

Après la mise à jour, vérifiez que les clés ont bien été supprimées :

wp option get updraft_central_localkeys

Si vous utilisez UpdraftVault pour stocker vos sauvegardes (backup) dans le cloud de TeamUpdraft, reconnectez-vous avec de nouvelles informations d'identification depuis Réglages > UpdraftPlus > Stockage distant. Si vous utilisez UpdraftClone, récupérez de nouvelles clés client depuis votre espace Mon Compte sur teamupdraft.com.

Sécuriser votre infrastructure WordPress

Cet incident rappelle qu'un plugin de backup connecté au cloud de l'éditeur est un vecteur d'attaque potentiel, quel que soit votre hébergeur. Voici les bonnes pratiques pour tout administrateur qui gère un ou plusieurs WordPress sur un serveur privé virtuel (VPS) ou un serveur dédié.

• Sauvegardes locales, hors site : ne comptez pas uniquement sur un service de backup cloud propriétaire. Sauvegardez votre VPS avec rsync vers un serveur distant pour conserver des copies de vos fichiers PHP, de vos bases de données MySQL et de vos fichiers de configuration indépendamment de tout éditeur tiers. Programmez des sauvegardes MySQL automatiques avec mysqldump et cron pour pouvoir restaurer vos données rapidement.
• Mises à jour de sécurité automatiques : maintenez votre système à jour pour corriger les failles du socle serveur (noyau Linux, interpréteur PHP, serveur web). Consultez notre tutoriel automatiser les mises à jour de sécurité sur Ubuntu. Sur Debian, configurez unattended-upgrades de la même manière. Quelle distribution Linux choisir pour un VPS ?
• Pare-feu (firewall) et durcissement SSH : verrouillez l'accès à votre serveur. Désactivez l'authentification par mot de passe SSH, configurez un firewall restrictif et ne laissez ouverts que les ports strictement nécessaires (guide VPS Ubuntu : SSH, UFW et Fail2ban). N'utilisez jamais FTP pour transférer des fichiers vers votre serveur : SFTP ou SCP transitent par le tunnel SSH chiffré.
• Certificat SSL et HTTPS : servez votre WordPress exclusivement en HTTPS avec un certificat SSL valide sur votre nom de domaine. Certbot et Let's Encrypt permettent d'obtenir et de renouveler un certificat SSL gratuitement. Configurez aussi votre enregistrement DNS pour pointer vers l'adresse IP de votre serveur.
• Audit des extensions et des comptes : auditez régulièrement la liste des plugins installés et des comptes administrateurs via le panel WordPress. Désactivez et supprimez tout plugin inutilisé. Limitez les connexions tierces (UpdraftCentral, ManageWP) aux seuls services indispensables.
• Alertes et supervision : configurez un envoi d'emails (via un serveur SMTP ou un relais comme Postfix) pour être notifié en cas de connexion suspecte ou de modification de fichiers critiques. Fail2ban protège votre VPS contre les attaques par force brute sur SSH et peut aussi surveiller les journaux d'accès web.
• Avantage du VPS et du dédié face au mutualisé : sur un hébergement mutualisé, vous ne contrôlez ni le firewall, ni l'accès root, ni la version de PHP. Sur un VPS ou un serveur dédié, vous pouvez isoler chaque site WordPress dans son propre utilisateur système, configurer des permissions strictes sur les fichiers, choisir votre distribution (Debian, Ubuntu) et allouer la RAM et le stockage SSD dont chaque site a besoin. C'est un avantage décisif pour limiter la propagation en cas de compromission d'un seul site parmi plusieurs. Les hébergeurs qui proposent de l'infogérance peuvent aussi appliquer ces durcissements pour vous.

Questions fréquentes