WordPress 7.1.4 : 22 failles de sécurité corrigées dont une exécution de code à distance, mettez à jour immédiatement

WordPress 7.1.4 : une release de sécurité majeure

Le 28 octobre 2026, l'équipe WordPress a publié la version 7.1.4, une mise à jour de sécurité corrigeant 22 vulnérabilités. WordPress est le CMS le plus utilisé au monde : chaque faille dans son coeur expose des millions de sites web. La release, signée Aaron Jorbin et Nik Tsekouras, corrige une exécution de code à distance (RCE) non authentifiée, sept XSS stockées dans l'Interactivity API, un déni de service stocké et une fuite d'information sur les changesets du Customizer (source : WordPress.org).

Si vous hébergez un ou plusieurs sites web WordPress sur un VPS Linux ou un serveur dédié, cette mise à jour vous concerne directement : la faille RCE ne nécessite aucune authentification. En tant qu'hébergeur, ElypseCloud recommande d'appliquer le correctif immédiatement sur toutes vos installations. Les hébergeurs proposant des installations WordPress gérées ont pour la plupart commencé le déploiement automatique. Si vous administrez votre propre serveur, la mise à jour reste de votre responsabilité. La prochaine version majeure, WordPress 7.2, est prévue pour le 8 décembre 2026.

La faille la plus grave : exécution de code à distance pendant la mise à jour

La vulnérabilité la plus critique concerne le processus de mise à jour du coeur WordPress. Lors d'une mise à jour, WordPress extrait les fichiers dans le répertoire wp-content/upgrade/. Avant le correctif, le nom du dossier temporaire était entièrement prévisible. Pendant la fenêtre de mise à jour (quelques secondes), un installateur WordPress complet, incluant les scripts d'installation et les fichiers de configuration, se retrouvait à une URL devinable et accessible depuis le web (source : Patchstack).

Un attaquant qui atteint cette URL au bon moment peut pointer l'installateur vers une base de données qu'il contrôle et exécuter du code arbitraire sur le serveur. Aucune authentification WordPress n'est requise. L'exploitation reste toutefois complexe : il faut accéder au répertoire pendant les quelques secondes où les fichiers sont exposés (complexité d'attaque haute, CVSS AC:H). Au moment de la publication, aucun identifiant CVE n'a été assigné à cette faille. Le bug existe dans le code WordPress depuis la version 2.8.

Le correctif apporte trois changements :

• Le nom du dossier temporaire reçoit 16 caractères aléatoires, rendant l'URL du répertoire imprévisible ;
• Le fichier index.php est recréé dans le répertoire au lieu d'être supprimé pendant l'extraction ;
• wp-config.php est ajouté à la liste des fichiers de configuration qui ne sont jamais copiés depuis le répertoire de travail.

Sept XSS stockées dans l'Interactivity API

L'Interactivity API, introduite dans les versions récentes de WordPress pour ajouter de l'interactivité côté client dans les blocs et les extensions, est à l'origine de sept vulnérabilités XSS stockées et d'un déni de service stocké. La cause racine est commune : le filtre KSES (le système de filtrage HTML de WordPress) autorise tout attribut data-* avec n'importe quelle valeur, et chaque directive de l'Interactivity API est justement un attribut data-*.

Les vecteurs d'attaque identifiés incluent :

• Des bindings injectant des URLs javascript: dans les attributs ;
• Des bindings sur des gestionnaires d'événements (on*) permettant l'exécution de scripts malveillants ;
• Une pollution de prototype via des clés réservées comme __proto__ ;
• Un contournement des vérifications KSES sur les éléments object ;
• Un parseur CSS relançant l'analyse à chaque itération, provoquant le gel de l'onglet du navigateur du visiteur (déni de service stocké, le serveur n'est pas affecté).

L'exploitation de ces failles requiert au minimum un compte contributeur WordPress. Un plugin ou thème acceptant du contenu utilisateur non filtré élargit la surface d'attaque. Les correctifs ajoutent un filtrage KSES sur les bindings dangereux, restreignent les bindings des éléments object côté PHP et refusent les cibles non sûres à l'exécution.

Les autres vulnérabilités corrigées

En complément de la faille RCE et des problèmes de l'Interactivity API, WordPress 7.1.4 corrige les vulnérabilités suivantes dans le coeur du CMS :

La plupart des XSS requièrent un compte contributeur ou auteur. Les comptes inutilisés sur vos installations WordPress sont un risque : un compte contributeur compromis, même sans accès admin, devient un vecteur pour injecter des scripts dans vos pages. Durcissez l'accès à votre VPS en complément des mises à jour applicatives.

Comment mettre à jour WordPress

Si les mises à jour automatiques en arrière-plan sont activées sur votre installation, la mise à jour a déjà pu s'appliquer. Vérifiez dans Tableau de bord > Mises à jour du panel d'administration WordPress.

Via le tableau de bord

Connectez-vous à l'interface d'administration (admin) de WordPress, allez dans Tableau de bord > Mises à jour, puis cliquez sur Mettre à jour maintenant. WordPress télécharge l'archive, extrait les fichiers dans les répertoires du CMS et applique le correctif.

Via WP-CLI en accès shell (SSH)

Si vous administrez vos sites web WordPress depuis un terminal SSH sur votre VPS Linux ou sous Debian, WP-CLI est la méthode la plus rapide pour mettre à jour manuellement. Depuis le répertoire racine de votre installation :

wp core update
wp core version

La deuxième commande doit afficher 7.1.4. Si vous gérez plusieurs sites WordPress sur le même serveur, répétez l'opération dans chaque répertoire. Vous pouvez automatiser avec un script shell :

for site in /var/www/*/; do
  if [ -f "$site/wp-config.php" ]; then
    echo "Mise à jour : $site"
    wp core update --path="$site"
  fi
done

Vérifier la version installée

wp core version
# Attendu : 7.1.4

Sauvegarder avant la mise à jour

Avant toute mise à jour, exportez votre base de données MySQL (via la ligne de commande mysqldump ou phpMyAdmin) et sauvegardez vos fichiers. Notre tutoriel rsync détaille comment créer un backup complet de votre VPS vers un serveur distant. En cas de problème après la mise à jour, vous pourrez restaurer vos fichiers de configuration, vos répertoires wp-content/ et votre base de données rapidement.

Contournement immédiat : bloquer l'accès à wp-content/upgrade/

Si vous ne pouvez pas mettre à jour immédiatement, bloquez l'accès HTTP au répertoire wp-content/upgrade/ dans les fichiers de configuration de votre serveur web. Ce répertoire n'a pas besoin d'être accessible depuis le navigateur.

Nginx (Ubuntu, Debian)

Ajoutez ce bloc dans le fichier de configuration du vhost Nginx, à l'intérieur du bloc server. Si vous utilisez Nginx comme reverse proxy, placez-le dans le vhost qui reçoit les requêtes :

location ~* ^/wp-content/upgrade/ {
    deny all;
    return 403;
}

Rechargez la configuration pour appliquer sans redémarrer le service :

sudo nginx -t && sudo systemctl reload nginx

Apache

Créez un fichier .htaccess dans le répertoire wp-content/upgrade/ de chaque installation WordPress :

# wp-content/upgrade/.htaccess
Require all denied

Ou ajoutez un bloc Directory dans votre fichier de configuration Apache :

<Directory /var/www/html/wp-content/upgrade>
    Require all denied
</Directory>

Redémarrez Apache pour appliquer :

sudo systemctl reload apache2

Ce contournement réduit la surface d'attaque de la faille RCE en empêchant tout accès web au répertoire temporaire de mise à jour. Il ne remplace pas la mise à jour vers 7.1.4.

Les backports : toutes les branches depuis 4.7 sont couvertes

L'équipe de sécurité WordPress a publié des backports pour toutes les branches encore supportées, de 4.7.39 jusqu'à 7.0.8. Si votre site tourne sur une version plus ancienne (6.5, 6.6, 6.7, etc.), la mise à jour de sécurité correspondante est disponible dans votre branche.

Les branches 4.6 et antérieures ne reçoivent plus de correctifs de sécurité. Si votre installation WordPress tourne sur une de ces versions, la migration vers une branche maintenue est indispensable.

WordPress 7.2 Beta 3 a également été publié avec tous les correctifs applicables inclus.

Checklist : sécuriser WordPress sur un VPS

Cette release est l'occasion de vérifier la configuration globale de votre installation WordPress. Voici les points essentiels pour les administrateurs qui gèrent le CMS sur un VPS ou un serveur dédié.

Extensions et plugins

• Désactivez et supprimez les extensions (plugins) que vous n'utilisez plus. Chaque plugin installé est un vecteur d'attaque potentiel, même désactivé. En octobre 2026, la compromission d'UpdraftPlus a exposé jusqu'à 400 000 sites via des backdoors.
• Configurez les mises à jour automatiques des extensions dans Extensions > Extensions installées pour les plugins critiques.

Comptes et mots de passe

• Supprimez les comptes contributeurs et auteurs inutilisés dans l'admin WordPress. La majorité des XSS corrigées dans 7.1.4 requièrent un compte avec le rôle contributeur au minimum.
• Imposez des mots de passe robustes à tous les comptes admin et éditeurs. Désactivez l'inscription ouverte si elle n'est pas nécessaire (Réglages > Général > Inscription).

Configuration serveur et réseau

• Certificat SSL/TLS : servez votre site en HTTPS. Installez un certificat SSL avec Let's Encrypt et Certbot si ce n'est pas encore fait. Vérifiez que le nom de domaine de votre site pointe vers la bonne adresse IP dans vos enregistrements DNS.
• Accès SSH : désactivez l'authentification par mot de passe et utilisez des clés SSH. N'utilisez jamais FTP en clair pour transférer des fichiers vers votre serveur : préférez SFTP ou SCP.
• Fichier wp-config.php : déplacez ce fichier de configuration un niveau au-dessus de la racine web si possible. Configurez les mises à jour automatiques de sécurité :

define('WP_AUTO_UPDATE_CORE', 'minor');

• Mises à jour système : sur Ubuntu ou Debian, configurez unattended-upgrades pour appliquer automatiquement les correctifs de sécurité du système d'exploitation.
• Backup régulier : planifiez une sauvegarde de vos fichiers et de votre base de données MySQL. rsync vers un serveur distant est la méthode la plus fiable pour un backup complet du VPS.
• Logs : consultez régulièrement les logs d'accès de votre serveur web pour détecter les tentatives d'exploitation. Recherchez les requêtes suspectes vers /wp-content/upgrade/ ou /wp-admin/setup-config.php.

Questions fréquentes