Faille All-in-One WP Migration : plus de 5 millions de sites WordPress concernés

Une nouvelle faille All-in-One WP Migration vient rappeler qu’un plugin de sauvegarde peut devenir un point critique de la sécurité d’un site WordPress.

La vulnérabilité, référencée CVE-2026-19949, touche All-in-One WP Migration and Backup jusqu’à la version 7.109 incluse. Wordfence la classe avec un score CVSS de 8,8/10, soit un niveau de sévérité élevé. Elle permet une injection SQL de second ordre non authentifiée pouvant, dans certaines conditions, mener jusqu’à une exécution de code à distance.

Le plugin est particulièrement sensible car il compte plus de 5 millions d’installations actives sur WordPress.org. La version 7.110 corrige le problème et doit être installée sans attendre sur les sites encore vulnérables.

Le plus important à comprendre est que l’attaque ne fonctionne pas exactement comme une injection SQL classique : la donnée malveillante peut être enregistrée à un premier moment, puis déclencher la vulnérabilité plus tard lors d’une opération d’export ou de restauration.

Voici ce qu’il faut savoir et surtout ce qu’il faut vérifier sur votre site.

Qu’est-ce qu’All-in-One WP Migration and Backup ?

All-in-One WP Migration and Backup est l’un des plugins de migration WordPress les plus connus.

Il permet notamment de :

• exporter un site WordPress ;
• importer un site sur un autre hébergement ;
• créer des sauvegardes ;
• restaurer un site ;
• déplacer une installation WordPress ;
• modifier certaines valeurs pendant une migration.

Son succès vient en grande partie de sa simplicité : on exporte un site sous forme d’archive, puis on le réimporte ailleurs.

Le plugin est particulièrement sensible car il compte plus de 5 millions d’installations actives, selon la fiche officielle All-in-One WP Migration sur WordPress.org

Quelle est la faille All-in-One WP Migration CVE-2026-19949 ?

La vulnérabilité est référencée :

CVE-2026-19949

Elle est décrite par Wordfence comme une :

injection SQL de second ordre non authentifiée lors de la restauration d’une archive, pouvant conduire à une exécution de code à distance.

Les versions vulnérables sont :

All-in-One WP Migration ≤ 7.109

La première version corrigée est :

All-in-One WP Migration 7.110

Le changelog officiel du plugin confirme d’ailleurs que la version 7.110 corrige un problème lié au traitement des valeurs se terminant par un antislash et remercie le chercheur Jack Taylor pour la divulgation responsable.

Pourquoi parle-t-on d’injection SQL de second ordre ?

C’est ce qui rend cette vulnérabilité particulièrement intéressante techniquement.

Une injection SQL classique fonctionne souvent ainsi :

entrée malveillante

↓

requête SQL vulnérable

↓

exécution immédiate

Une injection SQL de second ordre fonctionne différemment.

La donnée malveillante peut d’abord être :

1. reçue par l’application ;
2. stockée dans la base ;
3. conservée pendant un certain temps ;
4. réutilisée plus tard dans un contexte vulnérable.

C’est seulement au moment où l’application réutilise cette donnée que l’injection SQL peut être déclenchée.

Dans le cas d’All-in-One WP Migration, le problème intervient notamment lors du traitement de certaines valeurs pendant une opération d’exportation ou de restauration.

Cela signifie que l’attaque peut rester dormante jusqu’à ce qu’un administrateur effectue une action parfaitement légitime.

Pourquoi cette faille est-elle dangereuse ?

Une injection SQL permet potentiellement à un attaquant d’interagir de manière non autorisée avec la base de données.

Selon le contexte et les protections présentes, cela peut permettre de :

• lire certaines données ;
• contourner certains traitements ;
• récupérer des informations sensibles ;
• modifier certaines valeurs ;
• préparer une compromission plus large.

Dans le cas de CVE-2026-19949, Wordfence indique que la chaîne d’exploitation peut aller jusqu’à une Remote Code Execution, c’est-à-dire une exécution de code à distance.

À ce stade, la vulnérabilité ne concerne plus seulement la base de données.

Une exécution de code réussie peut permettre, selon les droits obtenus et la configuration du serveur :

• installation d’une backdoor ;
• modification de fichiers WordPress ;
• création d’un compte administrateur ;
• injection de malware ;
• redirections frauduleuses ;
• vol de données ;
• prise de contrôle du site.

Faut-il être connecté à WordPress pour exploiter la faille ?

Non pour la première étape.

Wordfence classe CVE-2026-19949 comme une vulnérabilité non authentifiée.

Cela signifie qu’un attaquant n’a pas nécessairement besoin d’un compte WordPress pour introduire la donnée qui sera utilisée ensuite.

C’est l’un des éléments qui augmente la gravité de la vulnérabilité.

Il faut toutefois éviter une simplification :

cela ne signifie pas qu’un attaquant peut systématiquement prendre immédiatement le contrôle de n’importe quel site utilisant le plugin.

L’exploitation complète dépend du déroulement de la chaîne d’attaque et du moment où la donnée stockée est réutilisée.

Pourquoi l’export ou la restauration du site peut déclencher l’attaque ?

All-in-One WP Migration travaille directement sur les données WordPress pour :

• les exporter ;
• les transformer ;
• remplacer certaines chaînes ;
• les restaurer sur une autre installation.

La vulnérabilité se situe justement dans ce processus de traitement.

Une donnée préalablement enregistrée dans WordPress peut sembler inoffensive lorsqu’elle est stockée.

Mais lorsqu’elle est ensuite traitée pendant une exportation ou une restauration, un défaut d’échappement peut transformer cette valeur en partie d’une requête SQL dangereuse.

C’est pour cela qu’on parle d’une vulnérabilité de second ordre.

Une sauvegarde WordPress peut-elle devenir dangereuse ?

C’est l’une des grandes leçons de cette faille.

Nous avons tendance à considérer une sauvegarde comme automatiquement sûre.

Ce n’est pas toujours vrai.

Une sauvegarde peut contenir :

• fichiers compromis ;
• données malveillantes ;
• comptes frauduleux ;
• scripts injectés ;
• valeurs conçues pour exploiter une vulnérabilité ultérieure.

Ainsi, restaurer une sauvegarde infectée peut parfois :

réintroduire exactement le problème que vous pensiez avoir supprimé.

Une bonne stratégie de sauvegarde doit donc inclure non seulement la conservation des archives, mais aussi leur intégrité et leur origine.

Quelle version corrige CVE-2026-19949 ?

La vulnérabilité affecte les versions :

7.109 et antérieures

La version corrigée est :

7.110

WordPress.org affiche actuellement la version 7.110 et précise dans son changelog que le correctif concerne le traitement des valeurs se terminant par un antislash.

La page officielle indique également que le plugin a été mis à jour récemment et reste installé sur plus de 5 millions de sites.

Comment vérifier votre version All-in-One WP Migration ?

Dans WordPress :

Tableau de bord → Extensions → Extensions installées

Recherchez :

All-in-One WP Migration and Backup

Vérifiez ensuite le numéro de version.

Si votre site utilise :

• 7.109 ;
• 7.108 ;
• 7.107 ;
• ou toute version antérieure ;

effectuez la mise à jour.

Faut-il installer exactement la version 7.110 ?

Au minimum, oui.

Mais la meilleure règle est :

installez toujours la dernière version stable disponible du plugin.

Aujourd’hui, WordPress.org affiche 7.110.

Si une version plus récente apparaît après la publication de cet article, privilégiez cette dernière plutôt que de rester volontairement sur 7.110.

Que faire avant de mettre le plugin à jour ?

Sur un site important, évitez les mises à jour à l’aveugle.

Voici la bonne méthode.

1. Faites une sauvegarde

Conservez :

• fichiers ;
• base de données ;
• configuration serveur.

Mais si vous suspectez déjà une compromission, ne considérez pas cette sauvegarde comme automatiquement saine.

2. Vérifiez l’état du site

Avant la mise à jour, notez :

• comptes administrateurs ;
• extensions installées ;
• fichiers récemment modifiés ;
• éventuelles redirections ;
• alertes de sécurité.

Cela vous permettra de détecter plus facilement un changement anormal.

3. Mettez à jour All-in-One WP Migration

Installez 7.110 ou une version ultérieure.

4. Vérifiez ensuite le fonctionnement du site

Testez :

• front-office ;
• administration ;
• formulaires ;
• sauvegardes ;
• éventuelles tâches automatisées.

La mise à jour suffit-elle ?

Si vous découvrez des fichiers inconnus, des comptes administrateurs suspects ou des modifications que vous n’avez pas effectuées, ne vous contentez pas de mettre l’extension à jour. Consultez notre guide Site WordPress piraté : que faire ? pour suivre une procédure de confinement, d’analyse et de nettoyage du site.

Elle corrige la vulnérabilité, mais elle ne prouve pas que le site n’a jamais été compromis.

C’est une distinction importante.

Imaginez :

1er septembre : vulnérabilité exploitée

2 septembre : backdoor installée

4 septembre : plugin mis à jour

La vulnérabilité est maintenant corrigée.

Mais la backdoor installée auparavant peut toujours exister.

C’est pourquoi un site ayant utilisé une version vulnérable mérite quelques vérifications supplémentaires.

Que vérifier après la mise à jour ?

1. Les comptes administrateurs

Dans :

Utilisateurs → Tous les utilisateurs

recherchez :

• compte inconnu ;
• compte créé récemment ;
• adresse email modifiée ;
• privilège administrateur inattendu.

2. Les plugins installés

Contrôlez que toutes les extensions correspondent réellement à celles que vous utilisez.

Un plugin inconnu ou récemment ajouté doit être investigué.

3. Les fichiers récemment modifiés

Examinez notamment :

• wp-config.php ;
• fichiers du thème ;
• plugins ;
• dossier uploads ;
• fichiers PHP inhabituels.

Un fichier PHP dans un endroit où il ne devrait pas être mérite une attention particulière.

4. Les sauvegardes récentes

Si vous avez effectué un export ou une restauration avec une version vulnérable, conservez l’archive mais ne la considérez pas nécessairement comme fiable.

Identifiez :

• date de création ;
• site d’origine ;
• version du plugin utilisée ;
• contexte dans lequel elle a été générée.

5. Les journaux du serveur

Les logs peuvent permettre d’identifier :

• accès inhabituels ;
• requêtes suspectes ;
• actions effectuées avant la compromission ;
• connexions provenant d’adresses IP inconnues.

Pour une investigation sérieuse, ces journaux peuvent être plus utiles qu’un simple scan antivirus.

Faut-il changer les mots de passe ?

Pas systématiquement après une simple mise à jour.

En revanche, si vous observez des signes de compromission, changez notamment :

• mot de passe administrateur WordPress ;
• hébergement ;
• FTP/SFTP ;
• base de données si nécessaire ;
• clés API ;
• comptes email liés au site.

Faites-le idéalement depuis un appareil considéré comme sain.

Faut-il renouveler les clés WordPress ?

En cas de compromission avérée ou fortement suspectée, il peut être prudent de renouveler les salts WordPress.

Cela permet notamment d’invalider les sessions existantes et d’obliger les utilisateurs à se reconnecter.

C’est utile lorsqu’un attaquant pourrait avoir récupéré des cookies ou des informations de session.

Désactiver les trackbacks protège-t-il contre la faille ?

Les trackbacks et pingbacks peuvent augmenter inutilement la surface d’attaque d’un site lorsqu’ils ne sont pas utilisés.

Les désactiver peut donc être pertinent.

Mais attention :

désactiver les trackbacks ne remplace absolument pas la mise à jour du plugin.

La seule véritable correction de CVE-2026-19949 est l’installation d’une version corrigée.

Faut-il bloquer toute l’API REST WordPress ?

Je ne recommande pas de bloquer complètement l’API REST sans raison.

De nombreux composants WordPress utilisent cette API :

• Gutenberg ;
• plugins ;
• WooCommerce ;
• applications ;
• automatisations.

La bloquer entièrement peut casser certaines fonctionnalités.

Une meilleure approche consiste à :

• appliquer les mises à jour ;
• limiter uniquement les endpoints inutiles si nécessaire ;
• contrôler les permissions ;
• utiliser un pare-feu applicatif ;
• surveiller les requêtes suspectes.

Wordfence suffit-il pour protéger le site ?

Un pare-feu peut apporter une couche de protection supplémentaire.

Mais il ne doit pas être considéré comme un substitut au patch.

La règle est :

mise à jour

pare-feu

MFA

sauvegardes

surveillance

Aucune extension de sécurité ne rend un site invulnérable.

Pourquoi les plugins de sauvegarde sont particulièrement sensibles

Un plugin de sauvegarde ou de migration possède souvent des privilèges très importants.

Il peut accéder à :

• base de données ;
• fichiers ;
• archives ;
• configurations ;
• chemins serveur.

Par définition, il doit être capable de manipuler une très grande partie du site.

Une vulnérabilité dans ce type d’extension mérite donc une attention particulière.

Le même raisonnement vaut pour :

• plugins de sécurité ;
• gestionnaires de fichiers ;
• constructeurs de sauvegarde ;
• plugins d’import/export.

Cette précaution est particulièrement importante après une vulnérabilité critique. Nous avons également détaillé 7 vérifications à effectuer après une faille WordPress en 2026 afin de rechercher les traces qu’une simple mise à jour ne peut pas supprimer.

Une autre raison de surveiller All-in-One WP Migration

Le changelog récent montre que le plugin a reçu plusieurs autres corrections de sécurité.

Par exemple, la version 7.106 a corrigé une vulnérabilité de path traversal non authentifiée, et la version 7.103 avait également corrigé des problèmes de traversal lors de la lecture et de l’extraction de fichiers.

Cela ne signifie pas que le plugin est « dangereux ».

Au contraire, cela montre qu’il est activement maintenu et que les problèmes signalés sont corrigés.

Mais cela souligne aussi pourquoi il est essentiel de ne pas conserver une ancienne version pendant plusieurs mois.

Faut-il supprimer All-in-One WP Migration ?

Non, si vous l’utilisez et qu’il est à jour.

Le plugin reste activement maintenu et très largement utilisé.

En revanche, si vous ne l’utilisez plus :

supprimez-le.

Un plugin inutile ajoute :

• du code ;
• des fichiers ;
• des endpoints ;
• une surface d’attaque.

Désactiver une extension est déjà mieux que la laisser active, mais la supprimer est préférable lorsqu’elle n’a plus d’utilité.

Faille All-in-One WP Migration : checklist immédiate

Si votre site utilise le plugin :

1. Vérifiez la version installée.
2. Mettez à jour vers 7.110 ou une version ultérieure.
3. Vérifiez les comptes administrateurs.
4. Contrôlez les extensions récemment ajoutées.
5. Examinez les fichiers modifiés.
6. Vérifiez les sauvegardes récentes.
7. Consultez les logs de l’hébergement.
8. Activez la MFA sur les comptes sensibles.
9. Supprimez les plugins inutilisés.
10. Surveillez le site dans les jours qui suivent.

FAQ – Faille All-in-One WP Migration

Conclusion : mettez All-in-One WP Migration à jour maintenant

La faille All-in-One WP Migration CVE-2026-19949 mérite une attention rapide en raison de trois facteurs :

• plus de 5 millions d’installations actives ;
• aucune authentification requise pour certaines étapes de l’attaque ;
• possibilité d’évolution vers une compromission beaucoup plus importante.

La priorité est donc simple :

mettez All-in-One WP Migration à jour vers la version 7.110 ou une version plus récente dès qu’elle est disponible.

Mais ne vous arrêtez pas à la mise à jour si le site est resté longtemps sur une version vulnérable.

Vérifiez également :

• administrateurs ;
• fichiers ;
• sauvegardes ;
• plugins ;
• logs.

Une mise à jour ferme une porte.

Elle ne supprime pas nécessairement ce qui aurait pu entrer avant sa fermeture.