All-in-One WP Migration et Gravity Forms : deux failles sans authentification corrigées en silence, 3,25 millions de sites en retard

Deux correctifs de sécurité que rien ne signalait

Le 2 septembre 2026, le site spécialisé webhosting.today a relevé une coïncidence embarrassante. Deux vulnérabilités exploitables sans compte venaient d'être rendues publiques, dans All-in-One WP Migration and Backup et dans Gravity Forms, et leurs correctifs avaient été publiés le même jour, le 20 août. Ce qui rend le cas instructif n'est pas la gravité des failles, mais la façon dont elles ont été annoncées : le journal des modifications de la première décrivait un correctif de gravité élevée comme un ajustement de remplacement de texte, celui de la seconde utilisait une formule passe-partout que l'éditeur emploie aussi pour ses versions ordinaires. Quiconque devait décider quels sites mettre à jour en priorité n'avait rien pour trancher.

Extension	Faille et versions touchées	Correctif du 20 août 2026 et intitulé dans le journal des modifications	Fiche CVE publique
All-in-One WP Migration and Backup (plus de 5 millions d'installations)	CVE-2026-19949, injection SQL de second ordre sans authentification, CVSS 8.8. Versions 7.109 et antérieures	7.110 : « Find and replace on values ending in a backslash. Special thanks to Jack Taylor for responsibly disclosing this issue. »	25 août (5 jours après)
Gravity Forms (extension commerciale, hors dépôt WordPress.org)	CVE-2026-19513, envoi de fichier arbitraire sans authentification, CVSS 8.1. Versions 3.0.2 et antérieures	3.0.3 : « Added security enhancements »	1er septembre (12 jours après)

All-in-One WP Migration : une injection qui attend que l'administrateur restaure

La faille, signalée le 14 août par le chercheur Jack Taylor via le programme de primes de Wordfence et transmise à l'éditeur ServMask le 15 août, se loge dans la fonction de restauration d'archive. Pendant une restauration, l'extension réécrit le contenu de la base de données (adresses, chemins) et analyse mal les antislashs et guillemets échappés. Wordfence, qui a publié son analyse complète le 2 septembre, décrit une attaque en deux temps : un visiteur anonyme dépose d'abord des données piégées via les rétroliens (trackbacks) de WordPress ; rien ne se passe tant que l'administrateur n'exporte puis ne réimporte pas le site. À ce moment, le traitement des délimiteurs de chaîne exécute les données stockées comme du SQL.

L'injection permet d'exposer la clé secrète d'import de l'extension (ai1wm_secret_key) dans un commentaire public. Avec cette clé, l'attaquant importe sa propre archive .wpress, qui peut contenir du code exécutable : c'est la prise de contrôle complète. Comme le note Wordfence, sauvegarder et restaurer est la raison d'être de l'extension, l'action déclenchante finira donc par se produire. Une version vulnérable désactivée présente moins de risque, mais redevient exploitable dès qu'on l'active le temps d'une migration.

Trois chiffres qui ne disent pas la même chose

webhosting.today relève que les signaux publics divergeaient : un CVSS de 8,8 dans la fiche CVE, une priorité « faible » chez Patchstack, dont la base jugeait d'abord l'exploitation improbable, et 5 millions d'installations sur WordPress.org. Le 4 septembre, après la publication de l'analyse de Wordfence, Patchstack a relevé sa priorité à « moyenne », l'issue étant désormais « susceptible d'être exploitée ». Un hébergeur ou une agence qui ne lisait qu'un seul de ces trois chiffres aurait soit alarmé ses clients pour rien, soit repoussé la mise à jour.

Le retard de mise à jour, lui, est mesurable : d'après les statistiques de WordPress.org relayées par BleepingComputer, seuls 35 % environ des sites avaient installé la 7.110 au 3 septembre, ce qui laisse quelque 3,25 millions de sites avec une version vulnérable. Une extension de sauvegarde est typiquement installée, utilisée une fois pour une migration, puis oubliée.

Gravity Forms : un envoi de fichier dont l'issue dépend de votre serveur

La faille de Gravity Forms, créditée à Alex Thomas et à Wordfence Argus, touche la gestion des envois de fichiers multiples. Un attaquant non authentifié peut abuser de l'état des envois par morceaux (chunked upload) sur n'importe quel formulaire public doté d'un champ Fichier avec l'option « Fichiers multiples », et déposer un polyglotte, un fichier construit pour passer les contrôles d'image ou de PDF tout en contenant autre chose, sous un nom .php ou .html de son choix, dans le dossier temporaire d'envoi de l'extension.

La suite dépend du serveur. Gravity Forms place un fichier .htaccess dans ce dossier à l'installation et à l'activation, qui bloque l'exécution de PHP sur les serveurs qui le lisent, Apache et LiteSpeed en général ; le risque résiduel y est un XSS stocké contre les visiteurs qui ouvrent l'adresse du fichier. Sur NGINX et les autres serveurs qui ignorent .htaccess, le même envoi peut mener à une exécution de code. En hébergement infogéré, ce réglage appartient à l'hébergeur, pas au propriétaire du site. Par le décompte de webhosting.today sur la base Patchstack, c'est le quatrième envoi de fichier arbitraire sans authentification recensé dans Gravity Forms depuis novembre 2025 ; nous avions déjà traité l'un d'eux dans nos alertes d'avril 2026.

Que vérifier sur vos sites

Les versions installées

wp plugin get all-in-one-wp-migration --field=version
wp plugin get gravityforms --field=version

All-in-One WP Migration doit être en 7.110 ou plus, Gravity Forms en 3.0.3 ou plus. Gravity Forms est commercial et se met à jour via le canal de l'éditeur : une licence expirée bloque la mise à jour sans le signaler. Si All-in-One WP Migration n'a servi qu'à une migration passée, désinstallez-le plutôt que de le laisser désactivé : la faille redevient active dès qu'on le réactive, et une extension de moins est une surface d'attaque de moins. Notre guide des sauvegardes WordPress explique comment organiser des sauvegardes régulières sans dépendre d'une extension de migration ponctuelle.

Les rétroliens et les commentaires

Le vecteur d'entrée de la faille All-in-One WP Migration est le rétrolien, une fonction que presque plus personne n'utilise. Désactivez-la globalement (Réglages, Discussion, « Autoriser les notifications de liens depuis d'autres blogs ») et sur les articles existants, puis cherchez dans la base les rétroliens et commentaires qui contiennent un antislash (caractère 92), inhabituel dans un commentaire légitime et signature possible d'une tentative :

wp db query "UPDATE wp_posts SET ping_status='closed' WHERE ping_status='open'"
wp db query "SELECT comment_ID, comment_type, comment_author_url, comment_date FROM wp_comments WHERE comment_type IN ('trackback','pingback') ORDER BY comment_date DESC LIMIT 50"
wp db query "SELECT comment_ID, comment_type, comment_date FROM wp_comments WHERE INSTR(comment_content, CHAR(92)) > 0 OR INSTR(comment_author, CHAR(92)) > 0 OR INSTR(comment_author_url, CHAR(92)) > 0"

Si vous avez restauré une archive entre la mi-août et la mise à jour, contrôlez aussi les commentaires publiés depuis, à la recherche d'une chaîne ressemblant à une clé (ai1wm_secret_key), et changez la clé en réinstallant l'extension à jour. Le réglage des commentaires et des rétroliens fait partie des bases que nous recommandons sur tout site.

Le dossier d'envoi de Gravity Forms

Listez les fichiers .php et .html dans le dossier d'envoi de l'extension, sous wp-content/uploads/gravity_forms/, et vérifiez que votre serveur refuse d'y exécuter du PHP, en particulier sous NGINX où le .htaccess de l'extension ne sert à rien :

find wp-content/uploads/gravity_forms -type f \( -name "*.php" -o -name "*.html" -o -name "*.phtml" \)
curl -s -o /dev/null -w "%{http_code}\n" https://votre-site.fr/wp-content/uploads/gravity_forms/test.php

Un serveur correctement configuré répond 403 ou 404 à la seconde commande, jamais 200 avec une exécution. La configuration est décrite dans notre tutoriel pour bloquer l'exécution PHP dans uploads, avec les directives Apache et NGINX.

Ce qu'un propriétaire de site peut en tirer

La leçon de webhosting.today s'adresse aux hébergeurs, mais elle vaut pour toute personne qui gère plus d'un site : le journal des modifications n'est pas un flux de sécurité. L'un de ces correctifs était décrit comme une manipulation de texte, l'autre avec une phrase qui décore aussi les versions majeures. Les signaux fiables, fiches CVE et bases de vulnérabilités, sont arrivés 5 et 12 jours après les correctifs. Dans les deux cas, la politique ennuyeuse a battu la politique informée : un site qui applique toutes les mises à jour d'extensions dans la journée était protégé avant même que la faille ait un nom.

• Mises à jour automatiques des extensions, au moins pour celles qui n'ont pas de mise en page à casser, ou déploiement le jour même après test pour les autres. C'est le cœur de notre approche des mises à jour WordPress.
• Abonnez-vous aux bases de vulnérabilités plutôt qu'aux notes de version : rapports hebdomadaires de Wordfence Intelligence, flux Patchstack, et traitez toute mise à jour qui remercie un chercheur par son nom comme un correctif de sécurité jusqu'à preuve du contraire.
• Réduisez le nombre d'extensions. Une extension de migration utilisée une fois et une fonction de rétroliens que personne ne lit sont deux surfaces d'attaque gratuites. Le même raisonnement vaut pour les champs de fichier des formulaires, cible principale des vulnérabilités d'envoi de fichiers cet été.

Sources

• webhosting.today, Natalia Nowak, « A High-Severity Patch for Five Million WordPress Sites Was Labeled as a Text Fix », 2 septembre 2026 (mise à jour du 4 septembre), webhosting.today
• BleepingComputer, « WordPress backup plugin flaw exposes millions of sites to takeover attacks », 3 septembre 2026, bleepingcomputer.com
• CVE Program, fiche CVE-2026-19949, cve.org
• CVE Program, fiche CVE-2026-19513, cve.org
• WordPress.org, fiche de l'extension « All-in-One WP Migration and Backup », wordpress.org