Nom du plugin	ajouterespacegratuit
Type de vulnérabilité	CSRF
Numéro CVE	CVE-2026-6701
Urgence	Faible
Date de publication du CVE	2026-05-04
URL source	CVE-2026-6701

Vol de requête intersite (CSRF) enchaîné à un script intersite stocké (XSS) dans addfreespace <= 0.1.3 — Ce que les propriétaires de sites WordPress doivent savoir et faire

Une vulnérabilité récemment divulguée impactant le ajouterespacegratuit plugin WordPress (versions <= 0.1.3) a été assignée CVE‑2026‑6701. La vulnérabilité est un problème CSRF (Vol de requête intersite) qui peut être enchaîné à une condition XSS (Script intersite) stockée. Bien que la note CVSS globale soit relativement basse (4.3), le risque dans le monde réel peut être plus élevé que le chiffre ne le suggère — surtout lorsque les attaquants ciblent des sites dans des campagnes de masse ou comptent sur le fait de tromper des utilisateurs privilégiés pour qu'ils interagissent avec un lien ou une page malveillante.

En tant qu'équipe de sécurité pour WP‑Firewall, nous voulons expliquer, en termes simples et avec des conseils spécifiques, ce que signifie ce problème, comment il peut être abusé, comment détecter l'exploitation, et — surtout — ce que vous pouvez faire dès maintenant pour protéger vos sites. Ce guide est rédigé pour les propriétaires de sites, les administrateurs, les développeurs et les équipes d'hébergement.

---

Résumé analytique (points à retenir)

• Une vulnérabilité dans addfreespace (<= 0.1.3) permet à un attaquant de soumettre des requêtes qui ne sont pas protégées contre le CSRF. Si un utilisateur privilégié (administrateur ou autre rôle à privilèges élevés) est trompé pour visiter une page malveillante ou cliquer sur un lien malveillant, l'attaquant peut stocker des charges utiles JavaScript dans le site (XSS stocké).
• L'XSS stocké exécuté dans un contexte d'administrateur peut conduire à une prise de contrôle de compte, une élévation de privilèges, un vol de données ou l'installation de portes dérobées persistantes.
• Il n'y a pas de correctif officiel pour le plugin disponible au moment de la publication. Des mesures d'atténuation immédiates sont fortement conseillées.
• Actions immédiates recommandées : désactiver ou supprimer le plugin ; restreindre l'accès aux pages d'administration du plugin ; appliquer des règles WAF ou des correctifs virtuels ; scanner pour des scripts injectés et des modifications suspectes ; réinitialiser les identifiants administratifs et faire tourner les clés ; et mettre en œuvre un durcissement à long terme.
• Les utilisateurs de WP‑Firewall peuvent appliquer des correctifs virtuels, des règles WAF gérées et un scan actif pour réduire immédiatement le risque.

---

Pourquoi le CSRF enchaîné avec l'XSS stocké est dangereux (en termes humains)

CSRF et XSS sont des types d'attaques différents, mais lorsqu'ils sont combinés, ils deviennent puissants :

• CSRF : Un attaquant trompe un utilisateur connecté (souvent un administrateur) pour qu'il effectue une action qu'il n'avait pas l'intention de faire — par exemple, en les incitant à cliquer sur un lien ou à visiter une page web qui fait une requête vers le site vulnérable. Les actions administratives WordPress correctement codées incluent des vérifications de nonce et des vérifications de capacité pour prévenir cela. Dans ce cas, le plugin n'a pas réussi à valider correctement l'origine/le nonce.
• XSS stocké : Si un attaquant peut faire en sorte qu'un JavaScript arbitraire soit enregistré dans la base de données du site web (par exemple, dans une option de plugin ou un champ personnalisé), ce code s'exécutera chaque fois que le contenu stocké est affiché dans le contexte d'administration ou de frontend sans échappement approprié.

Chaînage : Un attaquant non authentifié crée une page qui soumet un POST/GET à l'endpoint du plugin vulnérable en arrière-plan ou lorsque un administrateur du site visite. Si le plugin stocke la charge utile JavaScript de l'attaquant (et l'affiche ensuite sans échappement), la charge utile s'exécute dans le contexte du navigateur de l'administrateur. De là, un attaquant peut voler des cookies d'authentification, effectuer des actions en tant que cet utilisateur (créer des publications, installer des plugins/thèmes, exporter des données) et établir un accès persistant.

Même si un attaquant a besoin que l'administrateur effectue une interaction (par exemple, cliquer sur un lien), ce seul clic peut être tout ce dont il a besoin pour pivoter vers un compromis complet.

---

Causes racines techniques (ce qui a mal tourné)

D'après les détails rapportés et les modèles d'exploitation typiques, la chaîne indique généralement les échecs suivants dans le code du plugin :

1. Protection CSRF manquante
   • Pas d'utilisation des nonces WordPress (par exemple, wp_create_nonce / check_admin_referer) pour les actions modifiant l'état.
   • Pas de validation de l'origine de la requête ou de l'en-tête referer pour s'assurer que la requête provient d'une interface admin de confiance.
2. Vérification des capacités insuffisante
   • Les points de terminaison du plugin peuvent ne pas avoir de vérifications appropriées des capacités utilisateur (current_user_can) ou appliquer la capacité appropriée pour la tâche.
3. Manque ou insuffisance de la désinfection des données et de l'échappement des sorties
   • Des données fournies par l'utilisateur dangereuses sont enregistrées dans la base de données sans désinfection (par exemple, en utilisant sanitize_text_field, wp_kses_post) et sont ensuite affichées sans échappement (par exemple, esc_html, esc_attr, ou filtrage kses approprié).
4. Interfaces administratives exposant des points de terminaison modifiables accessibles via des méthodes HTTP non authentifiées
   • Hooks d'action ou points de terminaison AJAX qui acceptent des requêtes POST sans protections appropriées.

Le résultat net : un attaquant peut déclencher un changement d'état (stockage de contenu) en utilisant le navigateur d'une victime, et le contenu stocké peut ensuite être rendu et exécuté.

---

Comment une attaque se déroulerait typiquement (niveau élevé)

1. L'attaquant identifie le point de terminaison du plugin vulnérable (par exemple, une URL d'action admin utilisée par addfreespace).
2. L'attaquant crée une page web qui effectue un POST (ou GET) vers ce point de terminaison avec une charge utile contenant du JavaScript (un vecteur XSS stocké). La soumission du formulaire inclut les paramètres attendus par le plugin.
3. Un administrateur (ou un autre utilisateur privilégié) visite la page malveillante ou clique sur un lien tout en étant authentifié sur le site WordPress vulnérable.
4. Parce que le plugin manque de protection CSRF, la requête est acceptée et le JavaScript malveillant est enregistré dans la base de données (par exemple, dans une option, des métadonnées de publication ou un champ contrôlé par le plugin).
5. Lorsque le site (ou la page admin) affiche plus tard cette valeur stockée sans désinfection/échappement, le JavaScript s'exécute dans le contexte du navigateur de l'admin.
6. Le JavaScript peut alors :
   • Lire les cookies ou le stockage local (et les exfiltrer) ;
   • Effectuer des requêtes authentifiées en utilisant les identifiants de l'admin (par exemple, créer de nouveaux utilisateurs admin, installer des plugins) ;
   • Chargez des scripts externes pour exécuter d'autres actions ou pour maintenir la persistance.

Note: L'étape clé est l'utilisateur privilégié effectuant une action (par exemple, visiter une page). Sans cette interaction, le CSRF ne peut normalement pas être déclenché. Cela dit, de nombreux administrateurs cliquent sur des liens ou ouvrent des pages, et les acteurs malveillants exploitent ce comportement à grande échelle.

---

Impact — ce que les attaquants peuvent réaliser

Le XSS stocké exécuté dans une session de navigateur administrative peut permettre :

• La prise de contrôle de compte (vol de cookies de session ou de jetons OAuth).
• La création de nouveaux utilisateurs administratifs.
• L'installation de portes dérobées (plugins/thèmes malveillants) ou de tâches planifiées qui maintiennent la persistance.
• L'exfiltration de données : exportation de publications, de médias ou de données utilisateur.
• La défiguration du site ou l'injection de logiciels malveillants drive-by pour infecter les visiteurs.
• Le pivotement vers le contrôle d'hébergement ou l'accès à la base de données via une exploitation supplémentaire.

Bien que le CVSS soit faible, l'impact commercial peut être sévère si l'attaquant parvient à maintenir la persistance ou à prendre le contrôle d'un site de production.

---

Actions immédiates que vous devez entreprendre (style réponse à incident)

Si vous gérez des sites WordPress utilisant addfreespace (<= 0.1.3), traitez la situation comme urgente :

1. Désactivez le plugin maintenant
   • Connectez-vous à wp-admin et désactivez addfreespace. Si vous ne pouvez pas accéder à wp-admin, renommez le dossier du plugin via SFTP/SSH (wp-content/plugins/addfreespace -> addfreespace.désactivé).
2. Supprimez le plugin
   • Si vous n'en avez pas strictement besoin, supprimez-le du code source. Parfois, supprimer le plugin est l'option la plus sûre à court terme jusqu'à ce qu'une version corrigée soit publiée.
3. Mettez le site en mode maintenance pendant que vous enquêtez
   • Réduisez la surface d'attaque pendant que vous scannez.
4. Appliquez immédiatement un WAF/patch virtuel.
   • Bloquez les requêtes vers les points de terminaison administratifs du plugin et refusez les POST suspects contenant des charges utiles ressemblant à des scripts.
   • Si vous utilisez WP‑Firewall, activez l'ensemble de règles WAF géré et le patch virtuel pour cette vulnérabilité afin de bloquer les tentatives d'exploitation même lorsque le plugin est présent.
5. Scannez les charges utiles injectées et les entrées DB suspectes.
   • Recherchez dans les articles, options, usermeta et autres stockages pour <script, onerror=, onload=, ou d'autres gestionnaires d'événements JS qui semblent inattendus.
   • Exemple (défensif, exécutez en tant qu'administrateur via WP‑CLI ou client de base de données) :
     • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
     • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
   • Note: Les requêtes exactes ci-dessus supposent des préfixes de table standard. Ajustez pour des préfixes personnalisés et la sécurité en production.
6. Rotation des identifiants et des secrets
   • Réinitialisez les mots de passe pour tous les utilisateurs administrateurs.
   • Faites tourner les clés API, les identifiants de compte de service et les clés dans wp-config.php si vous soupçonnez une compromission.
7. Examiner les comptes utilisateurs et les rôles
   • Recherchez des comptes administrateurs inattendus ou des utilisateurs avec des privilèges élevés.
8. Examinez les journaux du serveur et d'accès
   • Inspectez les journaux du serveur web et les pistes d'audit pour des POST ou des requêtes suspectes vers les points de terminaison du plugin.
9. Restaurez à partir d'une sauvegarde connue et bonne si vous détectez des changements que vous ne pouvez pas nettoyer en toute sécurité.
   • Si vous trouvez des portes dérobées ou des modifications inexpliquées, une restauration propre peut être la remédiation la plus rapide.
10. Renforcez l'accès administrateur
    • Appliquez l'authentification à 2 facteurs (2FA) pour tous les comptes privilégiés.
    • Limitez l'accès à la zone admin par IP si possible.
    • Utilisez des mots de passe forts et uniques ainsi qu'une politique de verrouillage de compte.

---

Comment détecter un XSS stocké à partir de cette vulnérabilité (indicateurs de compromission)

Recherchez les signes suivants :

• JavaScript inattendu dans les articles, pages, options ou contenu de widget.
• Nouveaux utilisateurs administrateurs ou changements inattendus dans les rôles des utilisateurs.
• Contenu de l'interface administrateur affichant des alertes étranges, des popups ou des redirections.
• Requêtes sortantes du site vers des domaines tiers inconnus (indiquant une exfiltration ou un rappel).
• Journaux du serveur montrant des POST vers des points de terminaison de plugin provenant de référents ou d'agents utilisateurs inhabituels.
• Utilisation élevée du CPU ou tâches cron planifiées de manière inattendue (indiquant des portes dérobées).

Vérifications défensives utiles :

• Recherche WP‑CLI pour des balises script dans les publications et options :
  • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'" --limit=100
  • wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%'" --limit=100
• Analyse avec un scanner de malware de confiance (côté site ou niveau hôte) pour détecter des portes dérobées et des webshells connus.
• Comparer les fichiers actuels avec un instantané propre ou les fichiers originaux distribués du plugin pour trouver des fichiers modifiés.

Lorsque vous trouvez un contenu suspect, isolez-le et ne l'exécutez pas dans un navigateur en direct. Traitez-le comme malveillant jusqu'à preuve du contraire.

---

Conseils de remédiation au niveau du code pour les développeurs

Si vous maintenez le plugin ou développez des thèmes/plugins, voici les pratiques de codage défensives essentielles à suivre pour prévenir à la fois le CSRF et le XSS stocké :

1. Utilisez des nonces et vérifiez-les à chaque requête modifiant l'état
   • Lors de la génération d'un formulaire ou d'un lien qui effectue un changement d'état :

     $nonce = wp_create_nonce( 'my_plugin_action' );

     Incluez-le dans les formulaires ou AJAX :

     <input type="hidden" name="_wpnonce" value="" />

   • Lors du traitement des requêtes :

     check_admin_referer( 'my_plugin_action' ); // ou check_ajax_referer pour AJAX

2. Vérifiez les capacités de l'utilisateur
   • Avant d'effectuer des actions, vérifiez :

     if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'Permissions insuffisantes' ); }

3. Assainir l'entrée avant de sauvegarder
   • Utilisez des assainisseurs appropriés :
     • sanitize_text_field(), sanitize_email(), intval(), floatval()
     • Pour l'entrée HTML : wp_kses_post() ou wp_kses() avec une liste autorisée sécurisée
4. Échappement à la sortie
   • Échappez toujours les données lors de l'impression :
     • esc_html(), esc_attr(), wp_kses_post() selon le contexte.
5. Utilisez l'API REST et vérifiez les rappels de permission
   • Pour les points de terminaison REST, implémentez permission_callback qui vérifie les capacités et les nonces.
6. Validez les types de données et les longueurs attendus
   • Appliquez des longueurs maximales et des caractères autorisés.

Exemple (pseudo-code défensif) :

// Dans le formulaire :
wp_nonce_field( 'my_plugin_save_settings', '_wpnonce', true );

// Dans le gestionnaire de soumission :
if ( ! current_user_can( 'manage_options' ) ) {;

Pour l'entrée HTML qui doit autoriser des balises limitées :

$allowed = array(;

---

WAF et patching virtuel — règles pratiques à déployer maintenant

Si vous avez un WAF (pare-feu d'application) tel que WP‑Firewall, vous pouvez créer des règles défensives qui bloquent les tentatives d'exploitation même avant qu'un correctif officiel du plugin ne soit publié. Considérez les approches de haut niveau suivantes :

1. Bloquez les contenus POST/GET suspects vers les points de terminaison du plugin
   • Créez une règle pour inspecter les requêtes ciblant les actions administratives du plugin ou les fichiers du plugin. Si le corps de la requête contient des balises script ou des gestionnaires d'événements XSS courants (onerror, onload, javascript :), bloquez la requête.
2. Imposer la présence du référent ou de l'origine pour les POST administratifs
   • Bloquez ou challengez (CAPTCHA) les POST vers wp-admin/admin-post.php, admin-ajax.php, ou des points de terminaison spécifiques au plugin qui n'incluent pas un référent valide ou un paramètre _wpnonce.
3. Limitez le taux et challengez les requêtes anonymes vers les points de terminaison administratifs
   • De nombreuses tentatives d'exploitation sont automatisées. La limitation de taux réduit les grandes attaques automatisées.
4. Patching virtuel : interceptez les modèles d'exploitation connus
   • Bloquez les requêtes correspondant aux noms de paramètres exacts ou aux modèles d'URL utilisés par le plugin vulnérable lorsqu'elles contiennent du contenu suspect.
5. Bloquez les requêtes qui tentent de créer/modifier des options avec du contenu script
   • Si une requête tente de mettre à jour wp_options ou des champs couramment utilisés par le plugin avec <script dans la charge utile, bloquez-la.

Exemple d'une règle de pare-feu conceptuelle (pseudo) :

SI request.path CORRESPOND À "/wp-admin/admin-post.php" OU "/wp-admin/*addfreespace*" ET request.method DANS (POST, GET) ALORS

Remarques :

• Évitez les règles trop larges qui pourraient entraîner des faux positifs. Testez d'abord en mode surveillance.
• Utilisez des règles combinées avec des journaux et des alertes afin de pouvoir vous adapter rapidement.

Si vous êtes un utilisateur de WP‑Firewall, activez l'ensemble de règles géré qui cible les modèles d'exploitation CSRF/XSS et activez le patching virtuel pour les vulnérabilités addfreespace. Cela fournit une protection immédiate pendant que vous suivez une remédiation à long terme.

---

Liste de contrôle post-remédiation (que faire après avoir supprimé le plugin ou appliqué un correctif)

1. Confirmez que le plugin est supprimé ou mis à jour vers une version corrigée lorsqu'elle est disponible.
2. Rescannez l'ensemble du site à la recherche de code malveillant, de webshells et de fichiers modifiés.
3. Examinez la base de données pour les charges utiles stockées et supprimez-les ou assainissez-les.
4. Faites tourner les identifiants : mots de passe administratifs, clés SSH, clés API.
5. Réémettez tous les jetons ou clés divulgués qui ont pu être exposés.
6. Restaurez une sauvegarde propre si vous ne pouvez pas garantir que le site est entièrement propre.
7. Surveillez les journaux et la détection d'intrusions pour des tentatives répétées.
8. Documentez l'incident, vos actions et les leçons apprises.

---

Comment communiquer aux clients et aux parties prenantes (si vous gérez d'autres sites)

• Bref et factuel : expliquez le plugin affecté, les versions, le niveau de risque et les actions que vous avez prises (désactivé/supprimé, scanné, règles WAF mises en œuvre).
• Fournissez des assurances : listez les atténuations exactes (règles WAF en place, scan terminé, identifiants tournés, sauvegardes utilisées).
• Fournissez des conseils : instruisez les utilisateurs finaux à changer leurs mots de passe s'ils se sont connectés pendant la période d'exposition, et à surveiller les activités suspectes.
• Offrez un suivi : planifiez un examen complet de la sécurité si des indicateurs de compromission sont trouvés.

---

Liste de contrôle de durcissement qui devrait être une pratique standard (prévenir des problèmes similaires)

• Appliquez l'authentification à deux facteurs pour chaque compte administratif.
• Limitez l'accès à la zone admin via une liste blanche d'IP lorsque cela est possible.
• Désactiver l'édition de fichiers dans wp-admin :

  définir( 'DISALLOW_FILE_EDIT', vrai );

• Appliquez le principe du moindre privilège : donnez aux utilisateurs uniquement les capacités dont ils ont absolument besoin.
• Maintenir le noyau de WordPress, les thèmes et les plugins à jour.
• Installez et exécutez un scanner de site réputé et un WAF géré.
• Utilisez des mots de passe forts et uniques et une politique de gestion des secrets centralisée.
• Sauvegardez quotidiennement (ou plus fréquemment) avec des sauvegardes immuables stockées hors site.
• Examinez le code du plugin avant d'installer des plugins d'auteurs inconnus ou d'articles à faible téléchargement.

---

Si vous trouvez du JavaScript suspect dans votre base de données — conseils de nettoyage sécurisés.

• Ne visitez pas les pages qui affichent le contenu suspect dans une session de navigateur administrateur avant de nettoyer.
• Exportez les lignes suspectes de la base de données vers une zone de quarantaine sécurisée et analysez-les hors ligne ou sur une machine isolée.
• Supprimez ou assainissez les entrées en utilisant des fonctions sûres (wp_update_post avec du contenu assaini, update_option avec du contenu assaini).
• Si vous n'êtes pas sûr de l'étendue de la compromission, restaurez à partir d'une sauvegarde propre vérifiée et réappliquez les correctifs et le durcissement.

---

Pourquoi un faible CVSS ne signifie pas “pas un gros problème”

L'exploitation automatisée de masse et l'ingénierie sociale reposent sur des étapes enchaînées et de faible complexité. Une vulnérabilité qui nécessite “seulement” qu'un administrateur clique sur un lien peut être extrêmement puissante lorsque les attaquants envoient des dizaines de milliers d'e-mails de phishing ou compromettent d'autres sites Web pour intégrer l'exploit. Les XSS stockés exécutés dans un contexte administrateur sont particulièrement sensibles. Traitez les vulnérabilités avec une évaluation des risques pratique : facilité d'exploitation, nombre de sites affectés et gain potentiel pour l'attaquant. Dans de nombreux cas, un correctif virtuel immédiat et la suppression de plugins sont prudents même pour des scores CVSS faibles.

---

Manuel de réponse rapide aux incidents (une page)

1. Désactivez le plugin (ou renommez le dossier du plugin).
2. Activez le mode maintenance et bloquez le trafic si nécessaire.
3. Activez les règles de WAF/correctif virtuel pour le plugin.
4. Scannez la base de données à la recherche de balises script et d'entrées suspectes ; mettez en quarantaine les éléments trouvés.
5. Scannez le système de fichiers à la recherche de fichiers modifiés et de webshells.
6. Faites tourner les mots de passe administratifs et les clés API.
7. Examinez les journaux et les comptes utilisateurs.
8. Restaurer à partir de sauvegardes propres si nécessaire.
9. Renforcez l'accès administrateur (2FA, liste blanche d'IP).
10. Réintroduisez le plugin uniquement lorsqu'il est corrigé et après un contrôle qualité complet.

---

Essayez le plan WP‑Firewall Basic (Gratuit) — Protection essentielle sans le prix.

Si vous recherchez une protection immédiate et pratique pendant que vous suivez les étapes ci-dessus, envisagez de vous inscrire au plan WP‑Firewall Basic (Gratuit). Il comprend des protections essentielles qui aident à bloquer les tentatives d'exploitation et à réduire rapidement votre exposition :

• Pare-feu géré et WAF pour bloquer les modèles d'exploitation connus
• Bande passante illimitée — le pare-feu ne limite pas votre trafic.
• Scanner de logiciels malveillants pour détecter les portes dérobées courantes et les charges utiles malveillantes.
• Atténuation des risques OWASP Top 10 pour réduire les vecteurs d'attaque courants.

Vous pouvez vous inscrire au plan gratuit et déployer ces protections rapidement à : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Derniers mots de l'équipe de sécurité de WP‑Firewall

Les vulnérabilités comme la chaîne addfreespace CSRF→stored‑XSS rappellent que même les petits plugins ou de niche peuvent introduire un risque démesuré. La bonne nouvelle : vous pouvez agir efficacement dès maintenant. Désactivez ou supprimez le plugin, appliquez des règles WAF et des correctifs virtuels, scannez les injections, faites tourner les identifiants et renforcez l'accès administratif. Si vous gérez plusieurs sites web (en tant qu'agence ou hébergeur), automatisez le scan et le patching virtuel pour réduire la fenêtre d'exposition sur tous les sites.

Nous nous engageons à aider les propriétaires de sites à réduire rapidement et en toute confiance le risque. Si vous avez besoin d'une assistance pratique, de chasse aux menaces ou de règles de patching virtuel sur mesure, WP‑Firewall est disponible pour soutenir le nettoyage et la défense à long terme.

Restez en sécurité et priorisez une atténuation rapide lorsqu'une vulnérabilité est divulguée — le temps entre la divulgation et l'exploitation active est souvent plus court que vous ne le pensez.

— Équipe de sécurité WP-Firewall

---

Annexe : Commandes de référence rapide (défensives)

• Recherchez des balises script dans les publications (ajustez le préfixe de la table si nécessaire) :

  Requête wp db "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' ;"

• Recherchez wp_options pour du contenu semblable à un script :

  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• Listez les fichiers récemment modifiés (derniers 7 jours) sur un hôte UNIX :

  find /path/to/wordpress -type f -mtime -7 -print

N'oubliez pas : exécutez ces commandes uniquement avec un accès approprié et des sauvegardes, et évitez d'exposer le site à un risque supplémentaire pendant l'enquête.