Inclusion de Fichiers Locaux (LFI) dans le thème WordPress “Département de Police” (<= 2.17) — Ce que les Propriétaires de Sites Doivent Faire Maintenant

Auteur : Expert en sécurité de Hong Kong

Publié : 2026-03-01

TL;DR

Une vulnérabilité critique d'Inclusion de Fichiers Locaux (LFI) (CVE-2026-28049) affecte le thème WordPress “Département de Police” version 2.17 et antérieures. Des attaquants non authentifiés peuvent inclure et lire des fichiers locaux sur votre serveur web, exposant wp-config.php, des fichiers d'environnement, des sauvegardes, des journaux et d'autres données sensibles. Le problème est de haute gravité (CVSS 8.1). Si vous utilisez ce thème et n'avez pas mis à jour ou atténué, agissez immédiatement.

Ce post explique :

• Comment la vulnérabilité fonctionne à un niveau élevé
• Qui et quoi est en danger
• Comment détecter les tentatives d'exploitation
• Contention immédiate et atténuations manuelles
• Récupération et prévention à long terme

Qu'est-ce qu'une vulnérabilité d'inclusion de fichiers locaux (LFI) ?

L'Inclusion de Fichiers Locaux se produit lorsqu'une application utilise des entrées utilisateur non validées pour déterminer un chemin de système de fichiers à inclure ou à afficher. Dans les thèmes WordPress, cela signifie souvent que des paramètres acceptant des noms de fichiers ou des modèles sont utilisés sans une sanitation appropriée. Un LFI réussi permet à un attaquant de lire des fichiers arbitraires depuis le serveur, et dans certaines chaînes, cela peut conduire à une exécution de code à distance.

Faits clés pour cette vulnérabilité :

• Affecte les versions de thème ≤ 2.17
• Type : Inclusion de Fichiers Locaux (LFI)
• CVE : CVE-2026-28049
• CVSS : 8.1 (Élevé)
• Privilège requis : aucun (non authentifié)

Pourquoi ce LFI est particulièrement dangereux pour les sites WordPress

WordPress stocke des secrets critiques dans des fichiers. L'exemple canonique est wp-config.php, qui contient des identifiants de base de données et des clés d'authentification. Si un attaquant lit ce fichier, il peut :

• Accéder ou modifier la base de données (si l'accès à la base de données distante est autorisé)
• Créer des comptes administratifs
• Injecter du contenu ou des portes dérobées
• Exfiltrer des données utilisateur, des enregistrements de paiement ou des informations personnelles identifiables (PII)

Même sans exposition directe de wp-config.php, LFI peut révéler des journaux, des sauvegardes ou des fichiers temporaires contenant des secrets. Dans de nombreuses configurations d'hébergement, l'accès en lecture local est suffisant pour une escalade supplémentaire.

Comment les attaquants trouvent et exploitent cette vulnérabilité

Les attaquants et les scanners automatisés recherchent des paramètres qui semblent accepter des noms de fichiers, par exemple fichier=, modèle=, chemin=, page=, inclure=, tpl=. Ils essaient ensuite des charges utiles de traversée de répertoire telles que ../ ou des variantes encodées en URL comme %2e%2e/.

Flux d'exploitation typique :

1. Découvrez un paramètre qui accepte des noms de fichiers ou des modèles.
2. Envoyez des charges utiles comme ../../wp-config.php (encodées en URL si nécessaire).
3. Si la réponse contient des contenus de fichiers, l'exfiltration a réussi.

Étant donné que la vulnérabilité est non authentifiée, le scan de masse et l'exploitation rapide sont probables après la divulgation publique. Traitez l'exposition comme urgente.

Indicateurs de compromission (IoC) — quoi rechercher maintenant

• Requêtes avec %2e%2e ou ../ dans les paramètres de requête.
• Requêtes incluant des noms de fichiers tels que wp-config.php, .env, config.php, sauvegarde.zip, dump.sql.
• Réponses incluant soudainement du code source PHP brut, des identifiants ou de longs blobs base64.
• Nouveaux utilisateurs administrateurs inattendus, contenu modifié ou tâches planifiées suspectes.
• Pics dans les réponses 200 pour un point de terminaison spécifique ou requêtes POST répétées vers la même URL.
• Journaux d'erreurs du serveur web montrant des avertissements PHP concernant des inclusions de fichiers déclenchées par l'entrée utilisateur.
• Adresses IP externes demandant à plusieurs reprises les mêmes URL inhabituelles (comportement de scan).

Si vous trouvez des preuves de scan ou de lectures de fichiers, supposez que des données sensibles ont pu être exposées et suivez immédiatement les étapes de récupération.

Contention immédiate — actions à entreprendre dès maintenant (ordre de priorité)

Si vous utilisez le thème vulnérable (<= 2.17) sur un site de production, effectuez ces étapes maintenant :

1. Mettez le site en mode maintenance — empêche toute exploitation automatisée supplémentaire et vous donne le temps d'enquêter en toute sécurité.
2. Remplacez ou désactivez le thème vulnérable — passez à un thème par défaut de confiance (par exemple, un thème Twenty*) ou un autre thème sécurisé que vous contrôlez. Si vous ne pouvez pas changer immédiatement, supprimez ou renommez le répertoire du thème sur le serveur (par exemple, renommez /wp-content/themes/departement-de-police à /wp-content/themes/departement-de-police.disabled) pour empêcher le code vulnérable d'être servi.
3. Bloquez les points de terminaison vulnérables au niveau du serveur web ou de la couche CDN — créez des règles pour bloquer les demandes qui incluent des paramètres ou des motifs suspects comme ../ dans les chaînes de requête. Consultez la section “ Atténuations manuelles temporaires ” pour des exemples de règles.
4. Appliquez un patch virtuel via un WAF si disponible — un WAF peut bloquer les tentatives d'exploitation pendant que vous enquêtez et testez un patch officiel. Utilisez des règles qui bloquent la traversée de répertoires, les noms de fichiers sensibles et les charges utiles LFI connues.
5. Examinez les accès et faites tourner les identifiants si une exposition est suspectée — si les journaux montrent des tentatives de lecture wp-config.php ou d'autres secrets, changez immédiatement le mot de passe de la base de données et mettez à jour wp-config.php. Changez les sels d'authentification et toutes les clés API stockées sur le site.
6. Créer un instantané judiciaire — sauvegarder des copies des journaux du serveur web, des journaux d'accès, des journaux d'erreurs et un instantané du système de fichiers (si possible) pour une enquête ultérieure.
7. Scanner à la recherche de web shells et d'autres indicateurs — utiliser des scanners de logiciels malveillants et une inspection manuelle pour trouver des fichiers PHP inattendus dans les répertoires de téléchargements, de thèmes ou de plugins.

Ne pas supprimer les preuves avant que les enquêteurs puissent les examiner — copier d'abord les journaux et les fichiers.

Atténuations manuelles temporaires (exemples)

Tester toute règle en staging avant de déployer en production. Ce sont des atténuations brutales mais efficaces pour réduire le risque immédiat.

Apache (.htaccess) — refuser les demandes contenant des séquences de traversée de répertoire

# Block requests with directory traversal attempts in query string
RewriteEngine On
RewriteCond %{QUERY_STRING} (%2e%2e|%2f|%5c) [NC]
RewriteRule .* - [F,L]

Cela bloque les requêtes avec des motifs de traversée courants encodés dans l'URL. Cela peut affecter les demandes légitimes qui utilisent des caractères encodés.

Nginx — rejeter les demandes contenant ../ ou des équivalents encodés dans la requête

# Block basic directory traversal attempts
if ($request_uri ~* "(%2e%2e|%2f\.\.|../|%5c)") {
    return 444;
}

Remarque : retourner 444 ferme la connexion sans réponse et est efficace pour arrêter les scanners.

Restreindre l'accès direct aux fichiers de thème

Si vous préférez bloquer complètement le répertoire du thème jusqu'à ce que vous le mettiez à jour :

Apache :

<Directory "/var/www/html/wp-content/themes/police-department">
    Require all denied
</Directory>

Nginx :

location ~* /wp-content/themes/police-department/ {

Cela empêche le serveur web de servir des fichiers à l'intérieur du répertoire du thème et est sûr si un thème alternatif est actif.

Paramètres PHP (à l'échelle du serveur) pour réduire le risque

• Assurez-vous allow_url_include = Désactivé.
• Utilisez open_basedir pour restreindre l'accès aux fichiers PHP à la racine du site et aux répertoires nécessaires.
• Désactiver les fonctions dangereuses si elles ne sont pas nécessaires, par exemple exec, shell_exec, système, proc_open.

Cela ne corrige pas le bug du thème mais augmente le coût pour les attaquants.

Détection et réponse — étapes plus approfondies

1. Conservez les journaux et les preuves — copier les journaux d'accès, les journaux d'erreurs, les journaux PHP-FPM et les fichiers de configuration du serveur web avec les horodatages préservés.
2. Identifier la chronologie de l'attaque — rechercher dans les journaux ../, %2e%2e, wp-config.php, .env, et d'autres noms de fichiers sensibles. Noter les IP sources et les User-Agents.
3. Rechercher des web shells ou des fichiers nouvellement ajoutés — inspecter les fichiers PHP récemment modifiés dans :
   • wp-content/uploads/
   • wp-content/themes/
   • wp-content/plugins/

   Indicateurs communs : code obfusqué, longues chaînes base64, utilisation de eval(), preg_replace avec /e, ou charges utiles compressées décodées à l'exécution.

4. Vérifier les utilisateurs WordPress et l'authentification — auditer wp_users et wp_usermeta pour des comptes administrateurs inattendus ou des changements de privilèges.
5. Faire tourner les secrets si nécessaire — si wp-config.php une exposition est suspectée, changer les identifiants de la base de données, mettre à jour wp-config.php, et faire tourner les sels d'authentification et toutes les clés API stockées sur le serveur.
6. Réinstaller des copies propres — après confinement, remplacer le thème par une copie propre de la source officielle une fois qu'une version sûre est disponible.
7. Engager une analyse judiciaire pour les expositions sensibles — si des données clients ou des dossiers financiers ont été divulgués, impliquer une réponse à l'incident ou un spécialiste judiciaire.
8. Notifier le fournisseur d'hébergement ou les autorités si nécessaire — certains hébergeurs peuvent aider avec des indicateurs et des remédiations au niveau du réseau.

Pourquoi un WAF et une protection en couches sont importants pour LFI

Un pare-feu d'application Web (WAF) aide en bloquant les requêtes malveillantes avant que le code vulnérable ne soit atteint. Les protections efficaces pour LFI incluent :

• Bloquer les séquences de traversée de répertoires dans les chaînes de requête et les valeurs de paramètres
• Bloquer les tentatives d'accès à des noms de fichiers sensibles connus (par exemple, wp-config.php, .env)
• Inspecter les corps de requête pour des charges utiles suspectes
• Limiter le taux et vérifier la réputation IP pour ralentir le scan de masse
• Patching virtuel — règles temporaires pour prévenir l'exploitation jusqu'à ce qu'un correctif officiel soit déployé

Le patching virtuel est particulièrement précieux lorsqu'aucun correctif immédiat n'est disponible ou lorsque les mises à jour doivent être testées en staging avant le déploiement en production.

Si vous ne pouvez pas patcher immédiatement : actions prioritaires

1. Appliquer le patching virtuel WAF pour bloquer les charges utiles d'exploitation et les tentatives de scan.
2. Désactiver ou supprimer le thème vulnérable des sites de production.
3. Bloquer les chaînes de requête et les noms de fichiers suspects au niveau du CDN ou du serveur web.
4. Renforcer les paramètres PHP (open_basedir, autoriser_inclusion_url).
5. Auditer les journaux fréquemment jusqu'à ce qu'un correctif permanent soit en place.
6. Faites tourner tous les secrets soupçonnés d'être exposés.

Liste de contrôle de durcissement — prévention à long terme

• Gardez le cœur de WordPress, les thèmes et les plugins à jour ; utilisez un environnement de staging pour tester les mises à jour.
• Abonnez-vous aux flux de vulnérabilités et aux notifications de correctifs pour les thèmes/plugins que vous utilisez.
• Appliquez le principe du moindre privilège sur les permissions de fichiers ; évitez les fichiers PHP accessibles en écriture par tous.
• Utilisez open_basedir et gardez autoriser_inclusion_url désactivé.
• Effectuez régulièrement des analyses automatisées de logiciels malveillants et des vérifications d'intégrité des fichiers.
• Utilisez une gestion sécurisée des secrets ; évitez de stocker des identifiants dans des fichiers accessibles au public lorsque cela est possible.
• Restreignez les tableaux de bord administratifs par IP ou exigez une authentification à deux facteurs pour tous les comptes administratifs.
• Maintenez un plan de récupération après sinistre avec des sauvegardes hors site chiffrées.
• Mettez en œuvre des défenses en couches : contrôles réseau, WAF, durcissement au niveau de l'hôte et sécurité des applications.

Récupération : après confinement et nettoyage

Avant de rouvrir votre site au public, assurez-vous des éléments suivants :

1. Confirmez que le thème vulnérable est supprimé ou mis à jour vers une version sécurisée.
2. Restaurez à partir d'une sauvegarde connue comme bonne si une compromission persistante est détectée.
3. Changez les identifiants de base de données et les clés API s'ils ont pu être exposés.
4. Mettez à jour les sels de WordPress (AUTH_KEY, SECURE_AUTH_KEY, etc.) dans wp-config.php.
5. Réinstallez les plugins et thèmes à partir de sources fiables ; ne réintroduisez pas de fichiers modifiés.
6. Relancez les analyses de logiciels malveillants et vérifiez les sommes de contrôle des fichiers.
7. Surveillez les journaux pour une activité inhabituelle pendant au moins 30 jours après la remédiation.
8. Documentez les étapes de remédiation pour la conformité et les dossiers d'analyse.

Manuel de détection — requêtes et outils

Utilisez ces modèles de recherche sur les journaux et les dépôts pour détecter les tentatives :

• Recherchez dans les journaux d'accès \.\./, %2e%2e, ou %252e%252e (doublement encodé).
• Recherchez des requêtes contenant wp-config.php, .env, config.php, dump.sql, sauvegarde.
• Inspectez les journaux d'erreurs pour des messages faisant référence à include() ou échouant à ouvrir des flux.
• Utilisez des analyseurs de logiciels malveillants pour identifier de nouveaux fichiers PHP ou des chaînes suspectes (eval, base64_decode, etc.).
• Utilisez les différences de contrôle de version ou les horodatages de modification de fichiers pour trouver des changements récents.
• Si vous avez un SIEM ou une agrégation de journaux, créez des alertes pour ces modèles afin de détecter l'exploitation tôt.

Questions fréquemment posées (FAQ)

Q : La page du thème indique qu'aucun correctif n'est disponible — que dois-je faire ?

R : Supprimez ou désactivez immédiatement le thème vulnérable et appliquez un correctif virtuel WAF si possible. Remplacez le thème par une alternative sécurisée ou maintenez des protections en couches jusqu'à ce qu'un correctif du fournisseur soit publié et vérifié.

Q : Mon site est sur un hébergement géré — l'hébergeur va-t-il me protéger ?

R : Les protections d'hébergement varient. Ne supposez pas une protection totale — vérifiez avec votre hébergeur et appliquez des contrôles WAF supplémentaires et des mesures de durcissement si nécessaire.

Q : Puis-je simplement renommer le dossier du thème pour arrêter l'exploitation ?

R : Oui. Renommer le répertoire du thème est une mesure temporaire efficace car le code PHP sous ce dossier ne sera plus servi dans le même chemin prévisible. Assurez-vous que le thème actif de votre site est sûr avant de renommer pour éviter de casser le front-end.

Q : Dois-je restaurer à partir de sauvegardes ?

R : Si vous trouvez une compromission active (coquilles web, comptes administratifs inattendus), restaurer à partir d'une sauvegarde connue comme bonne et ensuite appliquer des correctifs et durcir est généralement plus sûr que la remédiation sur place.

Notes finales et résumé immédiat

Si votre site WordPress utilise le thème “ Police Department ” (<= 2.17), considérez cela comme urgent :

1. Supprimez ou désactivez immédiatement le thème vulnérable, ou appliquez des règles WAF bloquant les motifs LFI.
2. Vérifiez les journaux pour des indicateurs de scan ou de lecture de fichiers et conservez-les.
3. Faites tourner les identifiants et les clés si vous voyez des preuves de lectures de fichiers.
4. Effectuez un scan complet de malware et d'intégrité du site.
5. Surveillez de près pendant des semaines après la remédiation.

La rapidité et les contrôles en couches sont importants. Contenez rapidement pour réduire le risque de vol de données ou de prise de contrôle du site. Si vous traitez des données réglementées ou sensibles et soupçonnez un compromis, engagez une équipe professionnelle de réponse aux incidents ou d'analyse judiciaire.

Références et lectures complémentaires

• OWASP : Aperçu de l'inclusion de fichiers locaux (LFI)
• Avis et suivi de CVE-2026-28049 (voir l'enregistrement CVE lié ci-dessus)
• Guides de durcissement de WordPress et meilleures pratiques de configuration PHP/FPM

Remarque : Ce post fournit des conseils techniques. Pour des compromis actifs ou des expositions de données réglementées, engagez des spécialistes de la réponse aux incidents.