Une vulnérabilité d'inclusion de fichiers locaux (LFI) de haute sévérité a été divulguée, affectant le thème WordPress Welldone (versions ≤ 2.4). Suivie sous le nom de CVE-2026-28118 et attribuée d'un score de base CVSS de 8.1, cette faiblesse permet à des attaquants non authentifiés d'inclure des fichiers locaux sur un site vulnérable et d'exposer leur contenu. Les informations dans les fichiers locaux (identifiants de base de données, clés API, détails de configuration) peuvent mener à un compromis total — une action immédiate est requise pour tout site utilisant le thème affecté.

Cet avis est rédigé avec un ton pratique, de praticien de la sécurité à Hong Kong : concis, priorisé et axé sur une containment rapide suivie de vérification et de récupération. Partagez cela avec vos équipes d'opérations ou d'hébergement et priorisez les étapes de “ Mitigation immédiate ” si vous administrez plusieurs sites.

Résumé de la divulgation

• Logiciel affecté : thème WordPress Welldone
• Versions vulnérables : ≤ 2.4
• Type de vulnérabilité : Inclusion de Fichiers Locaux (LFI)
• CVE : CVE-2026-28118
• CVSS : 8.1 (Élevé)
• Privilège requis : Aucun (non authentifié)
• Impact : Lecture arbitraire de fichiers locaux ; possible divulgation d'identifiants et de fichiers sensibles ; peut mener à une prise de contrôle totale selon la configuration du serveur
• Rapporté par : Tran Nguyen Bao Khanh (rapporté le 19 août 2025 ; divulgation publique le 26 février 2026)

Pourquoi LFI est si dangereux pour les sites WordPress

L'inclusion de fichiers locaux se produit lorsque le code construit un chemin vers un fichier local en utilisant une entrée fournie par l'utilisateur sans validation appropriée, puis inclut ou lit ce fichier. En PHP, des fonctions telles que include(), require(), include_once() et require_once() sont des points de défaillance courants — en particulier dans les thèmes et les plugins qui chargent des parties de modèles ou des fichiers en fonction des paramètres de requête.

Pour WordPress, les conséquences sont graves :

• wp-config.php contient souvent des identifiants de base de données et des sels ; le lire peut donner à un attaquant un accès complet à la base de données.
• D'autres fichiers peuvent contenir des clés API, des identifiants SMTP ou des données propriétaires.
• Les wrappers de flux PHP (php://filter, data://) ou les emplacements de téléchargement accessibles peuvent aider un attaquant à passer de la lecture de fichiers à l'exécution de code.
• La faille est non authentifiée, donc un scan et une exploitation automatisés de masse sont probables ; un scan rapide par des attaquants opportunistes est attendu.

Comment les attaquants exploitent généralement LFI (niveau élevé)

Un attaquant trouve un paramètre utilisé dans un appel include() (par exemple : include( $template_path . $_GET[‘page’] . ‘.php’ ); ). Sans validation, l'attaquant peut envoyer des charges utiles de traversée de répertoire (../../../../wp-config.php) ou utiliser des wrappers de flux PHP (php://filter) pour lire des fichiers locaux arbitraires. LFI peut souvent être enchaîné pour atteindre l'exécution de code à distance (RCE) en exposant des zones de téléchargement écrites ou des fichiers journaux.

Nous ne fournissons pas de charges utiles d'exploitation fonctionnelles ici ; les défenseurs devraient se concentrer sur la reconnaissance des modèles et des indicateurs énumérés ci-dessous.

Indicateurs d'attaque et de compromission - ce qu'il faut rechercher

Surveillez les journaux d'accès du serveur web, les journaux d'erreurs PHP et tout journal WordPress pour ces signes :

1. Requêtes contenant des motifs de traversée de répertoire dans les chaînes de requête :
   • Séquences “../” non encodées ou encodées (par exemple, ..%2F, %2e%2e%2f)
   • Tentatives de traversée répétées comme ../../../../
2. Requêtes faisant référence à des noms de fichiers sensibles :
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd
3. Requêtes utilisant des noms de paramètres LFI courants :
   • Paramètres nommés fichier, page, modèle, inc, chemin, module
   • Sursauts de charges utiles de traversée variées vers les points de terminaison de thème
4. Utilisation de motifs de wrapper de flux PHP :
   • php://filter, expect://, data:// dans les paramètres de requête
5. Fichiers anormaux ou modifications sous des répertoires écrits :
   • Nouveaux fichiers PHP/JS ou fichiers suspects dans wp-content/uploads, wp-content/themes//
   • Fichiers de modèle ou de plugin modifiés de manière inattendue
6. Activité de base de données inhabituelle : création inattendue d'utilisateurs administrateurs, requêtes étranges ou injections de contenu.

Si vous trouvez l'un de ces indicateurs, traitez la situation comme une priorité élevée et suivez la liste de contrôle de réponse aux incidents ci-dessous.

Atténuation immédiate (heures) — actions triées et pratiques

Ces étapes sont ordonnées par rapidité et impact probable. Effectuez-les immédiatement si vous utilisez le thème affecté ou si vous n'êtes pas sûr.

1. Désactivez temporairement le thème vulnérable
   • Passez à un thème par défaut standard et maintenu pour réduire rapidement la surface d'attaque.
   • Si le changement n'est pas possible, placez le site en mode maintenance tout en appliquant d'autres atténuations.
2. Supprimez ou mettez en quarantaine le thème vulnérable du système de fichiers
   • En utilisant SFTP/SSH, renommez ou supprimez le répertoire du thème vulnérable dans wp-content/themes/ pour empêcher l'exécution du code du thème.
   • Conservez une copie hors serveur pour analyse si vous enquêtez.
3. Bloquez les requêtes suspectes au niveau du serveur web
   • Bloquez les requêtes contenant des séquences de traversée de répertoires et des wrappers de flux PHP au niveau du serveur web (nginx ou Apache). Testez d'abord les règles sur un environnement de staging pour éviter de casser le trafic légitime.
   • Exemple nginx (conceptuel) :

   if ($request_uri ~* "(%2e|%2f|\.\./|\.\.\\)") {
       return 403;
   }
   if ($request_uri ~* "php://|data://|expect://|file://") {
       return 403;
   }

   • Exemple Apache (.htaccess) — refuser l'accès direct à wp-config et bloquer les chaînes de requête suspectes :

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   <IfModule mod_rewrite.c>
     RewriteEngine On
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>

4. Renforcez les permissions et la propriété des fichiers (vérifications rapides)
   • Assurez-vous wp-config.php n'est pas lisible par tous : utilisez 400 ou 440 lorsque cela est approprié.
   • Paramètres standard : répertoires 755, fichiers 644 (renforcez davantage les fichiers sensibles).
   • Assurez-vous d'une propriété appropriée et évitez d'exécuter des processus de serveur web en tant que même utilisateur capable de modifier les fichiers du site si votre hébergeur prend en charge la séparation.
5. Désactivez les wrappers et fonctions PHP dangereux lorsque cela est possible
   • Dans php.ini, définissez allow_url_fopen = Désactivé et allow_url_include = Désactivé.
   • Envisagez de désactiver les fonctions risquées si elles ne sont pas nécessaires : exec, shell_exec, système, passthru, proc_open, popen. Exemple :

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen

6. Bloquer les paramètres fournis par l'utilisateur utilisés pour les chargements de fichiers
   • Si les points de terminaison du thème acceptent fichier ou modèle des paramètres, ajoutez des règles temporaires côté serveur pour bloquer ou valider ces paramètres jusqu'à ce que vous puissiez appliquer un correctif.

Remédiation et vérification à moyen terme (jours)

1. Remplacer ou mettre à jour le thème
   • Vérifiez s'il existe une version officielle corrigée de Welldone qui traite le CVE-2026-28118. Lorsqu'elle est disponible, testez sur un environnement de staging puis déployez en production.
   • S'il n'existe pas de correctif, envisagez de remplacer le thème par une alternative maintenue ou de créer un enfant personnalisé d'un thème de base maintenu.
2. Auditez votre système de fichiers à la recherche de webshells et de fichiers suspects
   • Analysez wp-content/uploads, répertoires de thèmes et de plugins pour des fichiers PHP inattendus, des modifications récentes ou des modèles IOC connus.
3. Faites tourner les identifiants et les secrets
   • Faites tourner tous les mots de passe administratifs WordPress, les identifiants de base de données, les clés API et tous les jetons qui ont pu être exposés.
   • Après une restauration à partir d'une sauvegarde, faites toujours tourner les identifiants.
4. Examiner les journaux du serveur et de l'application
   • Recherchez dans les journaux avant et après la date de divulgation des signes d'exploitation. Exportez les journaux pertinents vers un emplacement sécurisé pour des analyses judiciaires si nécessaire.
5. Analyse complète du site pour les logiciels malveillants et vérification de l'intégrité
   • Exécutez des analyseurs de logiciels malveillants et des vérifications d'intégrité des fichiers pour trouver des webshells, des portes dérobées et des fichiers de base modifiés. Comparez le code à des sources connues comme étant saines.
6. Restaurez à partir de sauvegardes propres si la compromission est confirmée
   • Si vous ne pouvez pas nettoyer en toute confiance un site compromis, restaurez à partir d'une sauvegarde connue comme étant saine prise avant les premiers signes de compromission. Après la restauration, appliquez un durcissement et faites tourner les identifiants.

Prévention et durcissement à long terme (semaines / en cours)

• Principe du moindre privilège : Assurez-vous que les utilisateurs de fichiers et de bases de données n'ont que les autorisations requises.
• Environnements isolés : Utilisez des identifiants séparés et une isolation entre la mise en scène et la production.
• Surveillance continue et alertes : Centralisez les journaux et ajoutez des alertes pour les tentatives de traversée de répertoire, les références à wp-config.php, et les pics inhabituels d'erreurs.
• Analyse régulière des vulnérabilités et revues de code : Scans automatisés plus des revues manuelles périodiques du code des thèmes et des plugins.
• Sauvegardes régulières et restaurations testées : Sauvegardes hors site, versionnées et tests de restauration réguliers.
• Renforcement de WordPress : Gardez le cœur, les plugins et les thèmes à jour ; supprimez les composants inutilisés ; désactivez les éditeurs de fichiers ; implémentez des en-têtes de sécurité et appliquez HTTPS.

Règles de détection et de prévention suggérées (conceptuelles)

Adaptez ces modèles dans votre WAF ou ensemble de règles de serveur et testez soigneusement pour éviter les faux positifs. Ce sont des extraits regex conceptuels pour la création de règles :

• Bloquer la traversée de répertoire : (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• Bloquer les wrappers de flux PHP : (php://|data://|expect://|zip://|phar://)
• Bloquer les références à des fichiers sensibles : (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• Bloquer les longues séquences encodées souvent utilisées pour l'obfuscation : (%[0-9A-Fa-f]{2}){6,}

Exemple de pseudo-règle (indépendant du WAF) : Si une chaîne de requête de demande correspond à l'un des :

• (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c) OU
• (php://|data://|expect://) OU
• (wp-config\.php|/etc/passwd|\.env)

Alors bloquez la demande (HTTP 403) et enregistrez les détails. Limitez les règles aux points de terminaison probables pour réduire les faux positifs.

Si votre site a été compromis — liste de contrôle de réponse à l'incident

1. Mettez le site hors ligne (mode maintenance) ou isolez l'hôte.
2. Prenez un instantané complet du site et des journaux pour une analyse judiciaire.
3. Changez tous les mots de passe : utilisateurs administrateurs, base de données, FTP/SFTP, panneau de contrôle.
4. Faites tourner les clés API et les jetons qui ont pu être stockés sur le serveur.
5. Scannez et supprimez les fichiers malveillants et les webshells ; si vous n'êtes pas sûr, restaurez à partir d'une sauvegarde propre.
6. Vérifiez l'intégrité de la base de données et supprimez les utilisateurs administrateurs non autorisés ou le contenu injecté.
7. Effectuez un audit complet pour déterminer le chemin de l'attaque et tout mouvement latéral.
8. Reconstruisez l'environnement à partir de sources connues et fiables si nécessaire ; ne comptez pas uniquement sur le “ nettoyage ” si des portes dérobées peuvent persister.

Note technique pour développeurs et administrateurs système

Cette classe de vulnérabilité provient généralement d'une concaténation non sécurisée des entrées utilisateur dans les chemins du système de fichiers. Suivez ces pratiques sécurisées :

• N'utilisez jamais d'entrées utilisateur brutes pour construire des noms de fichiers sans autoriser des valeurs sur liste blanche.
• Utilisez des mappages : associez des clés courtes à des noms de fichiers autorisés au lieu d'accepter des chemins complets.
• Normalisez et validez tout chemin avant de le passer à include/require.
• Si le contenu utilisateur détermine la sélection du modèle, restreignez les choix à un ensemble de confiance présent dans votre code source.

Exemple de modèle sûr (pseudo-code) :

$allowed_templates = ['home', 'archive', 'single'];

Extraits pratiques pour le serveur (résumé)

Testez-les sur un hôte de staging avant de les déployer en production :

Protégez wp-config.php (Apache .htaccess) :

<files wp-config.php>
  order allow,deny
  deny from all
</files>

Règle Nginx pour bloquer les tentatives de wrapper php (conceptuel) :

if ($query_string ~* "php://|data://|%2e%2e|(\.\./)") {
  return 403;
}

Durcissement PHP ini (exemple) :

allow_url_fopen = Off

Actions finales — que faire dans les 24 à 72 heures suivantes

1. Inventaire : Identifier tous les sites utilisant le thème Welldone ≤ 2.4.
2. Appliquer au moins une atténuation immédiate :
   • Désactiver ou renommer le dossier du thème, ou
   • Bloquer les modèles d'exploitation au niveau du serveur, et
   • Verrouiller wp-config.php l'accès.
3. Activer la surveillance et le scan continus pour les indicateurs décrits ci-dessus.
4. Si vous hébergez des clients, informez les parties prenantes et appliquez rapidement des atténuations à travers les locataires affectés.

Besoin d'une assistance professionnelle ?

Si vous gérez de nombreuses installations WordPress ou manquez de capacité de réponse aux incidents en interne, engagez un fournisseur de réponse aux incidents réputé ou l'équipe de sécurité de votre fournisseur d'hébergement. Priorisez la containment, la capture de journaux et la criminalistique avant toute nettoyage agressif qui pourrait détruire des preuves.