# 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.

- Source canonique : [https://allaux.fr/securite/wordpress-s-est-mis-a-jour-tout-seul](https://allaux.fr/securite/wordpress-s-est-mis-a-jour-tout-seul)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Vérifiez d’abord le numéro de version affiché en bas à droite du tableau de bord, ou dans Tableau de bord puis Mises à jour. Si le site affiche « Briefly unavailable for scheduled maintenance », un fichier .maintenance est resté à la racine : supprimez-le par FTP et le site revient. Un écran blanc apparu le même jour vient presque toujours d’une extension ou d’un thème incompatible, à désactiver un par un.

## 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.

## terminal — à la racine du site

```
wp core version
wp core check-update
```

## Le site est resté sur une version ancienne

1. **Vérifier que les mises à jour automatiques n’ont pas été coupées** — La constante AUTOMATIC_UPDATER_DISABLED dans wp-config.php, ou WP_AUTO_UPDATE_CORE 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.
2. **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.
3. **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.
4. **Débloquer un site resté en maintenance** — Un fichier .maintenance 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.
5. **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.
6. **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.

## La mise à jour ferme la porte, elle ne nettoie pas ce qui est entré avant

> Passer en version corrigée empêche une nouvelle exploitation. Cela n’efface ni un fichier déposé, ni un compte administrateur créé, ni une tâche planifiée ajoutée pendant que la porte était ouverte. Et il faut être honnête sur l’état des connaissances : au 20 juillet 2026, aucune attribution publique n’avait été faite et aucun indicateur de compromission spécifique n’avait été publié. Il n’existe donc pas de nom de fichier ni de compte précis à chercher qui trancherait la question. La vérification repose sur les méthodes générales : comptes administrateurs inconnus, fichiers créés ou modifiés à partir du 17 juillet 2026, tâches planifiées inhabituelles, journaux d’accès du serveur sur cette période. Mesure provisoire citée par Tenable pour les installations qui ne peuvent pas être mises à jour tout de suite : bloquer /wp-json/batch/v1 au niveau du pare-feu applicatif et surveiller les tentatives visant ce point d’accès.

## Pour aller plus loin

- **Mise à jour d’urgence de sécurité** — Comment appliquer une mise à jour imposée sans casser une boutique en production. ([/wordpress-woocommerce/mise-a-jour/urgence-securite](/wordpress-woocommerce/mise-a-jour/urgence-securite))
- **Restaurer après une mise à jour ratée** — Si la mise à jour forcée a cassé une extension ou le thème. ([/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee))
- **Vérifier si mon site est compromis** — La méthode à appliquer quand aucun indicateur précis n’a été publié. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Que faire dans les deux heures** — L’ordre des opérations si vous trouvez autre chose qu’une simple mise à jour. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))

## FAQ

### J’ai reçu l’e-mail « Your site has been updated », dois-je m’inquiéter ?

L’e-mail lui-même est une bonne nouvelle : il signifie que la mise à jour est passée. Ce qu’il faut vérifier, c’est que le site fonctionne toujours normalement, et qu’il n’a pas été touché pendant la fenêtre d’exposition, entre la divulgation du 17 juillet 2026 et l’installation du correctif.

### Puis-je annuler cette mise à jour ou revenir à la version précédente ?

Techniquement oui, et je le déconseille formellement. Revenir en arrière remet le site sur une version vulnérable à une exécution de code à distance sans authentification, pour laquelle des codes de démonstration publics circulent. Si une extension est cassée, c’est l’extension qu’il faut corriger.

### Mon site est en 6.8.x, je suis moins concerné ?

Moins, pas indemne. L’enchaînement des deux failles menant à l’exécution de code concerne les installations 6.9.x et 7.0.x, mais CVE-2026-60137 est présente depuis la 6.8 et les versions 6.8.0 à 6.8.5 sont listées comme vulnérables. La version corrigée de cette branche est la 6.8.6.

### Comment savoir si j’ai été touché avant la mise à jour ?

En cherchant ce qui a changé sur le site à partir du 17 juillet 2026 : nouveaux comptes administrateurs, fichiers créés ou modifiés, tâches planifiées ajoutées, journaux d’accès inhabituels. Au 20 juillet 2026, aucun indicateur de compromission spécifique n’avait été publié, donc il n’y a pas de raccourci.

### Un pare-feu applicatif suffit-il en attendant ?

C’est une mesure provisoire, pas une solution. Tenable cite le blocage de /wp-json/batch/v1 et la surveillance des tentatives visant ce point d’accès pour les installations qui ne peuvent pas être mises à jour immédiatement. Cela fait gagner des heures, pas des semaines.