L'essentiel en 30 secondes
- Logiciel
- WordPress, le cœur, et ses branches encore corrigées à partir de la 4.7
- Version corrigée
- 7.1.4, publiée le 28 octobre 2026
- Anciennes branches
- 7.0.8, 6.9.11, 6.8.12 et ainsi de suite jusqu'à 4.7.39, proposées par le serveur de mise à jour de WordPress le 29 octobre ; rien pour les versions 4.6 et antérieures
- Gravité
- Dans les onze avis publiés le 29 octobre, WordPress classe un avis en « élevé » (XSS et déni de service dans l'Interactivity API), six en « moyen » et quatre en « faible », dont la faille de la mise à jour. Pas encore de numéro CVE.
- Condition
- Un compte Contributeur ou plus pour la plupart des failles ; aucun compte pour la faille de la mise à jour et pour les modifications non publiées du Customizer
- Exploitation
- Aucune attaque signalée publiquement au 29 octobre 2026
Ce que corrige cette version
La faille qui ne demande aucun compte
Quand WordPress installe une mise à jour, une extension ou un thème, il décompresse le paquet dans le dossier wp-content/upgrade/, que le serveur web rend accessible comme n'importe quel autre dossier. Jusqu'à la 7.1.3, le dossier de travail portait le nom du paquet, donc un nom prévisible, et WordPress effaçait au passage le fichier qui empêche d'afficher la liste du contenu. Pendant les quelques secondes de l'opération, une copie complète de WordPress se trouvait donc à une adresse devinable. Un attaquant qui la consulte au bon moment pourrait, selon Patchstack, faire exécuter du code sur le serveur.
La fenêtre est très courte : WordPress note la faille « faible » et Patchstack juge son exploitation peu réaliste. Mais elle revient à chaque mise à jour, y compris les mises à jour automatiques, et Patchstack précise qu'un pare-feu installé comme extension ne voit pas passer ces requêtes. Le correctif de la 7.1.4 ajoute 16 caractères aléatoires au nom du dossier de travail, recrée le fichier index.php qui bloque l'affichage de la liste, et ne l'efface plus.
Les failles qui demandent un compte
Les autres failles permettent à un utilisateur qui peut rédiger des contenus d'y glisser du code qui s'exécutera dans le navigateur d'un visiteur ou d'un administrateur (XSS stockée). Elles touchent l'Interactivity API, qui anime certains blocs, plusieurs blocs (Catégories, Image, Playlist, pagination des commentaires), le Customizer et l'écran de suppression des données personnelles. S'y ajoutent les modifications non publiées du Customizer visibles sans compte, des Notes lisibles par des rôles personnalisés et la mise à jour des certificats racine embarqués.
Deux de ces failles ont été signalées par Anthropic, l'éditeur de Claude.
Êtes-vous concerné ? Trois situations
À faire maintenant
Votre site est en 4.6 ou plus ancien, ou ses mises à jour sont bloquées
Aucun correctif n'existe pour les versions 4.6 et antérieures, qui équipent encore 0,95 % des sites WordPress d'après les statistiques publiques de WordPress.org (sites qui contactent le serveur de mise à jour). Un site dont les mises à jour automatiques sont désactivées reste vulnérable tant que personne n'intervient.
À vérifier
Vous êtes en 7.1.3 ou sur une ancienne branche, mises à jour automatiques actives
La mise à jour doit arriver seule. Vérifiez qu'elle a bien eu lieu : une mise à jour automatique peut échouer, et WordPress ne la retente pas toujours. Ajoutez ensuite le blocage serveur décrit plus bas.
Protégé contre ces failles
Vous êtes en 7.1.4 ou sur une version rétroportée, avec le blocage serveur en place
Il reste à contrôler qui, sur votre site, a un compte capable de publier des contenus.
Vous gérez plusieurs sites
64 % des sites WordPress tournent sur la branche 7.1 d'après WordPress.org, qui ne publie pas la répartition entre 7.1.3 et 7.1.4. Seul un inventaire de vos sites dit où ils en sont. Avec WP-CLI et des alias de sites :
wp @all core versionQue faire maintenant
Vérifier la version installée, et mettre à jour si besoin
Dans l'administration de WordPress : menu Tableau de bord, puis Mises à jour. La dernière commande ci-dessous compare chaque fichier du cœur aux empreintes officielles de WordPress.org : elle doit répondre que l'installation est conforme.
wp core version
wp core update
wp core verify-checksumsBloquer l'accès web à wp-content/upgrade/
C'est la mesure que recommande Patchstack, et la seule efficace contre la faille sans compte pendant la mise à jour vers la 7.1.4 elle-même (voir notre essai). Sur un serveur qui lit les fichiers .htaccess (Apache, LiteSpeed), placez la règle dans wp-content/.htaccess, pas dans le dossier upgrade. Nous l'avons testée sur Apache. Sur Nginx, la règle va dans la configuration du site, ce qui demande en général l'hébergeur ; équivalent, que nous n'avons pas testé : location ^~ /wp-content/upgrade/ { deny all; }
<IfModule mod_alias.c>
RedirectMatch 403 /wp-content/upgrade/
</IfModule>Contrôler que le dossier ne s'affiche plus
Ouvrez https://votre-site.fr/wp-content/upgrade/ dans un navigateur. Une erreur 403 est le bon résultat ; une page « Index of » signifie que le contenu du dossier peut être listé.
Revoir les comptes qui peuvent écrire
Toutes les failles sauf deux partent d'un compte Contributeur ou plus. Supprimez les comptes d'anciens rédacteurs ou prestataires. Les comptes clients d'une boutique WooCommerce ont le rôle Client, qui ne permet pas de rédiger d'articles.
wp user list --role__in=contributor,author,editor,administrator --fields=ID,user_login,roles,user_registeredCe que nous avons vérifié
Nous avons rejoué la mise à jour le 29 octobre 2026 sur une installation locale de test (WordPress 7.1.3 en français, Apache 2.4.66, PHP 8.3.30), sans jamais sonder la fenêtre de la faille. Chaque essai part de la même sauvegarde, restaurée à l'identique à la fin.
| Vérification | Ce que nous avons observé |
|---|---|
Le dossier wp-content/upgrade/ en 7.1.3, entre deux mises à jour | Vide, sans fichier index.php. Le serveur affichait la page « Index of » : le contenu du dossier peut être listé. |
Une règle de blocage placée dans wp-content/upgrade/.htaccess | Elle bloquait l'accès (erreur 403)… jusqu'à la mise à jour, qui a effacé le fichier. Après la mise à jour, le dossier était de nouveau listable. Le code de la 7.1.4 ne conserve que index.php lors de ce nettoyage : une règle placée là disparaîtra à chaque mise à jour. |
| Le dossier juste après le passage en 7.1.4 | Toujours sans index.php. La mise à jour vers la 7.1.4 est exécutée par le code de la version installée, la 7.1.3 : la nouvelle protection ne s'applique donc pas à cette mise à jour-là. |
| La première installation suivante (une extension officielle) | Le fichier index.php est apparu et le dossier n'était plus listé : la protection de la 7.1.4 s'active à partir de la prochaine installation ou mise à jour. |
La règle placée un niveau au-dessus, dans wp-content/.htaccess | Le dossier et ses sous-dossiers répondaient 403, la page d'accueil et les fichiers du thème 200. La mise à jour vers la 7.1.4 a réussi, la règle est restée en place, l'installation suivante aussi, et wp core verify-checksums a confirmé l'intégrité du cœur. |
| Fichiers changés par la mise à jour | 50 fichiers du cœur modifiés, aucun supprimé. |
La leçon pratique : la mise à jour seule ne ferme pas la fenêtre de la mise à jour qui l'installe, et un blocage placé dans le dossier lui-même ne survit pas. Le blocage utile se place au-dessus, ou dans la configuration du serveur. L'affichage de la liste dépend de la configuration de chaque hébergeur : faites le contrôle du point 3 sur votre propre site.
Les indices à vérifier, et ce que notre scan en voit
Nous indiquons pour chaque indice ce que Genisoft Security détecte aujourd'hui, sans arrondir. Pour cette mise à jour, l'essentiel se vérifie à la main.
| Indice | Où chercher | Notre scan |
|---|---|---|
| WordPress 7.1.3 ou version non corrigée d'une ancienne branche | Tableau de bord, puis Mises à jour | Oui. Depuis le 30 octobre 2026, le scan compare la version du cœur à la liste des versions publiées par WordPress.org, sans attendre les bases de failles : une 7.1.3, ou une ancienne branche sans son dernier correctif, est signalée avec la version à installer. Une version 4.6 ou plus ancienne est signalée comme n'ayant plus de correctif. |
| Dossier wp-content/upgrade/ consultable depuis le web | Navigateur, adresse du dossier | Non. Le scan lit les fichiers du site par notre extension, pas la configuration du serveur web. |
| Fichier du cœur modifié ou ajouté après une attaque | Dossiers wp-admin et wp-includes | Oui. Chaque fichier du cœur est comparé aux empreintes officielles de WordPress.org ; un fichier PHP étranger dans ces dossiers est signalé. |
| Code injecté dans un contenu publié | Articles et pages | En partie. Les contenus publiés qui contiennent des balises script ou iframe, ou certaines fonctions JavaScript, sont signalés. Les attributs de l'Interactivity API et les liens « javascript: » ne le sont pas, ni les brouillons. |
| Compte récent avec des droits élevés | Utilisateurs | En partie. Le scan signale les administrateurs et éditeurs inscrits depuis moins de 30 jours ou dont l'identifiant est atypique. Les comptes Contributeur et Auteur ne sont pas examinés. |
| Porte dérobée déposée après une exécution de code | Fichiers du site | En partie. Les portes dérobées connues sont reconnues par nos règles de détection ; une variante chiffrée peut passer. |
Votre site a-t-il été modifié avant la mise à jour ? Contrôlez ses fichiers
Le scan unique analyse les fichiers et une partie de la base de votre WordPress, et classe chaque élément en menace confirmée, à vérifier ou informatif. Si une menace est confirmée, le Nettoyage accompagné (249 €) remet le site en état pour vous : sauvegarde vérifiée, quarantaine réversible et remplacement par les versions officielles.
Paiement unique, sans abonnement. Il faut créer un compte et installer sur le site notre extension de connexion, qui fonctionne en lecture seule. Le scan ne vérifie ni le serveur ni les secrets : ces étapes restent à faire.
Ce que cette mise à jour rappelle
Le moment de la mise à jour est lui-même exposé
Un dossier temporaire servi par le web a suffi à créer une faille sans compte, présente depuis la version 2.8 selon Patchstack. Tout ce qui est décompressé sous la racine du site doit être inaccessible depuis le web.
Une mise à jour s'installe avec le code de la version précédente
Une protection ajoutée au processus de mise à jour ne vaut que pour les mises à jour suivantes. C'est pour cela que le réglage serveur compte, justement cette semaine.
Le rôle Contributeur n'est pas anodin
Presque toutes ces failles partent d'un compte qui peut rédiger. Un compte de rédacteur oublié est une porte ouverte : faites le ménage après chaque collaboration.
Une base de failles a un temps de retard
Le 29 octobre au soir, plus d'une journée après le correctif, la base publique qu'utilise notre scan ne recensait pas encore ces failles. Pendant ce délai, seule la comparaison avec la dernière version publiée dit si un site est à jour : notre scan la fait depuis le 30 octobre.
Pour aller plus loin, notre guide pour vérifier l'intégrité des fichiers WordPress et notre checklist pour sécuriser WordPress.
Questions fréquentes
Mon site se met à jour tout seul : ai-je quelque chose à faire ?
Vérifiez que la mise à jour a bien eu lieu (Tableau de bord, puis Mises à jour, ou wp core version). Une mise à jour automatique qui échoue n'est pas toujours retentée. Ajoutez le blocage de wp-content/upgrade/ : la mise à jour automatique vers la 7.1.4 se fait encore avec l'ancien code.
Je suis en 6.8 et je ne peux pas passer en 7.1 tout de suite. Suis-je protégé ?
Oui, si votre site a reçu la version 6.8.12, qui contient les correctifs applicables à cette branche. WordPress rappelle toutefois que seule la dernière version est réellement maintenue : planifiez le passage en 7.1.
Le pare-feu de mon extension de sécurité suffit-il ?
Pas pour la faille de la mise à jour : d'après Patchstack, la copie décompressée ne charge pas les extensions du site, donc pas leur pare-feu. Le blocage doit se faire au niveau du serveur web.
Mon site est une boutique WooCommerce. Mes clients peuvent-ils exploiter ces failles ?
Pas avec un compte client : ce rôle ne permet pas de rédiger de contenu. Le risque vient des comptes d'équipe (contributeurs, auteurs, éditeurs) et des deux failles sans compte : celle de la mise à jour et l'exposition des modifications non publiées du Customizer.
Chronologie et sources
| Date | Événement |
|---|---|
| Publication de WordPress 7.1.4 et de la 7.2 bêta 3. Analyse de Patchstack, qui annonce les versions rétroportées jusqu'à 4.7.39 le jour même ; WordPress.org les indiquait encore « en cours ». | |
| Le serveur de mise à jour de WordPress propose les versions rétroportées, de 7.0.8 à 4.7.39. Le soir, WordPress publie onze avis de sécurité sur GitHub, sans numéro CVE. Aucune exploitation signalée publiquement. |
- WordPress.org, WordPress 7.1.4, 28 octobre 2026, modifié le 29 octobre (en anglais). Source de référence pour la liste des failles et leurs découvreurs.
- WordPress, avis de sécurité du dépôt wordpress-develop, 29 octobre 2026 (en anglais) : gravités et versions corrigées par branche. Onze avis étaient publics le 29 octobre au soir ; Patchstack en décompte dix-sept.
- Patchstack, WordPress 7.1.4 Security Release, 28 octobre 2026 (en anglais) : conditions de chaque faille et fonctionnement du correctif.
- WordPress.org, statistiques des versions et versions proposées par le serveur de mise à jour, relevés du 29 octobre 2026.
- Code de WordPress 7.1.3 et 7.1.4 (dépôt WordPress/WordPress), fichiers
wp-admin/includes/class-wp-upgrader.phpetupdate-core.php.
Les avis de WordPress et de Patchstack peuvent évoluer : ils restent la référence en cas d'écart avec cette page, dont la date de mise à jour figure en tête d'article.
Comment cet article a été produit : faits vérifiés le 29 octobre 2026 dans les sources ci-dessus ; lecture du correctif entre les versions 7.1.3 et 7.1.4, relevé des statistiques de versions de WordPress.org, lecture du code de notre scanner et essai de la mise à jour et du blocage serveur sur une installation WordPress de test. Rédigé avec l'aide de Claude (Anthropic), dont l'éditeur a signalé deux des failles corrigées, puis relu et validé par l'équipe Genisoft Security avant publication.
Voir à quoi ressemble un vrai rapport
Nous publions un rapport de scan réel, consultable sans créer de compte. Vous y verrez comment chaque élément est classé, et pourquoi un fichier signalé n'est pas forcément une infection.
