Exposition WordPress : version, readme.html, install.php, listing de répertoires

Les attaquants ne devinent pas — ils vérifient 4 fichiers précis. Les tests #41 à #44 révèlent si votre site WordPress diffuse ses vulnérabilités au monde entier.

Avant de lancer une vraie attaque, chaque hacker suit la même checklist. Il ne commence pas par du brute force ou de l'injection SQL. Il commence par la reconnaissance — collecter des informations sur la cible. Et WordPress lui facilite remarquablement la tâche.

Par défaut, WordPress expose son numéro de version dans le code source HTML, laisse un fichier readme.html à la racine, garde le script d'installation accessible et laisse n'importe qui parcourir les répertoires internes. Chacun de ces éléments est un indice gratuit pour un attaquant.

Orilyt exécute 4 tests complémentaires pour détecter ces expositions. Le test #41 vérifie le fingerprinting de version. Le test #42 sonde readme.html et license.txt. Le test #43 teste l'accessibilité d'install.php. Le test #44 vérifie le listing de répertoires sur wp-content, wp-includes, uploads, plugins et themes. Ensemble, ils cartographient l'intégralité de la surface de fuite d'informations d'un site WordPress.

Test #41 : Votre version WordPress est-elle exposée ?

Le test #41 recherche 4 signaux distincts qui révèlent votre version WordPress à quiconque prend la peine de regarder :

1. Balise meta generator — WordPress injecte <meta name="generator" content="WordPress X.X"> dans le head HTML par défaut. C'est la divulgation de version la plus directe. N'importe quel scanner la détecte instantanément
2. Chaînes de version des assets — les fichiers CSS et JS de wp-includes et wp-content incluent des paramètres ?ver=X.X.X. Ces chaînes correspondent souvent exactement à la version du cœur WordPress
3. Endpoint REST API — /wp-json/ est accessible par défaut et confirme que WordPress est installé. La réponse inclut des informations de namespace qui révèlent la version de l'API
4. En-tête Link — WordPress envoie un en-tête HTTP Link référençant wp-json, confirmant le CMS avant même le chargement du corps de la page

Score : si la balise meta generator et les chaînes de version des assets sont toutes deux présentes, le score chute à 30/100. Un signal critique plus l'API REST = 50. L'API REST seule (sans données de version) = 80. Si tous les signaux sont masqués, le score est de 100.

Test #42 : Les fichiers readme.html et license.txt sont-ils accessibles ?

Chaque installation WordPress est livrée avec deux fichiers à la racine : readme.html et license.txt. Ils ne servent à rien en production — mais ils confirment le CMS et peuvent révéler des détails de version :

1. readme.html — ce fichier est une page HTML formatée qui affiche « WordPress » en gros et inclut souvent le numéro de version exact. C'est la vérification de fingerprint la plus simple : requêter /readme.html, vérifier si le retour est 200
2. license.txt — contient le texte de la licence GPL avec « WordPress » dans l'en-tête. Moins directement utile aux attaquants que readme.html, mais confirme tout de même le CMS et l'absence de durcissement

Score : les deux fichiers accessibles = 30/100. Seul readme.html accessible = 40. Seul license.txt = 60. Les deux retournent 403 ou 404 = 100. Ces fichiers ne devraient tout simplement pas être servis en production.

Test #43 : Le fichier install.php est-il accessible ?

L'installeur WordPress se trouve à /wp-admin/install.php. Sur un site correctement configuré, ce script redirige vers la page de connexion ou retourne 403/404. Mais sur des serveurs mal configurés, il peut être directement accessible :

1. Le test requête /wp-admin/install.php et vérifie la réponse HTTP. Si la réponse est 200 et que le corps contient « install WordPress » ou le mot-clé « wp-install », le script est exposé
2. Un installeur accessible est un constat critique. Dans le pire des cas, un attaquant pourrait déclencher une réinstallation — réinitialiser la connexion à la base de données, créer un nouveau compte administrateur et prendre le contrôle total du site
3. La plupart des hébergeurs gèrent cela automatiquement, mais les configurations serveur personnalisées, les setups Docker ou Nginx sans règles appropriées le laissent souvent exposé

Score : si la page d'installation est accessible et ressemble à l'assistant d'installation WordPress, le score chute à 30/100. Une réponse 403/404 = 100. Une redirection = 95.

Test #44 : Le listing de répertoires est-il activé ?

Le listing de répertoires (autoindex) permet à n'importe qui de parcourir le contenu d'un dossier via le navigateur. Le test #44 vérifie 5 répertoires WordPress critiques :

1. /wp-content/ — le répertoire de contenu principal. Le lister révèle tous les plugins installés, thèmes et dossiers d'uploads en un coup d'œil
2. /wp-includes/ — les fichiers du cœur WordPress. Le listing confirme la structure d'installation et la version
3. /wp-content/uploads/ — les fichiers téléchargés par les utilisateurs. Peut contenir des documents sensibles, factures ou fichiers de sauvegarde jamais destinés à être publics
4. /wp-content/plugins/ — chaque plugin installé est visible avec son nom de répertoire exact, rendant triviale la recherche de vulnérabilités connues pour chacun
5. /wp-content/themes/ — tous les thèmes visibles, y compris les inactifs qui peuvent avoir des failles de sécurité non corrigées

Le test requête chaque répertoire et cherche des marqueurs d'autoindex dans la réponse : « Index of / », « Directory listing for », liens « Parent Directory ». Si le serveur retourne une page HTML listant les fichiers au lieu d'un 403, le répertoire est exposé.

Score : 3 répertoires ou plus exposés = 20/100. Deux exposés = 35. Un seul exposé = 50. Tous bloqués (403/404) = 100. Le répertoire uploads reçoit un poids supplémentaire car il peut contenir des données utilisateur.

Corrections courantes — toutes en moins de 5 minutes

Chacune de ces expositions se corrige avec de simples changements de configuration. Pas de code, pas de plugin, pas d'interruption de service :

1. Supprimer la balise meta generator — ajoutez remove_action('wp_head', 'wp_generator') dans le functions.php de votre thème. Une ligne, effet immédiat
2. Supprimer les chaînes de version des requêtes — ajoutez un filtre pour retirer les paramètres ?ver= des scripts et styles. Ou utilisez un plugin de sécurité qui le fait automatiquement
3. Bloquer readme.html et license.txt — ajoutez une règle deny dans .htaccess : <Files "readme.html"> Require all denied </Files>. Ou supprimez simplement les fichiers (ils reviendront aux mises à jour, donc le .htaccess est préférable)
4. Bloquer install.php pour les non-authentifiés — la plupart des hébergeurs gèrent cela, mais si le vôtre ne le fait pas, ajoutez une règle .htaccess dans wp-admin/ pour restreindre l'accès à install.php
5. Désactiver le listing de répertoires — ajoutez Options -Indexes dans votre .htaccess racine. Cette seule ligne bloque l'autoindex pour tout le site. Elle devrait déjà être présente sur la plupart des installations WordPress, mais beaucoup de configurations personnalisées l'oublient

Le schéma est constant : ce sont tous des problèmes de configuration par défaut. WordPress est livré dans un état permissif pour faciliter l'installation. Le durcissement est une étape séparée que la plupart des propriétaires ne franchissent jamais.

Pourquoi ces constats vendent des contrats de maintenance

Pour les freelances et agences, ces 4 tests sont de puissants démarreurs de conversation. Ils sont faciles à démontrer, visuellement évidents, et le client n'a pas besoin de comprendre le code :

Dans le rapport Orilyt, chaque test génère une recommandation FIA :

1. Fait : « La version WordPress 6.4.1 est visible dans le code source HTML » ou « 5 répertoires sont librement navigables »
2. Impact : « Les attaquants peuvent chercher les exploits connus pour cette version exacte » ou « Tous les plugins installés sont visibles, permettant un scan ciblé de vulnérabilités »
3. Action : « Supprimer la balise meta generator et retirer les chaînes de version » ou « Ajouter Options -Indexes dans le .htaccess »

Ces constats créent l'urgence parce qu'ils sont tangibles. Vous pouvez ouvrir le navigateur du client, taper /readme.html et lui montrer la version WordPress à l'écran. Vous pouvez parcourir /wp-content/plugins/ et lister chaque plugin installé. Ce n'est pas abstrait — c'est une démonstration en direct de l'exposition.

Les 4 fichiers que les hackers vérifient en premier — testés en quelques secondes

L'exposition WordPress n'est pas une question d'attaques sophistiquées. C'est une question de fruits à portée de main. Numéros de version, fichiers par défaut, installeur accessible, listing de répertoires — ce sont les premières choses que tout scanner ou attaquant vérifie. Et tout se corrige en quelques minutes.

Les tests #41 à #44 couvrent toute cette surface. Ils détectent chaque fuite d'information courante, évaluent la gravité et génèrent des recommandations claires. Exécutez-les avant qu'un attaquant ne le fasse.

Pour les audits orientés client, les constats d'exposition WordPress sont le point d'entrée parfait. Ils sont visuels, urgents, et les corrections sont rapides. Si un site échoue à ces 4 tests, il y a une conversation sécurité à avoir — et probablement un contrat à signer.