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

Une vulnérabilité d'inclusion de fichiers locaux se produit lorsqu'une application accepte un nom de fichier ou un chemin d'accès provenant de l'entrée utilisateur et charge ensuite ce fichier à partir du système de fichiers local sans une sanitation ou un contrôle d'accès suffisants. Dans les systèmes basés sur PHP (y compris WordPress), LFI peut permettre à un attaquant de :

• Lire des fichiers sensibles (par exemple : wp-config.php, fichiers de sauvegarde, .env fichiers, fichiers journaux).
• Exposer des identifiants (nom d'utilisateur/mot de passe de la base de données, sels et clés, clés API).
• Enchaîner vers une exécution de code à distance (RCE) lorsqu'il est combiné avec un empoisonnement de journal ou des téléchargements de fichiers écrits et des wrappers de flux PHP (par exemple, php://filter, php://input).

Étant donné que les sites WordPress contiennent souvent des fichiers qui stockent des identifiants de base de données et des clés secrètes, une LFI dans un thème ou un plugin est particulièrement dangereuse. Un attaquant non authentifié peut potentiellement exfiltrer des secrets et escalader vers une prise de contrôle complète du site.

Pourquoi cette vulnérabilité spécifique est importante

• Logiciel affecté : thème SEO intelligent (versions <= 2.9).
• Vulnérabilité : Inclusion de Fichiers Locaux (LFI).
• CVE : CVE-2026-28117.
• Privilège : Non authentifié — aucun compte WordPress valide requis.
• Gravité : Élevée (CVSS 8.1).
• Statut : Aucun correctif officiel disponible (au moment de cet avis).

Étant donné que la vulnérabilité ne nécessite aucune authentification et permet l'inclusion de fichiers arbitraires, la probabilité d'exploitation automatisée et de balayage généralisé est élevée. Les attaquants ciblent fréquemment des thèmes largement distribués pour cette raison.

Scénarios typiques d'attaquants et impact

1. Divulgation d'informations (impact initial)
   • L'attaquant lit wp-config.php pour acquérir des identifiants de base de données et des sels d'authentification.
   • L'attaquant lit des fichiers de sauvegarde, .env des fichiers, ou tout autre fichier de configuration contenant des secrets.
   • Avec les identifiants de la base de données, l'attaquant peut lire ou modifier les données du site, créer des utilisateurs administrateurs, ou extraire les hachages de mots de passe des utilisateurs.
2. Compromission complète du site (enchaînement vers RCE)
   • LFI → empoisonnement de journal : l'attaquant écrit du code PHP dans les journaux (user-agent, charges utiles de requête) et inclut ce fichier journal via LFI pour exécuter le code.
   • LFI → téléchargement de fichiers : si les téléchargements sont modifiables et pas correctement protégés, une exécution de code indirecte peut suivre.
   • LFI → la lecture des clés privées SSH ou d'autres identifiants peut permettre un mouvement latéral ou un accès aux sauvegardes.
3. Porte dérobée persistante et malware
   • Après avoir acquis des identifiants ou RCE, les attaquants installent souvent des portes dérobées persistantes, créent des tâches planifiées, ou injectent du spam SEO, des redirections malveillantes et du contenu de phishing.

Parce que ces chaînes d'attaque sont réalistes, traitez tout LFI comme urgent.

Comment la vulnérabilité est généralement exploitée (niveau élevé, pas de code d'exploitation)

LFI survient lorsqu'un développeur utilise une entrée contrôlée par l'utilisateur dans des opérations de fichiers telles que inclure, exiger, fopen, ou file_get_contents sans validation adéquate. Par exemple, un thème qui charge des modèles en fonction d'un paramètre GET ou POST et inclut directement un chemin fourni par l'utilisateur est vulnérable.

Flux d'exploitation typique (conceptuel) :

1. L'attaquant crée une requête qui tente d'inclure un fichier sensible (par exemple en utilisant le parcours de chemin : ../../wp-config.php).
2. L'application utilise le chemin fourni et renvoie le contenu du fichier dans la réponse (et donc à l'attaquant).
3. L'attaquant inspecte le contenu retourné à la recherche de secrets ; avec des identifiants de base de données, une compromission supplémentaire devient réalisable.

Important : cet avis évite de publier des chaînes d'exploitation ou du code PoC ; l'accent est mis sur la détection et l'atténuation.

Comment détecter une tentative d'exploitation

Surveillez les journaux d'accès/d'erreurs du serveur web et les journaux WordPress pour des demandes suspectes. Les indicateurs incluent :

• Des demandes contenant des séquences de traversée de chemin (../, ..%2f, %2e%2e%2f) dans les paramètres utilisés par le thème.
• Des paramètres contenant des noms de fichiers comme wp-config.php, .env, .htpasswd, id_rsa, ou d'autres noms de fichiers sensibles connus.
• Des demandes incluant des noms de wrappers de flux PHP (php://, data://, expect://), ou utilisant des filtres base64 (php://filter).
• Des chaînes d'agent utilisateur inhabituelles ou des motifs de numérisation répétés touchant des points de terminaison spécifiques au thème ou des paramètres de nom de fichier.
• Des pics soudains dans les réponses 200 pour des demandes qui font référence à des fichiers locaux, ou des sorties irrégulières (contenus de fichiers bruts).

Mettez en place des règles de détection automatisées dans votre pile de surveillance pour alerter sur ces comportements.

Exemples de motifs de journal à rechercher (conceptuels, pas des modèles d'exploitation) :

• GET /?template=../../wp-config.php
• POST /wp-content/themes/smartseo/?file=../wp-config.php
• Toute demande où un paramètre de thème contient %2e%2e ou php://filter

Atténuations immédiates (que faire tout de suite)

Si votre site utilise le thème smart SEO (≤ 2.9), agissez immédiatement. Priorisez les actions ci-dessous dans l'ordre donné.

1. Mettez le site en mode maintenance (si possible)

   Empêchez toute numérisation et exploitation automatisées supplémentaires pendant que vous évaluez.

2. Désactivez ou supprimez le thème vulnérable

   Passez à un thème par défaut sûr (par exemple, la série Twenty Twenty ou un autre thème connu comme sûr). Si vous ne pouvez pas changer immédiatement, supprimez ou renommez le dossier du thème vulnérable (par exemple, renommez wp-content/themes/smartseo à smartseo-désactivé) pour empêcher le chargement du code du thème.

3. Appliquez immédiatement des correctifs virtuels (règles WAF)

   Déployez des règles qui bloquent :

   • Les requêtes contenant des séquences de traversée de chemin dans les paramètres utilisés par le thème.
   • Les tentatives d'inclure des noms de fichiers sensibles connus (wp-config.php, .env, etc.).
   • L'utilisation de wrappers de flux PHP dans les paramètres (php://, data://, expect://).

   Remarque : le patching virtuel (via un WAF ou un proxy inverse) arrête les tentatives d'exploitation à la périphérie pendant que vous corrigez ou remplacez le code vulnérable. Si vous n'utilisez pas déjà un WAF géré, envisagez un ensemble de règles d'urgence de votre hébergeur ou d'un fournisseur de sécurité — ne tardez pas.

4. Restreignez l'accès aux fichiers sensibles via la configuration du serveur

   Refusez l'accès à wp-config.php et d'autres fichiers de configuration au niveau du serveur web (.htaccess pour Apache, configuration nginx).

   <Files wp-config.php>
     order allow,deny
     deny from all
   </Files>
   
   <FilesMatch "\.(env|ini|log|sh|bak|sql)$">
     Require all denied
   </FilesMatch>
           

   Pour nginx, ajoutez des emplacement blocs appropriés pour retourner 403 pour ces fichiers.

5. Renforcez les règles d'accès au système de fichiers PHP

   Si possible, désactivez les wrappers ou fonctions PHP dangereux au niveau de la configuration PHP (manipulez avec précaution). Assurez-vous open_basedir que les restrictions sont définies de manière appropriée pour restreindre l'accès aux fichiers PHP aux répertoires attendus.

6. Changez immédiatement vos identifiants si vous soupçonnez un compromis

   Si vous trouvez des secrets exfiltrés ou des preuves de lectures de fichiers, faites tourner vos identifiants de base de données, les sels WordPress et toutes les clés API divulguées. Révoquez et régénérez tous les jetons ou clés qui ont pu être exposés.

7. Exécutez une analyse complète des logiciels malveillants et un contrôle d'intégrité.

   Scannez votre site à la recherche de signes de logiciels malveillants/backdoors. Recherchez des fichiers récemment modifiés, des fichiers PHP inconnus, des tâches planifiées (cron) et des utilisateurs administrateurs non autorisés.

8. Auditer les journaux pour une activité suspecte

   Exportez les journaux d'accès et d'erreurs et recherchez des demandes suspectes comme décrit ci-dessus ; identifiez les exploits réussis possibles et la chronologie.

9. Restaurez à partir d'une sauvegarde propre si nécessaire

   Si vous trouvez des signes de compromis au-delà d'une simple exposition de données (malware ou backdoors persistants), restaurez à partir de la sauvegarde propre la plus récente, puis mettez à jour les identifiants et les mesures de durcissement avant de remettre le site en ligne.

Comment les protections gérées et le patching virtuel peuvent aider

Une défense en couches aide lorsqu'un patch officiel n'est pas encore disponible. Les protections gérées (WAF, proxys inverses, fonctionnalités de sécurité CDN) et le patching virtuel offrent une réduction immédiate des risques en bloquant les modèles d'exploitation à la périphérie. Capacités typiques à rechercher :

• Règles WAF qui détectent et bloquent les tentatives de traversée de chemin, les wrappers de flux suspects et les tentatives d'accès à des noms de fichiers sensibles connus.
• Patching virtuel : ensembles de règles de réponse rapide qui bloquent les modèles d'attaque pendant que vous appliquez des correctifs au niveau du code.
• Analyse de logiciels malveillants et vérifications d'intégrité programmées pour détecter les fichiers modifiés ou nouvellement ajoutés.
• Journalisation des événements et alertes — notification immédiate des tentatives LFI bloquées afin que les administrateurs puissent trier et répondre.
• Conseils pour un code sûr et un durcissement du serveur par des équipes de sécurité qualifiées ou votre fournisseur d'hébergement.

Déployer de telles protections est une stratégie efficace à court terme : elles arrêtent automatiquement l'exploitation opportuniste, vous donnant le temps de corriger, remplacer ou supprimer le code vulnérable.

Stratégies pratiques de règles WAF (conceptuelles)

Exemples de stratégies de règles pour atténuer les tentatives LFI :

• Bloquez les valeurs de paramètres contenant des jetons de traversée de chemin : ../, ..%2f, %2e%2e%2f.
• Bloquez les paramètres contenant wp-config.php, .env, id_rsa, config.php où le chemin de la demande n'est pas un fichier administrateur authentifié.
• Bloquez les demandes utilisant php:// ou data:// enveloppes dans les paramètres.
• Bloquer les combinaisons suspectes : traversée de chemin + extension de fichier sensible (.php, .sql, .conf, .env).
• Limiter le taux ou mettre sur liste noire les IP affichant un comportement de scan sur plusieurs hôtes.
• Utiliser une liste blanche positive lorsque cela est possible : si le thème n'accepte qu'une petite liste de noms de modèles, autoriser uniquement ces valeurs.

Appliquer ces protections fournit une atténuation immédiate sans changer le code du site.

Guide pour les développeurs — gestion sécurisée des inclusions de fichiers

Si vous maintenez ou développez des thèmes/plugins, suivez ces meilleures pratiques pour prévenir LFI :

1. Ne jamais inclure directement des entrées contrôlées par l'utilisateur. Évitez le code comme 8. include($_GET['page']) ou require_once($_REQUEST['file']).
2. Utilisez une validation basée sur une liste blanche. Accepter uniquement un petit ensemble connu de noms de modèles ou de fichiers. Mapper ces noms à de vrais chemins sur le serveur.

<?php
    

3. Si les chemins de fichiers dynamiques sont inévitables, assainir et valider. Utilisez basename() et validez avec realpath() pour s'assurer que le chemin résolu est à l'intérieur d'un répertoire autorisé.

<?php
    

4. Évitez d'exposer le contenu brut des fichiers aux réponses publiques. Si un fichier doit être lu, appliquez des contrôles d'accès stricts et ne pas afficher le contenu brut du fichier.
5. Suivez le principe du moindre privilège pour les permissions de fichiers. Les modèles doivent être lisibles mais pas accessibles en écriture par tous. wp-config.php doivent avoir le moins de privilèges possible (par exemple, 640) et être possédés par l'utilisateur du serveur web lorsque cela est approprié.

Ces modèles de codage empêchent les astuces basées sur des chaînes comme la traversée de chemin et l'abus de wrapper.

Liste de contrôle pour le renforcement du serveur et de WordPress

• Restreignez l'accès à wp-config.php via les règles du serveur web.
• Désactiver l'affichage des répertoires.
• Assurez-vous que les permissions des fichiers sont correctes : thèmes/plugins lisibles, fichiers non accessibles en écriture par tous.
• Désactivez l'exécution PHP dans wp-content/uploads (bloquer l'exécution via .htaccess ou les règles nginx).
• Définissez open_basedir pour restreindre PHP aux répertoires attendus si possible.
• Utilisez des sels et des clés sécurisés dans wp-config.php; régénérez-les si vous soupçonnez une compromission.
• Désactivez l'éditeur de fichiers de thème et de plugin dans wp-config.php: define('DISALLOW_FILE_EDIT', true);
• Limitez les fonctions PHP uniquement si vous savez ce qui est sûr à désactiver (soyez prudent ; la fonctionnalité du site peut être affectée).
• Gardez le cœur de WordPress, les plugins et les thèmes à jour. Si un correctif officiel est publié pour le thème smart SEO, appliquez-le après l'avoir testé en staging.

Réponse aux incidents — que faire si vous avez été exploité

1. Isoler — Mettez le site hors ligne ou mettez-le en mode maintenance ; isolez-le des autres systèmes s'il est hébergé sur une infrastructure partagée.
2. Collecter des preuves — Conservez les journaux d'accès, les journaux d'erreurs, les sauvegardes de base de données et les instantanés du système de fichiers pour une analyse judiciaire.
3. Faire tourner les secrets — Changez les mots de passe de la base de données, les mots de passe administratifs WordPress, les clés API et toute autre information d'identification stockée sur le site ou les services à proximité.
4. Scanner et nettoyer — Exécutez une analyse complète des logiciels malveillants. Supprimez ou remplacez les portes dérobées ou les fichiers inconnus. Vérifiez les comptes utilisateurs — supprimez les utilisateurs administrateurs indésirables.
5. Restaurez à partir d'une sauvegarde propre — Si l'intégrité est incertaine, restaurez à partir d'une sauvegarde antérieure à la compromission. Après la restauration, renforcez et faites tourner les informations d'identification avant de rendre le site actif.
6. Audit et surveillance — Après le nettoyage, activez la surveillance continue et des protections de bord plus strictes. Surveillez les signes de réinfection.
7. Informez les parties prenantes — Informez les clients, utilisateurs ou clients comme l'exige votre politique de réponse aux incidents ou les obligations légales/réglementaires.

Prévention et surveillance à long terme

• Mettez en œuvre des protections en périphérie (WAF géré / proxy inverse) avec des correctifs virtuels et des mises à jour de signatures pour protéger contre les tentatives d'exploitation LFI connues et inconnues.
• Effectuez des audits de sécurité réguliers et des revues de code, en particulier pour les thèmes personnalisés ou les thèmes tiers qui ne sont pas souvent maintenus.
• Planifiez des vérifications d'intégrité automatisées et une surveillance des fichiers pour détecter rapidement les modifications.
• Conservez des sauvegardes sécurisées et testées dans un emplacement hors site et vérifiez régulièrement les procédures de restauration.
• Utilisez un processus de déploiement par étapes pour les mises à jour : testez en préproduction avant la production.

Liste de contrôle de détection pratique pour les administrateurs

• Recherchez dans les journaux les requêtes contenant : ../, %2e%2e, wp-config.php, .env, php://.
• Surveillez les réponses 200 répétées aux requêtes GET/POST qui ressemblent à des lectures de fichiers.
• Vérifiez les nouveaux fichiers PHP ou les fichiers modifiés dans les thèmes, plugins ou wp-content répertoires.
• Vérifiez les heures de modification des fichiers critiques (wp-config.php, .htaccess, index.php).
• Assurez-vous que tous les comptes administrateurs sont connus et qu'aucun administrateur non autorisé n'existe.

Questions fréquemment posées

Q : Un LFI peut-il entraîner une prise de contrôle complète du serveur ?

R : Oui — si l'attaquant peut récupérer des identifiants (par exemple, depuis wp-config.php) ou enchaîner LFI à l'exécution de code à distance (par exemple, en injectant du PHP dans les journaux), il peut escalader vers un compromis complet du site.

Q : Si je bloque le dossier du thème avec .htaccess, est-ce sûr ?

R : Bloquer l'accès direct aux fichiers PHP du thème peut réduire le risque, mais ce n'est pas un substitut à la suppression ou au correctif du code vulnérable. Certaines fonctionnalités du thème peuvent être rompues. L'action à court terme la plus sûre est de désactiver le thème.

Q : Dois-je faire tourner les identifiants de la base de données même si je ne trouve pas de preuve d'exploitation ?

A : Si vous trouvez des preuves de tentatives LFI contre votre site, le changement de mots de passe est une précaution recommandée, surtout parce qu'un attaquant peut avoir accédé silencieusement à des fichiers.

Options immédiates pour les propriétaires de sites

Si vous avez besoin d'une réduction rapide des risques et ne pouvez pas immédiatement corriger le thème, envisagez ces actions :

• Mettez le site en mode maintenance et supprimez ou renommez le répertoire du thème vulnérable.
• Demandez à votre fournisseur d'hébergement des règles WAF d'urgence ou des filtres de bord pour bloquer le parcours de chemin et les noms de fichiers sensibles connus.
• Engagez un consultant en réponse aux incidents ou en sécurité qualifié pour trier, déployer des correctifs virtuels et effectuer un examen forensic.
• Changez les mots de passe et effectuez une analyse approfondie de l'intégrité des fichiers et des logiciels malveillants.

Ne comptez pas uniquement sur l'espoir que le site ne sera pas ciblé — les scanners automatisés rechercheront rapidement cette classe de vulnérabilité.