Faille plugin migration WordPress : sauvegarde piégée, 3 millions de sites menacés

Vous utilisez All-in-One WP Migration and Backup pour sauvegarder votre site ou le déplacer d’un hébergeur à un autre. C’est un des plugins les plus installés de l’écosystème WordPress, avec plus de cinq millions d’installations actives. Une faille référencée CVE-2026-19949 y a été identifiée, corrigée le 20 août dans la version 7.110, et au 3 septembre seulement 35 % des installations avaient appliqué la mise à jour. Environ 3,2 millions de sites restent donc exposés.

À lire aussi : WordPress 7.0.4 : une mise à jour de sécurité à ne pas ignorer

Ce qui rend cette faille inhabituelle, c’est son déclencheur : ce n’est pas une attaque directe sur votre site, c’est vous qui l’armez, au moment précis où vous restaurez une sauvegarde. Le geste censé réparer votre site devient celui qui l’ouvre.

Je détaille ici le mécanisme en langage clair, la façon de vérifier en deux minutes si vous êtes concerné, et les signes à chercher si vous avez restauré une archive récemment.

Ce que fait ce plugin, et pourquoi il est sensible

All-in-One WP Migration and Backup empaquette un site WordPress complet (fichiers, base de données, contenus) dans une archive au format .wpress. Vous pouvez ensuite restaurer cette archive sur n’importe quel serveur de destination. C’est la raison de sa popularité : changer d’hébergeur ou dupliquer un site devient une opération en deux clics.

Cette souplesse a un prix technique. L’opération d’import n’est pas authentifiée : elle ne demande pas de connexion administrateur. Elle est protégée par une clé secrète, nommée ai1wm_secret_key, enregistrée à chaque passage de restauration de base de données. Tant que cette clé reste privée, personne ne peut importer une archive sur votre site. La faille consiste précisément à faire sortir cette clé.

Au passage : un plugin de migration est par nature un outil qui écrit dans votre base et remplace vos fichiers. Toute faille dans ce type d’outil a mécaniquement un potentiel de dégâts élevé, contrairement à un plugin de galerie photo. C’est le même raisonnement que pour les plugins populaires touchés par des failles critiques : plus les privilèges d’un plugin sont larges, plus l’écart entre une version corrigée et une version obsolète compte.

Le mécanisme : une injection SQL de second ordre via les trackbacks

L’expression « injection SQL de second ordre » décrit une attaque en deux temps. Dans une injection SQL classique, du code malveillant est envoyé et exécuté immédiatement. Ici, le code est d’abord stocké tranquillement dans la base, sans rien déclencher, puis exécuté plus tard, quand une autre opération le réutilise. Le déclencheur, c’est votre restauration.

Voici la chaîne, étape par étape :

1. L’attaquant soumet deux trackbacks sur un article public de votre site. Le trackback est une notification automatique qu’un site envoie à un autre quand il le cite ; c’est une fonction d’origine de WordPress, largement inutilisée aujourd’hui.
2. Chaque trackback porte une barre oblique inversée finale et une URL pointant vers une charge utile. L’entrée est enregistrée telle quelle : les barres obliques inversées ne sont pas supprimées, les URL ne sont pas rejetées.
3. Le contenu dort dans la base. Rien ne se passe.
4. Vous archivez votre site, puis vous importez l’archive. Pendant la restauration, le plugin réécrit les URL et les préfixes de table dans le SQL stocké.
5. Cette réécriture promeut l’entrée de l’attaquant en SQL exécutable. Résultat : la valeur de la clé secrète est écrite dans un commentaire, approuvé et rendu public.
6. L’attaquant récupère la clé depuis l’endpoint REST API des commentaires de votre site, sans être authentifié.
7. Avec cette clé, il importe une archive .wpress forgée contenant un plugin must-use malveillant, exécuté au chargement de page suivant. C’est l’exécution de code à distance.

La cause technique est décrite sans ambiguïté : échappement insuffisant des entrées fournies par l’utilisateur et requêtes SQL existantes insuffisamment préparées. Un attaquant peut ainsi ajouter ses propres requêtes pour extraire des informations sensibles de la base.

Si vous avez restauré une archive .wpress depuis le 20 août avec une version antérieure à 7.110, considérez que votre clé secrète a pu être publiée dans un commentaire et vérifiez vos commentaires approuvés.

Le niveau de gravité, chiffres à l’appui

La faille est classée de haute sévérité. Un score CVSS (le barème standard de gravité des vulnérabilités, de 0 à 10) permet de situer le risque sans interpréter.

Deux lectures de ce tableau. Le vecteur CVSS indique une attaque réalisable à distance par le réseau, avec une complexité faible et un impact élevé sur la confidentialité, l’intégrité et la disponibilité. Le score EPSS, lui, estime la probabilité d’exploitation observée à court terme : 0,00538 reste faible. Je n’ai pas de confirmation d’exploitation active dans la nature à ce jour, et je ne l’affirmerai pas. La question reste ouverte, mais un correctif publié depuis plusieurs semaines et appliqué sur un tiers seulement du parc constitue un signal suffisant pour agir.

La marche à suivre, dans l’ordre

Trois vérifications, puis une action. Comptez dix minutes sur un site simple.

• Vérifiez la version installée. Dans l’administration WordPress, ouvrez la liste des plugins et lisez le numéro affiché sous All-in-One WP Migration and Backup. Si vous lisez 7.109 ou moins, vous êtes concerné.
• Mettez à jour vers 7.110 ou supérieur. Faites d’abord une sauvegarde par un autre moyen que ce plugin (export base de données côté hébergeur, copie des fichiers en FTP), puis lancez la mise à jour depuis l’écran des plugins. Vous pouvez consulter la page officielle du plugin sur WordPress.org pour confirmer la version courante.
• Désactivez les trackbacks et pingbacks. Dans Réglages puis Discussion, décochez l’autorisation des notifications de liens depuis d’autres blogs. Attention : ce réglage ne s’applique qu’aux nouveaux articles. Pour les articles existants, passez par l’édition en lot depuis la liste des articles.
• Relisez vos commentaires approuvés. Cherchez des commentaires au contenu incohérent, contenant des chaînes techniques ou des URL inattendues, publiés autour d’une restauration récente.
• Inspectez le dossier des plugins must-use. Il s’agit de wp-content/mu-plugins, un répertoire dont le contenu s’exécute sans être activé. Tout fichier .php que vous n’avez pas placé là est suspect.

Si vous prévoyez une migration, mettez le plugin à jour avant l’export, pas seulement avant l’import : le SQL stocké dans l’archive voyage avec elle.

Si vous confiez la manipulation à quelqu’un, précisez explicitement la version cible. Sur une migration de site WordPress, la mise à jour des outils de migration eux-mêmes fait partie du travail de préparation, avant la copie.

Ce que révèle ce tiers de sites à jour

Le correctif existe depuis le 20 août. Deux semaines plus tard, 65 % des installations tournaient encore sur une version vulnérable. C’est le vrai sujet : la faille n’est pas un incident isolé, c’est la mise à jour qui n’arrive pas. Un plugin de sauvegarde s’installe une fois, sert deux fois par an, et disparaît de l’attention. Il reste pourtant actif, avec ses privilèges d’écriture.

Le même écart se retrouve sur d’autres cas récents, comme les 600 000 sites exposés par la faille de téléversement de Forminator : le correctif est publié vite, l’application traîne. La parade n’est pas technique, elle est organisationnelle : une vérification mensuelle des versions de plugins, et la désinstallation de ceux dont vous ne vous servez plus. Un plugin de migration désactivé mais présent sur le serveur reste un fichier exploitable.

À faire cette semaine

Ouvrez votre liste de plugins et lisez la version d’All-in-One WP Migration and Backup. Si elle est inférieure à 7.110, sauvegardez par un autre moyen, mettez à jour, puis coupez les trackbacks dans Réglages, Discussion, en incluant les articles déjà publiés. Si vous avez restauré une archive depuis le 20 août, relisez vos commentaires approuvés et le contenu de wp-content/mu-plugins avant de considérer le dossier clos. Et si ce plugin ne vous sert plus, supprimez-le : c’est la seule mesure qui ne demande aucun suivi.

FAQ

Comment savoir en pratique si je suis concerné ?

Deux conditions. Le plugin All-in-One WP Migration and Backup est installé sur votre site, et sa version est 7.109 ou antérieure. Le numéro s’affiche sous le nom du plugin dans l’écran Plugins de l’administration. Si le plugin n’est pas présent, cette faille précise ne vous concerne pas, indépendamment de vos autres extensions.

Mon hébergeur applique-t-il le correctif à ma place ?

Cela dépend entièrement de votre contrat. Certaines offres WordPress infogérées appliquent les mises à jour de plugins automatiquement, d’autres se limitent au cœur de WordPress, beaucoup ne touchent à rien. Ne le supposez pas : vérifiez le numéro de version affiché dans votre administration, c’est la seule preuve fiable de l’état réel de votre installation.

Faut-il couper définitivement les trackbacks et pingbacks ?

Sur la grande majorité des sites d’artisans, de TPE et d’indépendants, ces fonctions n’apportent rien et génèrent surtout du spam. Les désactiver réduit une surface d’entrée sans effet visible sur votre site ni sur votre référencement. Ce n’est pas un substitut à la mise à jour du plugin, c’est une mesure complémentaire qui limite le point de départ de l’attaque.

Que signifie concrètement une exécution de code à distance ?

Un attaquant fait tourner ses propres instructions sur votre serveur. Dans le cas décrit, il déploie un plugin must-use, exécuté au chargement de page suivant. Cela ouvre la voie à une compromission complète : webshells, pages ajoutées, redirections, envoi de courriels frauduleux depuis votre domaine. La restauration d’une sauvegarde antérieure devient alors la voie de sortie la plus sûre.

Que faire si je soupçonne une compromission déjà effective ?

Changez les mots de passe administrateurs et la base de données, examinez wp-content/mu-plugins et les fichiers .php récents, supprimez les commentaires suspects. Puis restaurez une sauvegarde antérieure à la restauration douteuse, sur un plugin déjà à jour. Si vous ne pouvez pas dater l’incident avec certitude, faites auditer le site plutôt que de nettoyer à l’aveugle.