Résumé (TL;DR)

• Vulnérabilité : XSS stocké non authentifié dans le plugin Nom Répertoire (versions ≤ 1.30.3). Le contenu fourni par l'utilisateur peut être stocké et rendu ultérieurement sans désinfection ni échappement adéquats.
• Impact : Exécution de scripts contrôlés par l'attaquant dans le navigateur de quiconque visualisant le contenu stocké (administrateurs, éditeurs, visiteurs). Les conséquences incluent le vol de session, la défiguration persistante, les redirections malveillantes, les actions administratives non autorisées et la distribution de logiciels malveillants.
• Versions affectées : Nom Répertoire ≤ 1.30.3.
• Actions immédiates : Isoler les points de terminaison, bloquer le trafic suspect, auditer les entrées stockées du plugin pour des scripts injectés, empêcher les administrateurs de visualiser du contenu suspect, scanner et nettoyer le site, et appliquer des règles WAF virtuelles lorsque disponibles.
• À long terme : Mettre à jour ou supprimer le plugin, désinfecter les enregistrements stockés et renforcer la validation des entrées, l'échappement, la surveillance et les processus d'incidents.

Qu'est-ce que le XSS stocké et pourquoi le XSS stocké non authentifié est dangereux

Le Cross-Site Scripting (XSS) se produit lorsque le contenu fourni par l'utilisateur est inclus dans une page web sans échappement approprié, permettant à un attaquant d'exécuter un script dans le navigateur de la victime. Le XSS stocké (persistant) signifie que la charge utile malveillante est sauvegardée sur le serveur (par exemple, dans la base de données) et exécutée chaque fois que le contenu est visualisé. Si un attaquant peut stocker un tel contenu sans authentification, la surface d'attaque est beaucoup plus grande : tout acteur anonyme ou bot automatisé peut soumettre des charges utiles qui persistent jusqu'à ce qu'elles soient nettoyées.

Dans les contextes WordPress, ce risque est amplifié car :

• Les administrateurs visualisent régulièrement du contenu tout en étant connectés ; un seul clic de prévisualisation peut déclencher une escalade.
• Les cookies de session et les jetons d'authentification sont présents dans le navigateur et peuvent être ciblés pour le vol.
• D'autres plugins et intégrations peuvent élargir la portée de l'impact lorsque l'attaquant obtient un point d'appui initial.

Vue d'ensemble technique de la vulnérabilité du Nom Répertoire

À un niveau élevé, le problème fonctionne comme suit :

1. Le plugin accepte des entrées via des formulaires publics ou des points de terminaison (points de terminaison REST, formulaires shortcode, etc.) de la part d'utilisateurs non authentifiés.
2. Certains champs d'entrée (noms, descriptions, notes) sont stockés dans la base de données sans une sanitation adéquate côté serveur.
3. Lorsque ces valeurs stockées sont affichées sur des pages ou des écrans d'administration, elles ne sont pas correctement échappées pour le contexte HTML. Les navigateurs interprètent donc le balisage ou les scripts injectés comme exécutables.

Les attaquants utilisent généralement