Pourquoi cela importe (court)

Le XSS stocké est à haut risque car les entrées malveillantes sont enregistrées côté serveur et exécutées plus tard dans le navigateur d'un autre utilisateur — souvent un administrateur. Dans ce cas, un utilisateur authentifié à faible privilège (Abonné) peut persister des charges utiles qui se déclenchent lorsque qu'un utilisateur privilégié consulte les pages affectées. Cela permet le vol de session, la prise de contrôle de compte, des actions administratives non autorisées et un compromis persistant du site.

Ce qui a été signalé

• Vulnérabilité : Cross-Site Scripting (XSS) stocké
• Logiciel affecté : WP Docs (plugin WordPress)
• Versions affectées : ≤ 2.2.9
• Version corrigée : 2.3.0
• CVE : CVE-2026-3878
• Recherche / crédit : crédité au chercheur de la divulgation publique
• Date de publication : 16 avr 2026
• Score de risque : Moyen (CVSS ~6.5) — mais l'impact pratique peut s'intensifier dans des déploiements réels

Comment la vulnérabilité fonctionne — aperçu technique (résumé expert)

1. Le plugin expose une entrée de paramètres identifiée comme wpdocs_options[icon_size] qui accepte des données fournies par l'utilisateur.
2. L'entrée est stockée de manière persistante dans la table des options de WordPress.
3. Plus tard, la valeur stockée est sortie dans un contexte HTML sans échappement ou assainissement suffisant.
4. Parce que la valeur est persistante, une condition XSS stockée existe. Un abonné authentifié peut insérer du JavaScript malveillant.
5. L'exploitation nécessite qu'un utilisateur privilégié visualise ou interagisse avec le contenu rendu (par exemple, un administrateur visitant la page des paramètres).

Important : il s'agit d'un vecteur d'injection authentifié — un attaquant a besoin d'au moins un compte d'abonné. De nombreux sites permettent l'inscription des utilisateurs ou ont des commentateurs, donc ce vecteur est réaliste sur de nombreuses installations.

Objectifs possibles des attaquants et scénarios d'impact

• Vol de session administrative : exfiltrer des cookies ou des jetons pour prendre le contrôle des comptes administratifs.
• Actions administratives à distance : émettre des requêtes AJAX en tant qu'administrateur pour créer des portes dérobées, ajouter des utilisateurs privilégiés ou modifier du code.
• Défiguration et injection de contenu visible pour les visiteurs.
• Compromis de style chaîne d'approvisionnement : implanter du code malveillant qui persiste et se propage.
• Mouvement latéral vers d'autres systèmes si les navigateurs administratifs détiennent des identifiants ou des jetons de services externes.

Bien que le CVSS marque cela comme “Moyen”, l'impact dans le monde réel sur des sites WordPress très fréquentés peut être sévère.

Étapes immédiates si vous gérez des sites WordPress utilisant WP Docs

1. Mettez à jour immédiatement : Mettez à jour WP Docs vers la version 2.3.0 ou ultérieure. C'est la solution définitive.
2. Si vous ne pouvez pas mettre à jour maintenant :
   • Désactivez le plugin jusqu'à ce que vous puissiez tester et mettre à jour en toute sécurité.
   • Appliquez un correctif virtuel (règle WAF) qui bloque les requêtes tentant de définir wpdocs_options[icon_size] un contenu suspect.
3. Changer les identifiants : Changez les mots de passe administratifs et invalidez les sessions s'il y a le moindre soupçon de compromission.
4. Scannez pour du contenu injecté : Recherchez dans la base de données pour wpdocs options et inspectez les valeurs pour ), (on\w+\s*=), (javascript:|data:text/html)
5. Bloquer ou assainir les POST qui définissent wpdocs_options[icon_size] des valeurs non numériques si le champ doit être numérique.
6. Bloquer les requêtes contenant des charges utiles encodées telles que %3C combinées avec des mots-clés suspects.

Exemple de pseudo-règle (adapter à votre syntaxe WAF) :

IF request contains parameter name: wpdocs_options[icon_size]
AND parameter value matches (?i)(<\s*script\b|on\w+\s*=|javascript:|data:text/html|%3Cscript%3E)
THEN block or sanitize request

Ajustez les règles avec soin pour éviter de perturber les actions administratives légitimes. Les correctifs virtuels sont temporaires ; appliquez la mise à jour du plugin dès que possible.

Pour les développeurs : comment cela aurait pu être évité

• Appliquez une validation côté serveur pour les entrées d'options — ne comptez jamais sur les contrôles côté client.
• Utilisez des valeurs d'options typées et validées. Si taille_icône doit être un entier, contraindre et valider (par exemple, intval() et vérification des limites).
• Échapper la sortie lors du rendu dans des contextes HTML (esc_attr(), esc_html()).
• Pour les tableaux modifiables par l'utilisateur, assainissez chaque champ de manière appropriée avant de sauvegarder.
• Utilisez des vérifications de capacité et des nonces afin que seuls les utilisateurs autorisés puissent modifier les paramètres.

Exemples de corrections pour les développeurs (conceptuel)

Lors de la sauvegarde des options :

$size = isset($_POST['wpdocs_options']['icon_size']) ? intval($_POST['wpdocs_options']['icon_size']) : 0;

Lors du rendu :

echo esc_attr( $options['taille_icône'] );

Si HTML est requis, restreignez les balises autorisées avec wp_kses().

Liste de contrôle de détection et de remédiation (concise)

• Mettez à jour WP Docs vers 2.3.0 ou une version ultérieure.
• Si vous ne pouvez pas mettre à jour immédiatement : désactivez le plugin ou activez le patch virtuel à la périphérie (WAF).
• Inspectez la base de données pour wpdocs les options et supprimez les charges utiles injectées.
• Faites tourner les mots de passe administrateurs et forcez les déconnexions.
• Scannez le système de fichiers à la recherche de fichiers modifiés et de portes dérobées.
• Vérifiez les comptes utilisateurs et supprimez les utilisateurs suspects.
• Surveillez les journaux et configurez des alertes pour les activités administratives suspectes.
• Mettez en œuvre un durcissement à long terme : 2FA, privilège minimal, CSP, scans programmés.

Exemples de commandes SQL & WP-CLI pour aider à détecter des entrées suspectes

-- SQL (rechercher du contenu suspect) SELECT option_id, option_name, option_value FROM wp_options WHERE option_name LIKE 'wpdocs_%' OR option_value REGEXP '