WordPress s’est mis à jour tout seul : que s’est-il passé
Une mise à jour de sécurité imposée à toutes les installations n’arrive pas tous les ans. Quand elle arrive, ce n’est pas une précaution : c’est que la faille corrigée pouvait être exploitée sans compte et sans mot de passe.
Ce qui a été corrigé le 17 juillet 2026
Si vous avez reçu un e-mail intitulé « Your site has been updated » sans avoir rien demandé, ce n’est pas un dysfonctionnement. Le 17 juillet 2026, WordPress a publié les versions 7.0.2, 6.9.5 et 6.8.6, et WordPress.org a activé les mises à jour automatiques forcées sur les versions concernées. La recommandation officielle tient en une phrase : mettre à jour immédiatement.
Deux failles sont corrigées. CVE-2026-60137 est une injection SQL facilitée par le paramètre author__not_in de WP_Query ; elle est présente depuis WordPress 6.8 et WordPress.org la classe critique. CVE-2026-63030 est une confusion de routes sur l’API REST par lots, introduite dans WordPress 6.9 ; WordPress.org la classe haute, et Tenable lui attribue un score CVSS de 9,8. Prises séparément, ce sont deux problèmes sérieux. Enchaînées, elles permettent une exécution de code à distance sans authentification sur les installations 6.9.x et 7.0.x — sans compte, sans mot de passe, sans qu’un administrateur ait à cliquer sur quoi que ce soit. Les versions vulnérables listées par Tenable sont 6.8.0 à 6.8.5, 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1.
Le rapport Patchstack sur l’état de la sécurité WordPress en 2026 donne un délai médian de cinq heures entre la divulgation publique d’une faille et son exploitation de masse, et estime qu’environ la moitié des vulnérabilités à fort impact sont exploitées dans les vingt-quatre heures. Des codes de démonstration publics sont apparus quelques heures après la divulgation du 17 juillet, et l’exploitation en conditions réelles a été confirmée par plusieurs équipes, dont Patchstack, dans les jours qui ont suivi. C’est tout le raisonnement derrière la mise à jour forcée : à cette échelle de temps, attendre que chaque site se mette à jour de lui-même n’était pas défendable.
Les signes d’une mise à jour imposée
- Un e-mail de WordPress intitulé « Your site has been updated » reçu autour du 17 juillet 2026, sans intervention de votre part.
- Un numéro de version qui a changé dans le tableau de bord alors que personne n’a cliqué sur le bouton de mise à jour.
- Un écran blanc, une erreur ou une mise en page cassée apparus le même jour, souvent liés à une extension ou un thème incompatible avec la nouvelle version.
- Un site bloqué sur le message « Briefly unavailable for scheduled maintenance », signe d’un fichier .maintenance resté en place.
- À l’inverse, et c’est le cas qui doit inquiéter : aucun e-mail, aucun changement de version, alors que le site tourne toujours sur une version antérieure.
Vérifier en trente secondes que vous êtes bien passé
Il n’y a qu’une question à se poser pour l’instant : quelle version tourne réellement sur le site. Depuis l’administration, la réponse est en bas à droite du tableau de bord, et dans Tableau de bord → Mises à jour. Vous devez lire 7.0.2, 6.9.5 ou 6.8.6, ou une version publiée plus tard. Si vous lisez 7.0.1, 6.9.4, 6.8.5 ou une version antérieure, la mise à jour n’a pas eu lieu et le site est resté sur une version vulnérable.
En ligne de commande, deux commandes suffisent, et elles ont l’avantage d’aller chercher la version dans les fichiers plutôt que dans une page d’administration qui peut être mise en cache. La seconde interroge en plus le serveur de mise à jour officiel et vous dit s’il reste quelque chose à installer.
wp core version
wp core check-updateLe site est resté sur une version ancienne
-
Vérifier que les mises à jour automatiques n’ont pas été coupées
La constante <code>AUTOMATIC_UPDATER_DISABLED</code> dans <code>wp-config.php</code>, ou <code>WP_AUTO_UPDATE_CORE</code> réglée sur false, suffit à empêcher toute mise à jour imposée. Certaines extensions de maintenance ou d’optimisation posent la même consigne sans le dire clairement.
-
Demander à l’hébergeur s’il pilote les mises à jour
Sur une offre gérée, c’est parfois l’hébergeur qui décide du moment de la mise à jour, après ses propres tests. Dans ce cas la question à lui poser n’est pas « pourquoi » mais « quand », et la réponse acceptable se compte en heures.
-
Vérifier que le cœur n’a pas été modifié à la main
Des fichiers du cœur retouchés font échouer la mise à jour, parfois en silence. Et le numéro de version affiché ne prouve rien si quelqu’un a édité le fichier qui le contient : dans le doute, je compare les fichiers du cœur à une archive officielle de la même version.
-
Débloquer un site resté en maintenance
Un fichier <code>.maintenance</code> laissé à la racine après une mise à jour interrompue bloque tout le site. Il se supprime, mais il faut ensuite vérifier que la mise à jour est réellement allée à son terme, et pas seulement que le site s’affiche à nouveau.
-
Recenser toutes les installations, pas seulement la principale
Un multisite, une préproduction, une ancienne installation dans un sous-dossier oubliée depuis deux ans : ce sont ces installations-là qui restent en version vulnérable, parce que personne ne reçoit leurs e-mails.
-
Sauvegarder, puis mettre à jour à la main
Sauvegarde complète des fichiers et de la base d’abord, mise à jour ensuite, depuis le tableau de bord ou en ligne de commande. Une extension incompatible se répare après coup ; une exécution de code à distance ouverte, non.
Pour aller plus loin
-
Mise à jour d’urgence de sécurité
Comment appliquer une mise à jour imposée sans casser une boutique en production.
-
Restaurer après une mise à jour ratée
Si la mise à jour forcée a cassé une extension ou le thème.
-
Vérifier si mon site est compromis
La méthode à appliquer quand aucun indicateur précis n’a été publié.
-
Que faire dans les deux heures
L’ordre des opérations si vous trouvez autre chose qu’une simple mise à jour.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.