Faille critique de WordPress : 5 millions de sites à mettre à jour

Une faille notée 8.8 sur 10 frappe All-in-One WP Migration and Backup, extension installée sur plus de 5 millions de sites WordPress. L’attaquant n’a besoin d’aucun compte : il dépose une charge SQL dans vos commentaires, puis attend que vous restauriez une sauvegarde pour prendre la main sur le serveur. Voici ce que vous devez absolument faire dès que possible et ce qu’il faut savoir.
Faille de sécurité dans l'extension WordPress All-in-One WP Migration and Backup
Faille de sécurité WordPress : All-in-One WP Migration and Backup

L’essentiel en bref

  • La vulnérabilité CVE-2026-19949 touche toutes les versions d’All-in-One WP Migration and Backup jusqu’à la 7.109 incluse. La version corrigée 7.110 est disponible depuis le 20 août 2026.
  • L’injection SQL est dite de second ordre : elle est déposée sans authentification via un rétrolien, et ne s’exécute qu’au moment où un administrateur restaure une archive.
  • La chaîne se termine par une exécution de code à distance, obtenue après la fuite publique de la clé ai1wm_secret_key.

Ce que Wordfence a trouvé dans All-in-One WP Migration and Backup

Le 14 août 2026, Wordfence reçoit via son programme de bug bounty un rapport signé par le chercheur Jack Taylor : une injection SQL non authentifiée dans la fonction de restauration d’archive de l’extension éditée par ServMask.

Le signalement part chez l’éditeur dès le lendemain, une règle de pare-feu est poussée aux abonnés payants le 16 août, et le correctif 7.110 sort le 20 août. Six jours entre le rapport et le patch, c’est un délai que peu d’éditeurs d’extensions tiennent.

8.8 / 10 Le score CVSS attribué à la faille CVE-2026-19949, classée en sévérité élevée, avec une prise de contrôle complète du site au bout de la chaîne. (Source : Wordfence Intelligence)

L’extension sert à empaqueter un site dans une archive .wpress puis à le restaurer ailleurs. Si vous l’utilisez pour vos opérations de migration ou vos sauvegardes de recette, vous êtes exactement dans la population visée.

Le process pour protéger votre site WordPress, dans l’ordre :

Si vous gérez une flotte de sites clients, traitez les étapes dans cet ordre précis. L’erreur classique consiste à restaurer une sauvegarde « propre » avant d’avoir mis à jour, ce qui revient à appuyer soi-même sur la détente.

  1. Ne lancez aucune restauration d’archive avant la mise à jour. C’est l’import qui exécute la charge, pas le dépôt du rétrolien.
  2. Passez en version 7.110 ou supérieure depuis Extensions puis Extensions installées, et vérifiez le numéro affiché plutôt que de vous fier au badge de mise à jour automatique.
  3. Désinstallez l’extension si elle ne sert plus. Beaucoup de sites la gardent active des mois après la migration initiale, sans usage réel.
  4. Coupez les rétroliens et pingbacks dans Réglages puis Discussion. Attention, décocher l’option ne s’applique qu’aux nouveaux articles : les publications existantes conservent leur réglage et doivent être traitées en édition groupée.
  5. Inspectez la table des commentaires à la recherche de rétroliens dont le nom d’auteur se termine par un antislash, ou de commentaires approuvés contenant une longue chaîne aléatoire qui ressemble à une clé.
  6. Considérez la clé ai1wm_secret_key comme compromise si une restauration a eu lieu entre la mi-août et votre mise à jour, et faites-la régénérer.
  7. Vérifiez le dossier mu-plugins et listez les fichiers que vous n’avez pas déposés vous-même, puisque c’est là que se loge la charge finale.

Côté défense périmétrique, les abonnés Wordfence Premium, Care et Response sont couverts depuis le 16 août. Les sites qui tournent sur la version gratuite attendront le 15 septembre, ce qui laisse une fenêtre d’un mois pendant laquelle le correctif de l’extension est votre seule protection réelle. Si vous n’avez pas encore arbitré sur ce sujet, notre sélection d’extensions de sécurité pour WordPress donne les points de comparaison.

Profitez aussi de l’occasion pour revoir votre chaîne de sauvegarde. Une stratégie de sauvegarde WordPress qui repose sur une seule extension, sans copie hors site ni test de restauration, vous laisse sans plan B le jour où la restauration elle-même devient le vecteur.

Pourquoi c’est votre propre restauration qui déclenche l’attaque ?

Le mécanisme mérite d’être compris, parce qu’il change complètement la façon de traiter l’incident.

L’attaquant ne pirate rien au moment où il agit : il envoie deux rétroliens à un article public de votre site qui accepte les pings, une fonction de WordPress qui ne demande aucune authentification.

Dans le détail, le nom de blog déclaré se termine par un antislash et l’URL transporte la charge utile. WordPress stocke ces deux valeurs telles quelles dans la table des commentaires, sans supprimer l’antislash ni rejeter l’URL. À ce stade, rien ne se passe et rien n’est visible.

La bascule arrive à l’import. L’extension réécrit les URL et les préfixes de tables à l’intérieur de chaque requête SQL de la sauvegarde, en s’appuyant sur une expression régulière chargée de repérer les chaînes entre guillemets simples.

Sauf que cette expression ne compte pas la série complète d’antislashs avant un guillemet fermant, elle n’en regarde qu’un seul. Conséquence directe : la donnée piégée déborde de son guillemet et passe du statut de texte à celui de SQL exécutable pendant la restauration.

La suite est méthodique. Le premier rétrolien est calibré pour dépasser le budget de temps de l’import, ce qui force une pause et une reprise, moment où l’extension réinjecte la vraie clé ai1wm_secret_key dans la table des options. Le second rétrolien lit alors cette clé et l’écrit dans un commentaire qu’il marque comme approuvé.

Le secret devient donc lisible par n’importe qui via l’API REST publique des commentaires. Avec cette clé, l’attaquant pilote directement l’action d’import de l’extension, qui est ouverte aux non-authentifiés et protégée par cette seule vérification, et il fait extraire une archive contenant un mu-plugin malveillant exécuté au chargement de page suivant.

Wordfence insiste sur un point que vous devez retenir avant d’agir : l’attaquant reste non authentifié de bout en bout, mais rien ne s’exécute tant qu’un administrateur n’a pas lancé un export puis un import. Sur une extension dont c’est précisément le métier, cette action arrive tôt ou tard.

Notre verdict :

Mettre à jour ne suffit pas à clore le dossier. Le correctif 7.110 empêche l’exécution future de la charge, mais il n’efface pas ce qui a déjà été déposé dans vos commentaires, et il n’annule pas une clé secrète déjà fuitée. Tout site ayant restauré une archive entre la mi-août et sa mise à jour doit être traité comme potentiellement compromis, pas comme corrigé.

Un avis ? post

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *