WordPress 7.1.4 : votre site a-t-il reçu la mise à jour de sécurité ?

Votre site a-t-il installé la 7.1.4 ?

La 7.1.4, publiée le 28 octobre, corrige 22 failles (la page officielle de la version, en anglais). Pour connaître le numéro installé sur votre site, ouvrez Tableau de bord, puis Mises à jour : il figure sur la ligne « Version actuelle ». Le lien « Obtenir la version 7.1.4 », en bas des écrans de l’administration, ne suffit pas à conclure. Il s’affiche aussi sur un site resté sur une série plus ancienne, même une fois le correctif de cette série installé.

Sauf réglage contraire, WordPress installe seul ses versions de sécurité. Il cherche une nouvelle version deux fois par jour (documentation des développeurs de WordPress, en anglais). Un site dont les mises à jour automatiques fonctionnent a donc normalement reçu la 7.1.4, ou la version corrigée de sa série, dans la journée qui a suivi sa sortie.

Pour savoir si ce mécanisme fonctionne chez vous, ouvrez Outils, puis Santé du site. Dans l’onglet « État », cliquez sur « Tests passés avec succès » pour dérouler la liste : le test « Les mises à jour d’arrière-plan fonctionnent » doit y figurer. Si vous lisez plutôt « Les mises à jour d’arrière-plan ne fonctionnent pas comme prévu », dépliez ce message : WordPress y donne la cause. Ce message est normal si un service de maintenance installe les mises à jour à la place de WordPress : certains, dont Maintena, coupent volontairement ce mécanisme.

Voici la version qui contient les correctifs, selon la série de votre site. WordPress en a publié une pour chaque série depuis la 4.7 :

Si votre site est en 7.1 et que la mise à jour ne s’est pas faite, sauvegardez ses fichiers et sa base de données, puis cliquez sur « Mettre à jour vers la version 7.1.4 » dans l’écran Mises à jour.

Sur une série plus ancienne, ce même bouton fait passer le site à la 7.1, une version majeure qui se prépare. L’écran Mises à jour ne propose pas la version corrigée de votre série : seule la mise à jour automatique de WordPress l’installe. Si elle est coupée, demandez à la personne qui gère votre site d’installer cette version à la main. WordPress rappelle d’ailleurs que seule sa dernière version est pleinement maintenue. Les risques d’une ancienne version et la façon de préparer le passage à la 7.1 sont détaillés dans notre article sur WordPress 7.

Deux failles sans compte, dont une dans la mise à jour de WordPress

D’après l’analyse citée plus bas, deux failles seulement peuvent être exploitées par quelqu’un qui n’a aucun compte sur le site. La plus sérieuse se trouve dans le mécanisme de mise à jour de WordPress lui-même.

Pendant une mise à jour, WordPress décompresse la nouvelle version dans un dossier du site, wp-content/upgrade, que l’on peut atteindre depuis le web. Il y crée un sous-dossier pour chaque mise à jour. Avant la 7.1.4, le nom de ce sous-dossier pouvait être prévisible, et le fichier qui empêche d’afficher la liste des fichiers du dossier était effacé. Pendant quelques secondes, une copie complète de WordPress, avec son programme d’installation, pouvait donc se trouver à une adresse facile à trouver. Un attaquant qui l’atteignait à ce moment-là pouvait lancer cette installation avec une base de données à lui, puis faire exécuter son code sur le serveur.

L’attaquant devait viser votre site au moment précis où une mise à jour s’y déroulait. Un éditeur de sécurité spécialisé dans WordPress, qui a analysé chacun des correctifs, juge cette faille très difficile à exploiter en pratique, même si chaque mise à jour, automatique ou non, rouvrait ce créneau (son analyse, en anglais). Au 29 octobre, aucune attaque exploitant cette faille n’a été signalée publiquement. Depuis la 7.1.4, le sous-dossier reçoit un nom impossible à deviner et le fichier de protection reste en place.

La seconde faille sans compte permettait à n’importe quel visiteur de voir les modifications en attente dans l’outil Apparence, puis Personnaliser, avant leur publication. Elle ne concerne que les sites où de telles modifications attendent, et ne permet pas de modifier le site.

Les autres failles demandent un compte qui peut écrire sur le site

La plupart des autres failles sont à la portée de tout compte qui peut écrire un article : contributeur, auteur, éditeur, mais aussi certains rôles créés par des extensions, comme les formateurs d’une plateforme de cours (les rôles de WordPress, en anglais). Ce sont surtout des failles XSS : un contributeur malveillant, ou un pirate qui a volé son mot de passe, peut glisser dans un brouillon du code qui s’exécute dans le navigateur de la personne qui l’affiche. Si un administrateur ouvre ce brouillon pour le relire, ce code peut agir avec ses droits, par exemple créer un compte administrateur.

Si vous êtes seul à vous connecter à votre site, ou si les autres comptes sont des abonnés ou des clients d’une boutique, qui ne peuvent rien écrire, ces failles ne vous concernent guère. Elles comptent davantage si vous donnez des accès à d’autres : rédacteurs invités, bénévoles d’une association, stagiaires, ancien prestataire dont le compte n’a jamais été supprimé.

Le cas le plus exposé est un site qui accepte les inscriptions et donne le rôle Contributeur à chaque nouveau compte. N’importe qui peut alors s’inscrire et tenter ces attaques. Vérifiez-le dans Réglages, puis Général, à la ligne « Rôle par défaut de tout nouveau compte ».

La mise à jour corrige ces failles. Profitez-en pour faire le tri parmi les comptes de votre site (menu Comptes, puis Tous les comptes) : le haut de la liste donne le nombre de comptes par rôle. Un compte qui peut écrire et dont personne ne se sert plus est une porte d’entrée inutile. Notre article pour sécuriser WordPress explique comment supprimer ces comptes sans perdre leurs contenus et comment fermer les inscriptions. Un administrateur que personne ne connaît est, lui, un signe de piratage, parmi ceux que décrit notre article pour savoir si votre site est piraté.

La septième version de sécurité depuis juillet

La 7.1.4 arrive trois semaines après la 7.1.3, qui corrigeait 7 failles d’après la même analyse. C’est la septième version de sécurité de WordPress depuis juillet, selon le décompte de The Repository (en anglais). Sur un site dont les mises à jour automatiques sont coupées et que personne ne surveille, chacune laisse des failles publiques ouvertes jusqu’à ce que quelqu’un y pense. Et même un site qui se met à jour seul doit être vérifié après chaque mise à jour : une version de sécurité peut, rarement, casser une page sans que personne ne le remarque.

Questions fréquentes

Mon site est encore en 7.1.3 : risque-t-il d’être piraté ?

Le risque immédiat est faible si personne d’autre que vous ne peut écrire sur le site, car la seule faille grave accessible sans compte ne peut servir que pendant les quelques secondes d’une mise à jour. Faites quand même la mise à jour aujourd’hui : ces failles sont maintenant publiques, et chacun peut lire leurs correctifs dans le code de WordPress.

Une extension de sécurité me protège-t-elle en attendant ?

Pas contre la faille de la mise à jour. La copie décompressée de WordPress démarre avec ses propres fichiers, sans les extensions de votre site : la plupart des extensions de sécurité ne la voient donc pas. Une règle posée sur le serveur, qui interdit l’accès au dossier wp-content/upgrade depuis le web, peut la bloquer. Votre hébergeur ou la personne qui gère votre site peut la poser. La mise à jour reste la vraie solution.

La 7.1.4 peut-elle casser mon site ?

C’est rare, mais pas impossible. Après la mise à jour, ouvrez votre page d’accueil, vos formulaires et, si vous vendez en ligne, votre panier. Si une sauvegarde a été faite juste avant, elle permet de revenir en arrière en cas de problème. WordPress n’en fait pas lui-même avant ses mises à jour automatiques.

Quand sort la prochaine version majeure de WordPress ?

La version 7.2 est prévue le 8 décembre 2026 (annonce de la 7.1.4, en anglais). Notre article sur WordPress 7 explique comment choisir entre une installation automatique et votre accord préalable.