Une extension de sauvegarde est censée être ce qui vous sauve. Celle-ci, dans une version non corrigée, est le chemin le plus court vers la perte du site — et la partie la plus désagréable de l’affaire est que c’est votre propre administrateur qui déclenche la charge, en faisant exactement ce pour quoi l’extension existe.
Ce qui a été publié
L’extension All-in-One WP Migration and Backup, éditée par ServMask, est affectée par une injection SQL non authentifiée référencée CVE-2026-19949. Elle est présente sur plus de cinq millions d’installations actives, ce qui en fait l’un des outils de migration les plus répandus de l’écosystème WordPress.
Wordfence lui attribue une note de 8,8 sur 10 sur l’échelle CVSS. Le correctif est publié depuis la version 7.110. Au moment des premières publications, environ 35 % seulement des installations l’avaient appliqué — autrement dit, plusieurs millions de sites restaient exposés.
Le mécanisme mérite d’être décrit précisément, parce qu’il explique pourquoi la détection est difficile. L’attaquant dépose d’abord des données forgées par le mécanisme des trackbacks de WordPress. Ces données ne font rien. Elles attendent.
Le déclenchement intervient lorsqu’un administrateur effectue une opération courante de l’extension : un export ou un import de site. À ce moment, l’extension interprète mal les antislashs et les guillemets échappés, et le SQL injecté s’exécute. Il peut alors faire ressortir la clé secrète d’import de l’extension, l’ai1wm_secret_key, au travers d’un commentaire public.
Muni de cette clé, l’attaquant peut importer une archive .wpress malveillante contenant du code exécutable. On ne parle plus de lecture de base de données : on parle de remplacement du site.
Notre avis d’expert (1 sur 3)
Le détail qui change tout dans cette faille, c’est le décalage temporel. Le dépôt ne produit aucun symptôme et peut rester en place des semaines. La charge n’est armée que le jour où un administrateur fait une sauvegarde ou une migration — c’est-à-dire précisément le jour où il pense agir de façon responsable. Cela signifie aussi qu’une analyse effectuée entre le dépôt et le déclenchement ne trouvera rien d’anormal côté fichiers, et que la corrélation entre l’incident et le commentaire déposé trois semaines plus tôt n’est jamais faite spontanément. Nous avons vu ce schéma sur d’autres extensions : ce n’est pas la sophistication qui protège l’attaquant, c’est le délai.
Ce que nous avons trouvé sur nos 31 sites clients
Nous gérons ou surveillons trente et un sites WordPress pour des PME françaises. Le lendemain de la publication, nous avons fait l’inventaire. Sept avaient l’extension installée et active.
Cinq d’entre eux étaient connus : l’extension avait servi lors d’une migration d’hébergeur et n’avait jamais été désactivée. C’est le cas le plus banal et le plus universel — un outil de migration reste en place bien après la migration.
Les deux autres sont plus intéressants. Personne, ni côté client ni côté prestataire précédent, ne se souvenait de les avoir installés. Sur l’un des deux, l’extension datait de 2023 et n’avait jamais été mise à jour. C’est le genre de découverte qui rend l’inventaire plus utile que la veille : nous connaissions la faille en quelques heures, mais nous ne connaissions pas notre propre surface d’exposition.
Aucun des sept ne présentait de trace d’exploitation. Nous les avons tous passés en 7.110 dans la journée, en commençant par ceux dont les journaux montraient un export récent.
Notre avis d’expert (2 sur 3)
Il faut dire clairement ce que cette faille produit dans une PME, parce que la représentation habituelle est fausse. Personne ne va voler votre fichier clients : ce n’est pas rentable à cette échelle. Ce qui arrive, c’est l’insertion discrète de pages de spam, de redirections conditionnelles ou d’un accès conservé pour plus tard. Le site continue de fonctionner normalement pour ses visiteurs, et le symptôme apparaît des semaines après, sous la forme d’une chute de trafic de recherche ou d’un avertissement de navigateur. Le coût n’est alors plus celui du nettoyage — quelques heures — mais celui de la réputation auprès des moteurs, qui se compte en mois.
Savez-vous quelles extensions tournent sur vos sites ?
Nous inventorions votre parc WordPress, identifions les extensions vulnérables et vous remettons un plan de correction priorisé — avec les sites à traiter en premier.
Discutons-en — audit WordPressLes 4 vérifications, dans l’ordre
1. Inventorier avant de corriger, sur tous les sites. Comptez trente minutes pour un parc d’une trentaine de sites. Ne vous limitez pas à ceux dont vous pensez connaître la configuration : les deux découvertes surprenantes de notre inventaire étaient sur des sites que nous croyions simples.
2. Passer en 7.110 ou supérieur, en commençant par les sites ayant fait un export ou un import récemment. C’est l’opération déclencheuse : un site qui n’a rien exporté depuis deux ans est moins urgent qu’un site migré la semaine dernière. Cette hiérarchisation ne coûte rien et fait gagner la seule chose qui compte quand on traite un parc, c’est-à-dire l’ordre.
3. Inspecter les commentaires et trackbacks en attente. Cherchez des contenus anormaux, en particulier des chaînes contenant des guillemets ou des antislashs en série. Si les trackbacks ne servent à rien sur votre site — ce qui est le cas de l’immense majorité des sites d’entreprise — désactivez-les, aujourd’hui et pour de bon. C’est une réduction de surface d’attaque gratuite.
4. Vérifier les fichiers modifiés récemment dans les répertoires d’extensions et de thèmes. C’est le moyen le plus rapide de repérer un dépôt de code déjà survenu, et c’est la vérification que nous faisons systématiquement avant de conclure qu’un site n’a pas été touché. Une extension modifiée sans mise à jour correspondante est un signal fort.
Notre avis d’expert (3 sur 3)
La leçon durable ne porte pas sur cette extension en particulier, qui a été corrigée correctement et rapidement par son éditeur. Elle porte sur le cycle de vie des outils. Une extension de migration a une durée d’utilité de quelques jours et une durée de présence de plusieurs années, et cet écart est la vraie vulnérabilité. Nous avons ajouté une règle simple à nos interventions : toute extension installée pour une opération ponctuelle est désinstallée à la fin de l’opération, pas désactivée. Une extension désactivée reste sur le disque, reste dans la base, et redevient active le jour où quelqu’un fait le ménage à l’envers. C’est une discipline de trois minutes qui aurait évité cinq de nos sept cas.
Ce que cela change dans un plan de sécurité 2026
Trois arbitrages méritent d’être rejoués. L’inventaire des extensions doit exister au même titre que l’inventaire des serveurs, avec version et date de dernière mise à jour, et il doit être automatique — un inventaire tenu à la main n’est plus juste au bout de six semaines.
La politique de mise à jour doit distinguer les extensions selon leur surface : une extension qui expose un point d’entrée non authentifié ne relève pas du même délai qu’une extension de mise en forme. Fixer un délai maximal unique pour tout le monde produit soit de l’immobilisme, soit des mises à jour non testées en production.
Enfin, la réduction de surface reste le levier le moins coûteux. Trackbacks, éditeur de fichiers dans l’administration, comptes d’anciens prestataires : ce sont trois cases à traiter une fois, qui suppriment des familles entières de scénarios.
Ces questions recoupent celles que se posent les équipes de développement sur la gouvernance de leurs dépendances, documentées côté écosystème open source, et les enjeux d’architecture de données traités côté intégration IA en entreprise. Pour les organisations soumises à NIS2, la revue de périmètre est le point de départ : voir notre page audit de périmètre NIS2.
Questions fréquentes
Qu’est-ce que la faille CVE-2026-19949 et quels sites sont concernés ?
Il s’agit d’une injection SQL non authentifiée affectant l’extension WordPress All-in-One WP Migration and Backup, éditée par ServMask, présente sur plus de cinq millions d’installations actives. Wordfence la note 8,8 sur 10 sur l’échelle CVSS, ce qui la place dans la catégorie des failles critiques. Le correctif est disponible depuis la version 7.110, mais environ trente-cinq pour cent seulement des installations l’avaient appliqué au moment des premières publications, ce qui laisse plusieurs millions de sites exposés. Tout site WordPress disposant de cette extension dans une version antérieure à 7.110 est concerné, qu’il soit vitrine, boutique ou intranet, et l’exploitation ne demande aucun compte sur le site.
Comment se déroule concrètement l’attaque ?
La chaîne est en deux temps, et c’est ce qui la rend particulièrement pénible à détecter. L’attaquant dépose d’abord des données forgées par le mécanisme des trackbacks de WordPress, une fonctionnalité ancienne et ouverte par défaut sur de nombreuses installations. Ces données restent dormantes : rien ne se produit tant que personne n’y touche. Le déclenchement intervient lorsqu’un administrateur effectue une opération courante de l’extension, typiquement un export ou un import de site. À ce moment, l’extension interprète incorrectement les antislashs et les guillemets échappés, et le code SQL injecté s’exécute. Il peut alors exposer la clé secrète d’import de l’extension, l’ai1wm_secret_key, au travers d’un commentaire public que l’attaquant n’a plus qu’à lire.
Que peut faire l’attaquant une fois la clé secrète récupérée ?
Importer une archive .wpress malveillante, c’est-à-dire remplacer le contenu du site par le sien, code exécutable compris. On passe donc d’une fuite d’information à une prise de contrôle complète du site et, selon la configuration de l’hébergement, potentiellement des autres sites hébergés sur le même compte. C’est ce saut qualitatif qui justifie la note de 8,8 plutôt qu’une note moyenne d’injection SQL : la faille ne se contente pas de lire la base, elle ouvre la voie au dépôt de code. Pour une PME, l’issue typique n’est pas la fuite de données clients mais l’insertion discrète de pages de spam ou de redirections, découverte des semaines plus tard par une chute de trafic.
Quelles vérifications faire aujourd’hui si l’on gère plusieurs sites WordPress ?
Quatre, pour environ deux heures au total sur un parc d’une trentaine de sites. Vérifier la version de l’extension partout, et pas seulement sur les sites que vous croyez concernés : nous avons trouvé l’extension active sur des sites où personne ne se souvenait de l’avoir installée. Passer en 7.110 ou plus, en commençant par les sites qui ont fait un export ou un import récemment, puisque c’est l’opération déclencheuse. Inspecter les commentaires et trackbacks en attente à la recherche de contenus anormaux. Et regarder les fichiers modifiés récemment dans les répertoires d’extensions et de thèmes, ce qui reste le moyen le plus rapide de repérer un dépôt de code déjà survenu.
Combien de vos sites sont encore en version vulnérable ?
Si la réponse n’est pas immédiate, c’est la seule chose à traiter cette semaine. Nous produisons l’inventaire complet de votre parc et le plan de correction priorisé en 48 heures.
Discutons-en