Nom du plugin	Thème WordPress Miller
Type de vulnérabilité	Inclusion de fichiers locaux
Numéro CVE	CVE-2026-28053
Urgence	Haut
Date de publication du CVE	2026-03-01
URL source	CVE-2026-28053

Urgent : Inclusion de fichiers locaux (LFI) dans le thème WordPress Miller (≤ 1.3.3) — Ce que les propriétaires de sites doivent faire maintenant

Résumé: Une vulnérabilité critique d'inclusion de fichiers locaux (LFI) (CVE-2026-28053) a été divulguée pour les versions du thème WordPress Miller jusqu'à et y compris 1.3.3. Le problème permet aux attaquants non authentifiés d'inclure des fichiers locaux d'un site vulnérable et de rendre leur contenu, ce qui peut entraîner une exposition des identifiants, un compromis complet de la base de données ou une exécution de code à distance selon l'environnement. Score de base CVSS 3.1 : 8.1 (Élevé). Si vous utilisez le thème Miller (ou gérez des sites qui le font), considérez cela comme une priorité immédiate.

Cet avis est rédigé du point de vue des spécialistes de la sécurité WordPress chez WP-Firewall. Ci-dessous, j'expliquerai ce qu'est cette vulnérabilité, pourquoi elle est dangereuse, comment elle peut être détectée et atténuée, et les étapes pratiques que vous devez prendre dès maintenant pour protéger vos sites. Ceci est écrit dans un langage technique simple afin que vous puissiez agir rapidement — pas de jargon marketing, juste des conseils concrets.

---

Table des matières

• Qu'est-ce que l'inclusion de fichiers locaux (LFI) ?
• Ce que nous savons sur CVE-2026-28053 dans le thème Miller
• Pourquoi cette vulnérabilité est-elle importante pour les sites WordPress
• Indicateurs de compromission (IoCs) à rechercher
• Étapes d'atténuation immédiates (rapides, sûres)
• Changements de durcissement et de configuration recommandés
• Détection et réponse à une compromission
• Exemples de règles WAF / serveur que vous pouvez déployer (modèles de blocage et suggestions)
• Comment WP-Firewall peut aider (plan gratuit et atténuation rapide)
• Recommandations à long terme et liste de contrôle post-incident
• Annexe : Commandes utiles, journaux d'exemple et liste de contrôle

---

Qu'est-ce que l'inclusion de fichiers locaux (LFI) ?

L'inclusion de fichiers locaux (LFI) est une classe de vulnérabilité où une application web inclut des fichiers du système de fichiers local du serveur en fonction d'une entrée contrôlée par l'utilisateur. Dans un scénario LFI typique, un attaquant manipule un paramètre dans une URL ou un formulaire afin que l'application lise et renvoie le contenu de fichiers tels que :

• wp-config.php (contient les identifiants de la base de données)
• .htaccess
• tout fichier PHP (exposant potentiellement le code source)
• fichiers système comme /etc/passwd

Bien que LFI en soi ne permette pas nécessairement l'exécution de code à distance (RCE), c'est souvent une étape intermédiaire. Par exemple, un attaquant peut :

• Lire wp-config.php => obtenir les identifiants de la base de données => pivoter vers la prise de contrôle de la base de données ou pivoter vers d'autres actions.
• Lire des fichiers journaux contenant du code PHP injecté ou télécharger des journaux pour atteindre RCE.
• Utilisez d'autres erreurs de configuration (comme des répertoires de téléchargement écriture) pour placer des fichiers malveillants et ensuite les inclure.

Les vulnérabilités LFI font partie des risques d“” injection » larges énumérés dans OWASP et, dans WordPress, mènent fréquemment à des compromissions complètes du site si elles ne sont pas atténuées rapidement.

---

Ce que nous savons sur CVE-2026-28053 (thème Miller ≤ 1.3.3)

• Type de vulnérabilité : Inclusion de fichiers locaux (LFI)
• Versions concernées : Versions du thème Miller ≤ 1.3.3
• CVE : CVE-2026-28053
• Authentification : Aucun requis (non authentifié)
• Score de base CVSS : 8.1 (Élevé)
• Classification OWASP : Injection (A3)
• Signalé : par un chercheur en sécurité (les détails de la divulgation publique varient)
• Patch officiel : Au moment de la rédaction, il n'y a pas de correctif officiel du thème disponible de la part de l'auteur du thème (confirmez avec la page du fournisseur de thème pour les mises à jour). Jusqu'à ce qu'un correctif officiel soit publié, les sites restent à risque et doivent s'appuyer sur des atténuations.

La vulnérabilité est exploitable à distance en fournissant des requêtes conçues qui manipulent un chemin d'inclusion de fichier utilisé par le thème. Comme elle est non authentifiée et affecte le code du thème (qui s'exécute dans l'espace de requête public), la surface d'exploitation est large. Un attaquant peut tenter d'inclure directement des fichiers locaux sur le serveur web et d'afficher leur contenu ou d'abuser autrement de l'appel d'inclusion.

---

Pourquoi cela est dangereux pour les propriétaires de sites WordPress

Il y a trois principales conséquences de LFI dans un thème WordPress :

1. Exposition des identifiants — wp-config.php contient souvent des identifiants de base de données en texte clair, des sels et des clés secrètes. La divulgation de ceux-ci peut permettre un accès complet à la base de données et une prise de contrôle administrative.
2. Exécution de code à distance ou contrôle du site — combiner LFI avec des répertoires écriture, ou empoisonner des journaux qui sont ensuite inclus, peut mener à RCE. RCE permet à un attaquant d'installer des portes dérobées, de défigurer le site ou d'héberger des logiciels malveillants.
3. Escalade de privilèges et pivotement — avec des identifiants de base de données ou une exécution de shell, les attaquants peuvent créer des utilisateurs administrateurs, exfiltrer des données utilisateur, utiliser l'hébergement du site pour attaquer d'autres réseaux, ou monétiser l'accès.

Parce que Miller est un thème qui peut être présent et actif sur de nombreux sites, et que la vulnérabilité ne nécessite pas de connexion, c'est une cible attrayante. Des scanners automatisés et du code d'exploitation de commodité devraient apparaître rapidement. La réponse recommandée est une atténuation immédiate.

---

Indicateurs de compromission (ce qu'il faut rechercher en ce moment)

Analysez les journaux et les systèmes de fichiers à la recherche de signes qu'un attaquant a tenté ou réussi :

• Journaux d'accès HTTP avec des requêtes contenant des séquences de traversée de répertoire (../ ou ..\\) ou des tentatives d'accès aux fichiers du thème avec des paramètres comme ?file=, ?template=, ?inc=, etc.
• Requêtes GET suspectes faisant référence à /wp-content/themes/miller/ ou similaires avec un parcours encodé : %2e%2e%2f ou 2e2e2f.
• Requêtes contenant des chaînes comme /etc/passwd, wp-config.php, ou php://filter/ dans les arguments.
• Création ou modification de fichiers inattendus dans wp-content/uploads, wp-content/themes, ou d'autres répertoires accessibles en écriture.
• Nouveaux utilisateurs administrateurs créés à des moments inhabituels.
• Connexions sortantes inattendues depuis le serveur ou des tâches cron exécutant des scripts PHP inconnus.
• Alertes de votre scanner de sécurité pour des changements de fichiers, des horodatages modifiés, ou des sommes de contrôle changées dans les fichiers de thème.

Si vous voyez des journaux ou des artefacts de ce type, procédez à une réponse à l'incident (voir ci-dessous).

---

Étapes d'atténuation immédiates — que faire dans les 60 à 120 prochaines minutes

1. Si le site utilise le thème Miller (actif ou présent), désactivez-le immédiatement si possible
   • Passez temporairement à un thème par défaut connu et bon (Twenty Twenty-Three ou équivalent).
   • Si vous ne pouvez pas changer en toute sécurité sur un site à fort trafic de production, appliquez des atténuations basées sur WAF (voir les éléments suivants).
2. Bloquez les vecteurs d'exploitation au niveau web
   • Appliquez des règles WAF pour bloquer les requêtes contenant des séquences de parcours de fichiers et des tentatives d'inclusion de fichiers locaux.
   • Si vous avez un pare-feu d'application web au niveau de l'hôte ou un pare-feu basé sur un plugin, ajoutez des signatures d'atténuation qui correspondent aux modèles LFI (voir les règles d'exemple dans cet article).
   • Refusez les requêtes vers des points de terminaison d'inclusion de thème spécifiques s'ils ne sont pas nécessaires publiquement.
3. Restreindre l'accès direct aux fichiers sensibles
   • Assurez-vous que wp-config.php n'est pas lisible publiquement et que les permissions de fichier sont restrictives (par exemple, 400/440 pour les fichiers qui n'ont pas besoin d'accès en écriture).
   • Ajoutez des règles .htaccess/nginx pour interdire l'accès direct à *.php dans les sous-dossiers de thème qui ne doivent pas être exécutés publiquement.
4. Renforcez les paramètres PHP
   • Assurez-vous que allow_url_include est désactivé (il devrait être désactivé par défaut).
   • Mettez en œuvre des restrictions open_basedir pour limiter l'accès aux fichiers PHP aux répertoires désignés.
   • Désactivez les fonctions dangereuses (si possible) : exec, shell_exec, system, passthru, proc_open, popen.
5. Rotation des identifiants
   • Si vos journaux indiquent une lecture réussie de wp-config.php ou d'autres fichiers sensibles, faites immédiatement tourner les identifiants de base de données et les clés API stockées dans des fichiers.
   • Réinitialisez les sels de WordPress et les mots de passe des utilisateurs — forcez une réinitialisation de mot de passe pour tous les administrateurs.
6. Isolez l'hôte affecté si un compromis est confirmé.
   • Mettez temporairement le site hors ligne ou restreignez-le par IP jusqu'à ce qu'un état propre soit restauré.
7. Déployez un patch virtuel temporaire.
   • Si vous exécutez un WAF ou pouvez déployer des règles au niveau du reverse-proxy/équilibreur de charge, ajoutez une règle pour bloquer les demandes tentant une inclusion de fichier local (exemples ci-dessous).
   • Le patching virtuel réduit le risque immédiat en attendant un patch officiel du fournisseur.

---

Changements de durcissement et de configuration recommandés (à long terme).

• Gardez les thèmes, les plugins et le cœur de WordPress à jour. Mais rappelez-vous : les mises à jour peuvent parfois être retardées et ne sont pas toujours immédiatement disponibles ; le patching virtuel basé sur un WAF est une solution temporaire utile.
• Supprimez les thèmes et plugins inutilisés. Même le code de thème inactif peut parfois être découvert et abusé.
• Limitez les permissions de fichier :
  • Répertoires : 755 (ou 750 si approprié)
  • Fichiers : 644 pour la plupart des fichiers ; 440 ou 400 pour wp-config.php si l'utilisateur du serveur le permet.
• Utilisez open_basedir pour restreindre PHP uniquement aux répertoires nécessaires.
• Mettez en œuvre une surveillance de l'intégrité des fichiers : surveillez les sommes de contrôle des fichiers de thème/plugin et alertez sur tout changement.
• Désactiver l'exécution PHP dans les répertoires de téléchargements :

  # Empêcher l'exécution PHP dans les téléchargements
  

  location ~* ^/wp-content/uploads/.*\.(php|phtml|php3)$ {
  

• Assurez-vous que votre environnement d'hébergement utilise le principe du moindre privilège pour l'utilisateur de la base de données — le compte DB ne doit avoir que les privilèges nécessaires (par exemple, éviter les privilèges GRANT).
• Maintenez des sauvegardes sécurisées avec versioning, stockées hors serveur. En cas de compromission, vous devez être en mesure de restaurer à un instantané connu comme propre.

---

Détection des tentatives d'exploitation — requêtes et vérifications pratiques

1. Recherchez des motifs dans les journaux HTTP :

   grep -i -E "(\.\./|\\|\\\|php://filter|wp-config.php|/etc/passwd)" /var/log/apache2/access.log

2. Vérifiez les journaux d'erreurs pour des erreurs ou des avertissements de fichiers inclus :

   grep -i "échec de l'ouverture du flux" /var/log/apache2/error.log

3. Recherchez des fichiers qui ont été modifiés récemment dans les répertoires de plugins/thèmes :

   find /var/www/html/wp-content -type f -mtime -7

4. Recherchez la création d'utilisateurs administrateurs suspects dans la base de données :

   Interrogez la table wp_users pour des comptes avec des dates de création inattendues.

5. Comparez les sommes de contrôle actuelles des fichiers de thème avec des copies connues comme bonnes. Si vous n'avez pas de référence, téléchargez une nouvelle copie du thème et comparez.

Si vous trouvez des preuves de téléchargements malveillants ou de portes dérobées, ne vous contentez pas de supprimer des fichiers et de supposer que tout va bien — effectuez une réponse complète à l'incident (voir la section suivante).

---

Procédure de réponse à l'incident (si vous soupçonnez une compromission)

1. Contenir
   • Bloquez toutes les attaques au niveau du pare-feu/WAF.
   • Mettez le site en mode maintenance ou restreignez par IP pendant l'enquête.
2. Préserver les preuves
   • Faites une copie judiciaire des journaux et du système de fichiers avant d'apporter des modifications destructrices.
   • Prenez un instantané du serveur lorsque cela est possible.
3. Éradiquer
   • Supprimez les portes dérobées et les fichiers malveillants.
   • Réinstaller le cœur de WordPress, le thème et les plugins à partir de sources fiables.
   • Remplacer les identifiants compromis (DB, admin WP, FTP, SSH).
   • Faire tourner toutes les clés API trouvées dans les fichiers de configuration.
4. Restaurer et valider
   • Restaurer à partir d'une sauvegarde connue comme propre.
   • Valider l'intégrité des fichiers et scanner à la recherche de logiciels malveillants.
   • S'assurer que tous les correctifs et mesures de durcissement sont appliqués.
5. Communiquer
   • Informer les parties prenantes, les clients ou les utilisateurs comme l'exige la politique ou la loi, en particulier si des données personnelles ont pu être exposées.
6. Analyse post-incident
   • Documenter la cause profonde (par exemple, exploitation d'un thème vulnérable inclus).
   • Examiner les processus de surveillance et de correction pour éviter la récurrence.

Si vous n'êtes pas à l'aise de le faire vous-même, engagez un professionnel de la sécurité expérimenté dans la gestion des incidents WordPress.

---

Exemples de règles WAF / serveur pour bloquer les tentatives LFI courantes.

Voici des modèles que vous pouvez utiliser dans un pare-feu d'application Web (WAF), ou comme règles de serveur pour Apache mod_security ou Nginx. Ceux-ci ne sont pas exhaustifs ; ajustez-les à votre environnement pour éviter les faux positifs. Si vous exécutez de nombreux itinéraires personnalisés, testez d'abord en mode non-bloquant/enregistrement.

Principe directeur important : ne comptez pas uniquement sur le blocage de chaînes — combinez WAF avec le moindre privilège, le durcissement de la configuration et la surveillance.

Modèles génériques pour détecter les tentatives de traversée et d'inclusion.

• Bloquer les requêtes contenant :
  • ../ ou ..\\ (non encodé ou encodé)
  • %2e%2e%2f ou 2e2e2f
  • php://filter
  • wp-config.php
  • /etc/passwd
  • entrée: file=, inclure=, inc=, modèle=, page=, chemin= lorsqu'elle est utilisée dans des contextes d'inclusion de thème.

Exemple de règle mod_security (conceptuel) :

SecRule REQUEST_URI|ARGS|ARGS_NAMES "@rx (\.\./|\\|\2e\2e|php://filter|wp-config\.php|/etc/passwd)" \"

Extrait de configuration Nginx exemple :

# bloquer les séquences de traversée suspectes

Règle ciblée : bloquer l'accès à des fichiers de thème spécifiques

Si vous identifiez un fichier de thème spécifique qui expose un paramètre d'inclusion (par exemple inc.php?file=), restreindre l'accès à ce point de terminaison :

• Refuser par défaut, autoriser par référent/IP, ou bloquer tout accès externe si ce n'est pas nécessaire.

Exemple Apache .htaccess :

<Files "inc.php">
  Require ip 192.0.2.0/24       # Only allow your IP range or internal systems
  Require all denied
</Files>

Utilisez ces protections côté serveur avec un WAF pour une meilleure couverture.

---

Exemples de modifications PHP sûres que les développeurs de thèmes devraient mettre en œuvre (niveau élevé)

Si vous êtes un développeur maintenant un thème ou le corrigeant, n'utilisez pas naïvement les entrées utilisateur dans les déclarations d'inclusion. Mettez en œuvre ce qui suit :

• Maintenez une liste blanche des cibles d'inclusion autorisées (mapper des clés comme en-tête1, pied de page2 vers des chemins de fichiers réels).
• Validez et normalisez les noms de fichiers — n'acceptez jamais ../.
• Évitez les inclusions dynamiques à partir des entrées utilisateur. Si vous devez, ne mappez que des jetons courts vers des chemins prédéfinis.
• Utilisez des fonctions PHP pour canoniser les chemins (realpath) et vérifier que le fichier se trouve dans le répertoire attendu.

Pseudo-code modèle sûr :

<?php

N'acceptez jamais un chemin de système de fichiers complet ni ne permettez des séquences de traversée de répertoires.

---

Comment prioriser l'atténuation sur l'ensemble de votre flotte de sites

1. Établissez un inventaire des sites et identifiez ceux qui utilisent le thème Miller (actif ou installé).
2. Priorisez les sites actifs faisant face au public ou ayant un fort trafic pour une action immédiate.
3. Appliquez des règles WAF à l'échelle du réseau pour bloquer les modèles d'exploitation connus pendant que vous corrigez ou supprimez le thème.
4. Pour les sites non critiques, envisagez de supprimer le thème ou de désactiver l'exécution PHP dans ses répertoires jusqu'à ce qu'il soit corrigé.
5. Après correction ou suppression, continuez à surveiller pendant au moins 30 jours pour détecter les activités post-exploitation retardées.

---

Comment WP-Firewall vous aide en ce moment

WP-Firewall se spécialise dans le patching virtuel rapide et la protection continue en temps réel pour les sites WordPress. Si vous gérez une flotte de sites ou une propriété importante, WP-Firewall fournit :

• Des règles WAF gérées qui peuvent être déployées immédiatement pour bloquer les modèles LFI et les signatures d'exploitation connues.
• Analyse de logiciels malveillants et surveillance de l'intégrité des fichiers pour détecter si un attaquant a déjà accédé à des fichiers sensibles.
• Atténuation des risques OWASP Top 10 dès la sortie de la boîte (y compris les tentatives d'injection et d'inclusion de fichiers).
• Un moyen simple de patcher virtuellement les thèmes vulnérables jusqu'à ce qu'une mise à jour officielle soit disponible de l'auteur du thème.

Protégez votre site maintenant — protection rapide et gratuite disponible

Nous recommandons à chaque propriétaire de site WordPress de s'inscrire au plan de base (gratuit) de WP-Firewall pour obtenir rapidement les protections essentielles : pare-feu géré, bande passante illimitée, WAF, analyse de logiciels malveillants et atténuation des risques OWASP Top 10. Ce niveau gratuit vous offre un blocage immédiat pour les modèles LFI et d'injection courants afin que vous puissiez réduire le risque pendant que vous effectuez une remédiation complète. Inscrivez-vous au plan gratuit ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si vous préférez plus d'automatisation : les plans Standard et Pro incluent la suppression automatique de logiciels malveillants, le blacklistage/whitelistage d'IP, le patching virtuel automatisé, des rapports de sécurité mensuels et des modules de sécurité dédiés qui simplifient considérablement la remédiation et la gestion continue.)

---

Améliorations de la posture de sécurité à long terme

Le LFI dans Miller est un rappel que la sécurité WordPress nécessite des couches :

• Gestion des correctifs : maintenez le cœur, les thèmes et les plugins à jour.
• Protection des applications : utilisez un WAF et renforcez PHP.
• Moindre privilège : limitez les permissions de la base de données et des fichiers.
• Surveillance + journalisation : surveillance de l'intégrité des fichiers, conservation des journaux et alertes.
• Sauvegardes + récupération : sauvegardes régulières versionnées hors site et récupération testée.
• Développement sécurisé : les développeurs de thèmes et de plugins doivent adopter les meilleures pratiques de codage sécurisé (listes blanches pour les inclusions, validation des entrées, encodage des sorties).

Tous ces niveaux ensemble réduisent considérablement le risque de compromission totale même lorsqu'une vulnérabilité est découverte.

---

Liste de contrôle pratique — Étape par étape pour les propriétaires de sites (copiez cette liste)

1. Identifier si le thème Miller est installé (actif ou inactif).
2. Si Miller est actif :
   • Passez à un thème sûr si possible OU
   • Déployez immédiatement des règles WAF pour bloquer les motifs LFI si vous ne pouvez pas changer.
3. Ajoutez des règles serveur pour bloquer la traversée de chemin et php:// les requêtes de style.
4. Définissez les permissions de fichiers : wp-config.php 400/440, fichiers 644, répertoires 755.
5. Désactivez l'exécution PHP dans les téléchargements et autres répertoires non codés.
6. Assurez-vous que allow_url_include = Off ; mettez en œuvre des restrictions open_basedir.
7. Scannez les fichiers pour détecter des changements et effectuez un scan approfondi de malware.
8. Vérifiez les journaux pour des tentatives LFI et une activité administrative suspecte.
9. Si une compromission est suspectée : préservez les journaux, mettez le site hors ligne, faites tourner les identifiants, restaurez à partir d'une sauvegarde propre et effectuez un examen post-incident.
10. Inscrivez-vous pour un WAF géré / un patch virtuel pour réduire le risque en attendant un patch officiel.

---

Annexe : Commandes utiles et recherches d'exemple

• Trouvez les fichiers récemment modifiés dans les thèmes :

  find /var/www/html/wp-content/themes/miller -type f -mtime -7 -ls

• Rechercher dans les journaux web des séquences de traversée :

  grep -iE "(\.\./|\\|php://filter|wp-config\.php|/etc/passwd)" /var/log/nginx/access.log

• Lister les utilisateurs WordPress ajoutés au cours des 7 derniers jours (MySQL) :

  SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE user_registered >= NOW() - INTERVAL 7 DAY;

• Vérifier la configuration PHP pour des paramètres dangereux :

  php -i | grep -E "allow_url_include|open_basedir|disable_functions"

---

Notes finales d'un expert en sécurité WP

Cette LFI dans le thème Miller est un exemple concret de la façon dont une seule inclusion vulnérable ou un modèle d'accès à un fichier dans le code du thème peut exposer l'ensemble du site. Les points clés à retenir :

• Traitez toute vulnérabilité d'inclusion de fichier non authentifiée comme une priorité élevée.
• Ne comptez pas uniquement sur “attendre un correctif”. Utilisez le patching virtuel (WAF) et les contrôles serveur pour réduire immédiatement la surface d'attaque.
• Faites tourner les identifiants et effectuez une enquête minutieuse si vous soupçonnez une exposition de wp-config.php ou d'autres secrets.
• Utilisez des défenses en couches : WAF, durcissement de l'hôte, codage sécurisé, surveillance et sauvegardes.

Si vous gérez plusieurs sites WordPress, une atténuation centralisée urgente (règles WAF sur l'ensemble de la flotte + un inventaire pour identifier les sites affectés) est le moyen le plus rapide de réduire le risque pendant que vous appliquez des correctifs ciblés.

Restez calme, agissez rapidement et utilisez la défense en profondeur. Si vous avez besoin d'aide pour mettre en œuvre les règles ou effectuer une enquête post-compromission, notre équipe de WP-Firewall peut vous aider avec une réponse sur mesure et une protection continue.