L’essentiel à retenir

Deux vulnérabilités ont été corrigées dans WordPress Core :

  • CVE-2026-60137, une injection SQL facilitée ;
  • CVE-2026-63030, une confusion de route dans l’API REST permettant un contournement de sécurité.

Sur WordPress 6.9 et versions ultérieures, leur exploitation combinée peut permettre une exécution de code arbitraire à distance sans authentification.

Les versions corrigées sont :

BrancheVersion corrigéeRemarque
WordPress 6.86.8.6concernée uniquement par la première vulnérabilité
WordPress 6.96.9.5concernée par les deux vulnérabilités
WordPress 7.07.0.2concernée par les deux vulnérabilités
WordPress 7.1 bêta7.1 beta2concernée par les deux vulnérabilités

Les versions antérieures à WordPress 6.8 ne sont pas affectées par ces deux vulnérabilités selon l’éditeur. Elles peuvent toutefois présenter d’autres failles et ne doivent pas être considérées comme sûres pour cette seule raison.

Pourquoi cette alerte est particulièrement importante

WordPress est utilisé par des millions de sites et fait régulièrement l’objet de scans automatisés.

Lorsqu’une preuve de concept devient publique, il devient beaucoup plus facile pour des attaquants opportunistes de :

  • rechercher les versions vulnérables ;
  • envoyer des requêtes automatisées ;
  • compromettre plusieurs sites en parallèle ;
  • déposer une porte dérobée ;
  • créer un compte administrateur ;
  • détourner le site pour du phishing, du spam ou de la distribution de logiciels malveillants.

Le risque ne dépend donc pas seulement de la notoriété de l’entreprise.

Un petit site vitrine peut être intéressant pour :

  • son domaine légitime ;
  • sa réputation auprès des moteurs de recherche ;
  • son hébergement ;
  • sa base de contacts ;
  • son formulaire ;
  • sa capacité à rediriger les visiteurs ;
  • sa relation de confiance avec des clients.

Comprendre les deux vulnérabilités

CVE-2026-60137 : injection SQL

Une injection SQL apparaît lorsque des données contrôlées par un utilisateur influencent incorrectement une requête envoyée à la base de données.

Selon le contexte, cela peut permettre :

  • de lire des informations ;
  • de contourner une logique applicative ;
  • de modifier certaines données ;
  • de préparer une attaque plus complexe.

WordPress indique que la branche 6.8 est uniquement concernée par cette première vulnérabilité.

CVE-2026-63030 : confusion de route dans l’API REST

La seconde vulnérabilité concerne une confusion autour des routes par lot de l’API REST.

Combinée à l’injection SQL dans WordPress 6.9 et versions ultérieures, elle peut permettre une exécution de code arbitraire à distance sans compte valide.

L’impact potentiel est donc très élevé : un attaquant peut tenter de prendre le contrôle du site et du compte système utilisé par PHP, dans les limites des droits accordés par l’hébergement.

Étape 1 : identifier la version de WordPress

Depuis l’administration

Connectez-vous au tableau de bord puis consultez :

Tableau de bord → Mises à jour

La version apparaît également dans plusieurs écrans d’administration.

Cette méthode n’est fiable que si l’administration elle-même n’a pas été modifiée par un attaquant.

Avec WP-CLI

Depuis la racine du site :

wp core version

Pour obtenir davantage d’informations :

wp core version --extra

En consultant le fichier de version

Le fichier suivant contient la version du cœur :

wp-includes/version.php

Vous pouvez effectuer une première lecture avec :

grep '\$wp_version' wp-includes/version.php

Étape 2 : confirmer la branche à installer

Ne passez pas automatiquement à une bêta ou à une branche différente.

Utilisez la version corrective de votre branche actuelle lorsque celle-ci est maintenue :

6.8.x → 6.8.6
6.9.x → 6.9.5
7.0.x → 7.0.2
7.1 beta1 → 7.1 beta2

Pour un site de production en WordPress 7.0, la cible normale est WordPress 7.0.2, pas la bêta 7.1.

WordPress.org a activé les mises à jour forcées en arrière-plan pour les versions concernées. Il reste nécessaire de vérifier que :

  • la tâche a réellement été exécutée ;
  • le système de fichiers est accessible en écriture ;
  • aucun blocage d’hébergement ne l’a empêchée ;
  • la version active correspond bien à la version corrigée.

Étape 3 : réaliser une sauvegarde avant intervention

La sauvegarde doit couvrir :

  • la base de données ;
  • le répertoire wp-content ;
  • les extensions indispensables ;
  • le thème et le thème enfant ;
  • les fichiers de configuration ;
  • les règles du serveur web ;
  • les tâches cron ou scripts externes ;
  • les certificats ou secrets nécessaires à la restauration.

Sauvegarder la base avec WP-CLI

mkdir -p "$HOME/sauvegarde-wordpress-2026-07-21"
wp db export \
  "$HOME/sauvegarde-wordpress-2026-07-21/base-wordpress.sql"

Sauvegarder les fichiers

Depuis le répertoire parent du site :

tar \
  --create \
  --gzip \
  --file "$HOME/sauvegarde-wordpress-2026-07-21/fichiers-wordpress.tar.gz" \
  NOM_DU_REPERTOIRE_WORDPRESS

Protéger la sauvegarde

Copiez ensuite cette sauvegarde vers un emplacement séparé :

  • stockage de sauvegarde ;
  • NAS protégé ;
  • stockage objet ;
  • coffre chiffré ;
  • poste d’administration sécurisé.

Étape 4 : créer une préproduction lorsque cela est possible

Pour un site critique ou fortement personnalisé, restaurez la sauvegarde dans un environnement isolé.

La préproduction doit utiliser :

  • un autre nom de domaine ou un fichier hosts local ;
  • une base distincte ;
  • des identifiants distincts ;
  • l’envoi d’e-mails désactivé ;
  • les paiements en mode test ;
  • les robots d’indexation bloqués ;
  • aucune connexion active avec les services de production lorsque cela n’est pas nécessaire.

Testez notamment :

  • la page d’accueil ;
  • les menus ;
  • les formulaires ;
  • l’espace client ;
  • la recherche ;
  • le panier et le paiement ;
  • les tâches planifiées ;
  • les appels API ;
  • le cache ;
  • les sauvegardes ;
  • les langues ;
  • l’administration.

Étape 5 : mettre WordPress à jour

Depuis le tableau de bord

Accédez à :

Tableau de bord → Mises à jour → Mettre à jour maintenant

Avec WP-CLI

Pour installer la dernière version corrective disponible de la branche proposée par WordPress :

wp core update

Pour cibler explicitement WordPress 7.0.2 :

wp core update --version=7.0.2

Pour WordPress 6.9.5 :

wp core update --version=6.9.5

Pour WordPress 6.8.6 :

wp core update --version=6.8.6

Mettez ensuite la base à niveau si WordPress le demande :

wp core update-db

Videz les caches :

wp cache flush

Selon l’infrastructure, videz également :

  • le cache d’extension ;
  • le cache Redis ou Memcached ;
  • le cache du reverse proxy ;
  • le cache CDN ;
  • le cache de l’hébergeur.

Étape 6 : vérifier que le cœur est intact

WP-CLI peut comparer les fichiers du cœur avec les sommes de contrôle officielles :

wp core verify-checksums

Un résultat correct confirme que les fichiers standards du cœur correspondent à la version officielle.

Cette commande ne vérifie pas :

  • les extensions ;
  • les thèmes ;
  • wp-content/uploads ;
  • wp-config.php ;
  • les fichiers ajoutés hors du cœur ;
  • la base de données.

Vérifier les extensions disponibles sur WordPress.org

wp plugin verify-checksums --all

Certaines extensions premium ou personnalisées ne possèdent pas de sommes de contrôle disponibles.

Vérifier les thèmes

wp theme list

Comparez les thèmes avec vos sources officielles et votre dépôt.

Étape 7 : mettre à jour les extensions et thèmes

Une vulnérabilité du cœur n’annule pas les vulnérabilités des composants tiers.

Listez les mises à jour :

wp plugin list --update=available
wp theme list --update=available

Après test en préproduction :

wp plugin update --all
wp theme update --all

N’utilisez pas --all sans test sur un site comportant :

  • une boutique ;
  • un constructeur de pages ;
  • une extension métier ;
  • un thème fortement personnalisé ;
  • une intégration de paiement ;
  • des extensions abandonnées.

Mesure temporaire si la mise à jour est impossible

Le CERT-FR relaie une mesure temporaire recommandée par les chercheurs : bloquer l’accès non authentifié à la route REST par lot concernée, notamment autour de :

/wp-json/batch/v1

et des requêtes utilisant :

rest_route=/batch/v1

Cette mesure peut être mise en œuvre dans un WAF ou un reverse proxy.

Elle doit être considérée comme :

  • temporaire ;
  • imparfaite ;
  • susceptible de casser une intégration légitime ;
  • inférieure à l’installation du correctif.

Étape 8 : rechercher une éventuelle compromission

La mise à jour empêche de nouvelles exploitations connues, mais ne supprime pas une porte dérobée déjà installée.

Examiner les comptes administrateurs

wp user list \
  --role=administrator \
  --fields=ID,user_login,user_email,user_registered

Recherchez :

  • compte inconnu ;
  • adresse e-mail modifiée ;
  • compte créé récemment ;
  • utilisateur ancien devenu administrateur ;
  • application password inattendu.

Examiner les extensions actives

wp plugin list \
  --fields=name,status,version,update

Recherchez :

  • extension inconnue ;
  • extension activée récemment ;
  • faux nom ressemblant à un composant connu ;
  • extension présente dans mu-plugins ;
  • fichier PHP isolé dans un répertoire inhabituel.

Examiner les thèmes

wp theme list \
  --fields=name,status,version,update

Un thème inactif peut tout de même contenir une porte dérobée accessible directement.

Rechercher les fichiers PHP dans les téléversements

Le répertoire uploads ne devrait généralement pas contenir de scripts PHP exécutables.

find wp-content/uploads \
  -type f \
  \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) \
  -print

Toute occurrence doit être analysée dans son contexte.

Rechercher les fichiers récemment modifiés

find . \
  -type f \
  -mtime -14 \
  -printf '%TY-%Tm-%Td %TH:%TM %p\n' \
  | sort

Adaptez la période à la date de publication de la vulnérabilité et à votre historique de déploiement.

Examiner les tâches cron WordPress

wp cron event list

Recherchez les hooks inconnus ou exécutés très fréquemment.

Examiner wp-config.php

Vérifiez :

  • inclusions inconnues ;
  • code avant <?php ou après la fin attendue ;
  • constantes ajoutées ;
  • redirections ;
  • appels réseau ;
  • secrets exposés ;
  • modifications de la base.

Examiner les journaux web

Recherchez autour de la période à risque :

  • requêtes vers l’API REST par lot ;
  • erreurs SQL inhabituelles ;
  • réponses 200 ou 500 répétées ;
  • création de fichiers ;
  • appels vers des scripts inconnus ;
  • connexions depuis des adresses inhabituelles ;
  • requêtes contenant des paramètres fortement encodés.

L’absence d’un motif évident ne prouve pas l’absence d’exploitation.

Vérifier l’intégrité de la base de données

Contrôlez notamment :

  • utilisateurs ;
  • options ;
  • tâches cron ;
  • contenus contenant du JavaScript injecté ;
  • URL du site ;
  • extensions actives ;
  • comptes applicatifs ;
  • redirections.

Vous pouvez consulter les options sensibles avec WP-CLI :

wp option get siteurl
wp option get home
wp option get active_plugins --format=json

N’exécutez pas de recherche-remplacement globale sans sauvegarde.

Que faire si le site semble compromis ?

Isoler sans détruire les preuves

Selon l’impact :

  • activez une page de maintenance statique ;
  • limitez l’administration à une adresse de confiance ;
  • conservez une copie des journaux ;
  • réalisez une image ou une archive forensique lorsque cela est nécessaire ;
  • notez l’heure de chaque action.

Révoquer les accès

Depuis un poste sain :

  • changez les mots de passe WordPress ;
  • changez les mots de passe de l’hébergement ;
  • changez le mot de passe de la base ;
  • révoquez les clés SSH et SFTP inconnues ;
  • révoquez les application passwords ;
  • changez les secrets API exposés ;
  • renouvelez les clés et sels WordPress.

Restaurer depuis une source saine

La méthode la plus fiable consiste souvent à :

  1. recréer un environnement propre ;
  2. installer une version corrigée de WordPress ;
  3. réinstaller les extensions depuis les sources officielles ;
  4. réinstaller le thème depuis une source connue ;
  5. restaurer uniquement les données vérifiées ;
  6. changer tous les secrets ;
  7. tester avant remise en ligne.

Durcir WordPress après la mise à jour

Activer les mises à jour automatiques adaptées

Conservez au minimum les mises à jour de sécurité du cœur.

Pour les extensions, choisissez une stratégie tenant compte :

  • de la criticité ;
  • de la compatibilité ;
  • de la préproduction ;
  • du niveau de maintenance disponible.

Protéger les comptes

  • MFA pour les administrateurs ;
  • comptes nominatifs ;
  • suppression des comptes obsolètes ;
  • mots de passe uniques ;
  • limitation des tentatives ;
  • revue des application passwords.

Réduire les droits du système de fichiers

Le serveur web ne doit pas pouvoir modifier plus de fichiers que nécessaire.

Évitez les permissions trop ouvertes comme :

777

Désactiver l’éditeur de fichiers

Dans wp-config.php :

define('DISALLOW_FILE_EDIT', true);

Cette mesure empêche l’édition directe des fichiers depuis l’administration, mais n’arrête pas un attaquant disposant déjà d’une exécution de code.

Centraliser les journaux et alertes

Surveillez :

  • modifications du cœur ;
  • création d’administrateurs ;
  • connexion inhabituelle ;
  • changement de thème ;
  • activation d’extension ;
  • échec de sauvegarde ;
  • modification DNS ;
  • expiration de certificat.

Checklist de remédiation

  • ☐ La version WordPress a été identifiée.
  • ☐ La branche corrigée a été confirmée.
  • ☐ La base de données a été sauvegardée.
  • ☐ Les fichiers ont été sauvegardés hors du serveur web.
  • ☐ Une préproduction a été utilisée lorsque nécessaire.
  • ☐ WordPress a été mis à jour vers 6.8.6, 6.9.5, 7.0.2 ou 7.1 beta2 selon la branche.
  • ☐ La version active a été revérifiée.
  • ☐ Les checksums du cœur ont été contrôlés.
  • ☐ Les extensions et thèmes ont été inventoriés.
  • ☐ Les comptes administrateurs ont été contrôlés.
  • ☐ Les fichiers PHP dans uploads ont été examinés.
  • ☐ Les fichiers récemment modifiés ont été revus.
  • ☐ Les journaux web ont été conservés et analysés.
  • ☐ Les secrets ont été renouvelés en cas de suspicion.
  • ☐ Une restauration propre a été envisagée si l’intégrité n’est pas démontrable.
  • ☐ Le MFA et la supervision ont été renforcés.

Conclusion

La mise à jour WordPress du 17 juillet 2026 corrige deux vulnérabilités importantes.

Sur WordPress 6.9 et versions ultérieures, leur exploitation combinée permet une exécution de code à distance sans authentification.

La présence d’une preuve de concept publique impose une réponse rapide :

  1. identifier la version ;
  2. sauvegarder ;
  3. mettre à jour ;
  4. vérifier l’intégrité ;
  5. rechercher une compromission ;
  6. renouveler les accès si nécessaire ;
  7. restaurer proprement lorsque l’intégrité ne peut plus être garantie.

Une mise à jour réussie est indispensable, mais elle ne constitue pas une preuve que le site n’a jamais été attaqué.

Besoin d’aide pour sécuriser un site WordPress ?

AGE-Info accompagne les professionnels dans la maintenance et la sécurisation de leurs sites web.

Nous pouvons notamment :

  • vérifier les versions ;
  • sauvegarder et tester la restauration ;
  • mettre à jour le cœur, les extensions et le thème ;
  • examiner les comptes et fichiers suspects ;
  • sécuriser les accès administrateurs ;
  • mettre en place une supervision ;
  • reconstruire un site compromis depuis une base saine.