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

L'inclusion de fichier local (LFI) est une classe de vulnérabilité des applications web où un attaquant peut amener un script côté serveur à inclure et évaluer des fichiers du système de fichiers local. Dans les applications PHP telles que les thèmes WordPress, cela provient généralement d'une utilisation non sécurisée de include(), require() ou de fonctions similaires où un paramètre contrôlable par l'utilisateur sélectionne un fichier. Une exploitation réussie peut révéler des fichiers sensibles (wp-config.php, .env, sauvegardes), divulguer des identifiants et, dans certaines configurations, conduire à l'exécution de code.

LFI diffère de l'inclusion de fichier à distance (RFI) — les PHP modernes désactivent souvent les inclusions distantes, donc LFI est un risque réel plus courant. Les fichiers locaux contiennent souvent des secrets et des configurations, rendant LFI très précieux pour les attaquants.

La vulnérabilité du thème Services AC : faits rapides

• Produit affecté : thème WordPress “Services AC | HVAC, climatisation et entreprise de chauffage” (famille de thèmes : Fenêtre / Services AC)
• Versions vulnérables : ≤ 1.2.5
• Type de vulnérabilité : Inclusion de Fichiers Locaux (LFI)
• CVE : CVE-2026-27326
• Rapporté par : chercheur indépendant (date de divulgation publique 2026-03-04)
• Privilège requis : Aucun — non authentifié
• Impact : Divulgation de fichiers locaux (y compris wp-config.php), fuite potentielle de crédentiels de base de données, possible prise de contrôle du site selon la configuration du serveur et les répertoires de téléchargement écrits
• État du correctif : Traitez les sites actifs comme étant à risque jusqu'à ce que le fournisseur publie un correctif confirmé et que vous l'appliquiez.

Pourquoi cette vulnérabilité est dangereuse pour les sites WordPress

Attributs clés qui rendent ce LFI sévère :

1. Exploitation non authentifiée — les attaquants peuvent sonder et exploiter sans compte.
2. Fichiers locaux sensibles — les installations WordPress contiennent couramment wp-config.php, des journaux, des sauvegardes et d'autres fichiers contenant des crédentiels et des secrets.
3. Analyse de masse automatisée — les attaquants déploient des bots pour découvrir et exploiter rapidement des thèmes vulnérables après divulgation.
4. Pivot vers un compromis total — les crédentiels de base de données exposés peuvent conduire à la manipulation de contenu, à la création d'administrateurs ou à des portes dérobées persistantes.
5. Risque de chaîne d'approvisionnement — les thèmes achetés déployés sur de nombreux sites clients peuvent entraîner une large exposition.

Étant donné ces facteurs, mettez en œuvre des atténuations en couches immédiatement : bloquez les tentatives d'exploitation, détectez les exploitations passées et corrigez la cause profonde.

Comment les attaquants peuvent (et le feront souvent) abuser d'un LFI

Les attaquants suivent couramment ce plan d'action :

1. Identification — identifiez les sites utilisant le thème et la version vulnérables.
2. Sondage — envoyer des requêtes élaborées à des points de terminaison vulnérables connus, souvent avec des séquences de traversée de répertoires (../ ou équivalents codés).
3. Extraction de données — récupérer wp-config.php et d'autres fichiers contenant des identifiants ou des sels.
4. Utilisation ou élévation des identifiants — utiliser des identifiants de base de données exposés pour modifier des données, créer des utilisateurs administrateurs ou obtenir un accès supplémentaire.
5. Persistance et nettoyage — installer des portes dérobées/webshells et supprimer des journaux pour cacher des traces.

Bloquer les tentatives LFI tôt est un moyen efficace de réduire le risque et d'arrêter de nombreuses attaques automatisées.

Indicateurs de compromission (IoCs) et conseils de détection

Recherchez ces signes dans les journaux et sur le système de fichiers — IoCs courants pour les tentatives d'exploitation LFI :

• HTTP requests to theme endpoints with query parameters containing traversal payloads (“../” or “..%2F”).
• Requêtes avec des paramètres tels que fichier=, page=, modèle=, inc=, inclure=, chemin=, vue=, etc., surtout s'ils correspondent au code du thème.
• Réponses 200 répétées pour des requêtes qui devraient renvoyer 404/403.
• Preuves d'accès web à wp-config.php, .env, ou fichiers de sauvegarde.
• Nouveaux fichiers PHP ou fichiers modifiés dans uploads, wp-content, ou répertoires de thème (possibles webshells).
• Changements inattendus dans la base de données (nouveaux utilisateurs administrateurs, publications modifiées avec des logiciels malveillants).
• Journaux d'erreurs élevés révélant le contenu des fichiers ou des traces de pile.
• Connexions sortantes inattendues depuis le serveur web.

Actions de détection que vous pouvez entreprendre maintenant :

• Examiner les journaux d'accès du serveur web pour des requêtes contenant ../ ou des tentatives de récupérer des noms de fichiers sensibles.
• Scanner le système de fichiers pour des fichiers récemment modifiés et des fichiers PHP inattendus dans uploads.
• Recherchez dans la base de données des utilisateurs inconnus et du contenu de publication suspect.
• Utilisez les journaux de votre serveur ou de votre fournisseur d'hébergement pour vérifier les demandes bloquées ou suspectes.

Atténuations immédiates que vous pouvez appliquer maintenant (aucune mise à jour de thème requise)

Si vous utilisez le thème affecté et ne pouvez pas le mettre à jour immédiatement, appliquez ces étapes pragmatiques :

1. Bloquez les motifs LFI à la périphérie (patching virtuel)
   Mettez en œuvre des règles de serveur ou de pare-feu qui bloquent la traversée de répertoires (../ et les formes encodées), les octets nuls et les schémas d'enveloppe (php://, données :, file:). Restreignez l'accès aux points de terminaison d'inclusion de thème aux origines de confiance lorsque cela est possible.
2. Restreindre l'accès direct aux fichiers sensibles
   Ajoutez des règles de serveur web pour refuser les demandes pour wp-config.php, .env, .git et d'autres noms sensibles connus.
3. Verrouillez les fichiers de thème
   Supprimez temporairement ou renommez les fichiers d'entrée suspects dans le thème qui appellent include() avec des entrées non fiables. Si un fichier vulnérable n'est pas nécessaire pour la fonctionnalité publique, déplacez-le hors de la racine web.
4. Renforcez les permissions de fichiers et l'exécution PHP
   Assurez-vous que les répertoires de téléchargements n'exécutent pas PHP. Appliquez des permissions de moindre privilège (fichiers 644, répertoires 755) et vérifiez que l'utilisateur du serveur web ne peut pas écrire dans les répertoires de thème ou de plugin principaux.
5. Faites tourner les clés et les identifiants si vous trouvez des preuves de divulgation
   Si wp-config.php ou d'autres secrets ont été accédés, faites tourner les identifiants de base de données et toutes les clés API exposées immédiatement, et mettez à jour la configuration en conséquence.
6. Surveillez et isolez les hôtes suspects
   Bloquez les IP des attaquants pendant que vous enquêtez. Si une porte dérobée ou un shell persistant existe, envisagez d'isoler l'hôte pour éviter d'autres dommages.
7. Sauvegardez avant la remédiation
   Créez des sauvegardes complètes du système de fichiers et de la base de données pour préserver les preuves et fournir des points de récupération.

Appliquez ces contrôles de toute urgence — ils réduisent le risque immédiat et fournissent du temps pour effectuer une remédiation complète.

Corrections de code sécurisées et conseils pour les développeurs

Si vous maintenez le thème ou travaillez avec un développeur, corrigez la cause profonde en éliminant l'utilisation d'entrées contrôlées par l'utilisateur non validées pour les opérations include/require. Le contrôle le plus fort est la liste blanche.

Modèles sûrs recommandés

1. Utilisez une liste blanche de modèles ou de fichiers autorisés. Mappez les noms logiques aux fichiers réels :

// Mapping des modèles autorisés

2. Ne jamais passer d'entrées brutes à include/require. La liste blanche est le contrôle le plus fort ; basename()/realpath() ne sont que des atténuations partielles.

3. Si la traduction de l'entrée en un chemin est inévitable, canonisez et assurez-vous que le fichier est à l'intérieur d'un répertoire de base sûr :

$base = realpath( get_template_directory() . '/templates' );

4. Évitez l'évaluation dynamique du code (eval(), create_function, etc.) et traitez le contenu des fichiers comme des données, pas comme du code exécutable.

5. Assurez-vous que le processus du serveur web a le minimum de privilèges pour les opérations sur les fichiers et ne peut pas modifier arbitrairement le code du thème.

Pour les mises à jour de thème, incluez des tests unitaires sécurisés et une révision de code axée sur l'utilisation de include(). L'analyse statique automatisée peut aider à détecter les appels risqués.

Liste de contrôle complète de remédiation (priorisée)

Suivez ces étapes par ordre d'urgence :

Immédiat (dans les heures)

• Appliquez des règles de bord/serveur pour bloquer les modèles LFI et les demandes ciblant des points de terminaison vulnérables connus.
• Refusez l'accès direct aux fichiers sensibles via des règles nginx/apache.
• Créez des sauvegardes complètes (système de fichiers + DB) avant les modifications.

Court terme (24–72 heures)

• Si un correctif de fournisseur est disponible, mettez à jour le thème sur tous les sites (testez d'abord sur la mise en scène).
• S'il n'existe pas de correctif, désactivez ou remplacez le thème vulnérable en production ; passez à un thème par défaut ou connu comme bon pendant que vous remédiez.
• Faites tourner les identifiants de base de données et d'API si une compromission est suspectée.

À moyen terme (1 à 2 semaines)

• Remplacez les fichiers modifiés ou malveillants par des copies propres provenant de sources vérifiées ou de sauvegardes.
• Auditer les utilisateurs malveillants, les tâches planifiées et les connexions sortantes inattendues.
• Effectuez des analyses complètes de logiciels malveillants et des vérifications d'intégrité des fichiers.

Long terme (en cours)

• Renforcez les permissions de fichiers et désactivez l'exécution PHP dans les téléchargements.
• Mettre en œuvre la journalisation et la surveillance des anomalies ; maintenir les systèmes à jour.
• Utiliser un environnement de staging pour les mises à jour et maintenir un plan de réponse aux incidents.

Recommandations de durcissement pour les hébergeurs WordPress et les propriétaires de sites.

• Maintenir et tester des sauvegardes complètes du site et des procédures de restauration.
• Appliquer le principe du moindre privilège aux comptes du système de fichiers et de la base de données.
• Imposer des secrets forts et les faire tourner périodiquement (mots de passe DB, sels, clés API).
• Désactiver l'édition de fichiers via l'interface d'administration : define('DISALLOW_FILE_EDIT', true);
• Effectuer des analyses de vulnérabilité périodiques et des vérifications de l'intégrité des fichiers.
• Configurer le serveur web pour refuser l'accès à .git, .env et aux fichiers de sauvegarde.
• Restreindre les connexions sortantes inutiles du serveur lorsque cela est possible.
• Activer l'authentification à deux facteurs pour les comptes administratifs et surveiller les tentatives de connexion.

Réponse aux incidents : que faire si vous soupçonnez que votre site a été compromis

1. Contenir
   Mettre le site en mode maintenance/hors ligne si possible. Bloquer les IP suspectes et isoler l'hôte s'il y a une exfiltration de données active ou un shell persistant.
2. Préservez les preuves
   Prendre des instantanés judiciaires du système de fichiers et de la base de données avant de modifier quoi que ce soit. Préserver les journaux du serveur (web, PHP, syslog).
3. Éradiquer
   Supprimer les fichiers malveillants ou restaurer à partir d'une sauvegarde propre vérifiée. Faire tourner les identifiants et invalider les sessions. Supprimer les utilisateurs administratifs suspects et les tâches planifiées.
4. Récupérer
   Restaurer les services à partir de sources propres, durcir le site et surveiller de près pour éviter toute récurrence.
5. Revoir et apprendre
   Effectuer une analyse des causes profondes et améliorer les défenses pour réduire le risque de récurrence.

Si la violation est complexe ou si vous manquez de capacités internes, faire appel à un spécialiste qualifié en réponse aux incidents expérimenté dans les enquêtes judiciaires WordPress.

Obtenir de l'aide et des services professionnels

Si vous avez besoin d'aide pour mettre en œuvre des mesures d'atténuation, effectuer une analyse judiciaire ou restaurer des sites pour plusieurs clients, recherchez un consultant en sécurité de confiance ou un fournisseur de réponse aux incidents. Demandez aux fournisseurs potentiels :

• Une expérience prouvée en réponse aux incidents WordPress et en chronologies judiciaires.
• Des références et des résumés d'engagements antérieurs (caviardés si nécessaire).
• Un périmètre de travail clair, des livrables et des délais pour la containment, l'éradication et la récupération.
• Une gestion sécurisée des identifiants et des pratiques de préservation des preuves.

Des conseils de test sûrs et des notes pour les équipes de sécurité.

• Testez uniquement les systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite de tester.
• N'incluez pas de fichiers sensibles dans les tests — utilisez des fichiers bénins pour confirmer le comportement d'inclusion.
• Préférez l'analyse passive des journaux avant les tests d'exploitation actifs.
• Si des tests actifs sont nécessaires, utilisez un environnement de staging isolé et conservez les journaux pour analyse.
• Suivez la divulgation responsable si vous découvrez des problèmes supplémentaires.

Le code d'exploitation public et les scanners de masse apparaissent rapidement après la divulgation ; appliquez les mesures d'atténuation rapidement.

Annexe — Exemples de règles de serveur (niveau élevé, testez avant utilisation)

Exemples de haut niveau que vous pouvez adapter à votre environnement :

• Bloquez l'accès direct à wp-config.php (extrait Nginx) : location ~* wp-config.php { deny all; }
• Refuser les demandes contenant des séquences de traversée : rejeter les demandes avec ../ ou des variantes codées où votre serveur prend en charge la correspondance des demandes.
• Bloquez les schémas d'emballage suspects : refusez les demandes contenant php://, données :, expect :, etc.

Ces règles sont intentionnellement génériques — adaptez et testez soigneusement en staging avant de déployer en production.