| Nom du plugin | Code d'en-tête et de pied de page AddFunc |
|---|---|
| Type de vulnérabilité | Scripts intersites (XSS) |
| Numéro CVE | CVE-2026-2305 |
| Urgence | Faible |
| Date de publication du CVE | 2026-04-10 |
| URL source | CVE-2026-2305 |
Plugin Code d'en-tête et de pied de page AddFunc XSS (CVE-2026-2305) : Ce que les propriétaires de sites WordPress doivent savoir — et comment WPFirewall vous protège
Date : 10 avril 2026
Gravité (liste Patchstack) : Faible (CVSS 6.5)
Versions affectées : <= 2.3
Corrigé dans : 2.4
Privilège requis : Contributeur (authentifié)
Une divulgation récente (CVE-2026-2305) décrit une vulnérabilité de script intersite stocké (XSS) authentifiée dans le plugin Code d'en-tête et de pied de page AddFunc pour WordPress (versions jusqu'à 2.3). Cette vulnérabilité permet à un utilisateur ayant un accès de niveau Contributeur d'injecter des charges utiles de type script via des champs personnalisés qui peuvent ensuite être rendus non assainis — produisant un XSS stocké sur des pages ou des écrans d'administration où ces champs sont affichés.
En tant qu'équipe derrière WPFirewall (un fournisseur de sécurité WordPress et de WAF géré), je souhaite vous donner une analyse lisible et pratique du risque, des scénarios d'attaque réalistes, des étapes de détection et de nettoyage, et des protections en couches que vous devriez appliquer immédiatement. Je vais également expliquer comment nos capacités de pare-feu vous protègent (y compris le patching virtuel et les signatures WAF), et fournir des conseils concrets et sûrs en matière de code et de configuration pour les développeurs et les administrateurs de sites.
Ceci est écrit du point de vue d'un praticien de la sécurité WordPress — pratique, sans fioritures, avec des étapes reproductibles que vous pouvez utiliser dès aujourd'hui.
Résumé exécutif — ce qui s'est passé et pourquoi cela compte
- Le plugin Code d'en-tête et de pied de page AddFunc (versions <= 2.3) permettait au contenu fourni par l'utilisateur à partir des champs personnalisés des publications d'être inclus dans la sortie sans assainissement/échappement suffisant.
- Un utilisateur authentifié avec des privilèges de Contributeur (capable d'ajouter ou de modifier des publications et des champs personnalisés) pouvait enregistrer une charge utile contenant des balises de script ou des gestionnaires d'événements.
- Lorsque ce contenu est ensuite rendu sur le front-end ou dans une page d'administration sans échappement approprié, le script stocké s'exécute dans le navigateur du visiteur ou de l'administrateur.
- L'impact dépend de l'endroit où le champ est rendu :
- Si la charge utile s'exécute sur le front-end (pages publiques), les visiteurs du site peuvent être affectés (redirections malveillantes, faux formulaires, cryptomineurs, injection de contenu).
- Si la charge utile s'exécute dans les pages d'administration (par exemple, lorsqu'un éditeur ou un administrateur ouvre la publication dans le tableau de bord), des utilisateurs de privilège supérieur peuvent être ciblés, entraînant une prise de contrôle du site : détournement de compte, installation de plugins/thèmes, modifications des paramètres ou installation de portes dérobées.
- Le plugin a été corrigé dans la version 2.4. L'action correcte immédiate pour les sites affectés est de mettre à jour vers 2.4 ou une version ultérieure.
Pourquoi un Contributeur peut être dangereux — modèle de menace du monde réel
De nombreux propriétaires de sites pensent que les utilisateurs de niveau Contributeur présentent un faible risque car ils ne peuvent pas publier de contenu. Bien que cela soit une conception valide pour la gestion de contenu, les contributeurs peuvent généralement créer des publications, modifier leurs propres brouillons et ajouter des champs personnalisés (selon la configuration du site). Le XSS stocké via des champs personnalisés est particulièrement dangereux car :
- Le contenu malveillant est persistant — il est stocké dans la base de données et se déclenchera chaque fois qu'il sera rendu.
- Si le site ou le thème imprime des champs personnalisés dans les pages d'administration (aperçus de publications, boîtes méta) ou dans les pages front-end sans échapper, les scripts s'exécutent avec les privilèges de l'utilisateur visualisant dans son navigateur.
- Les attaquants peuvent créer des charges utiles qui effectuent des actions au nom d'un administrateur (changer des mots de passe, créer des comptes administrateurs, installer des plugins) en exploitant la session authentifiée de l'administrateur et des requêtes falsifiées (CSRF combiné avec XSS).
En résumé : les contributions des utilisateurs en qui vous aviez confiance pour le contenu peuvent être exploitées pour compromettre le site si la désinfection/l'échappement est manquante.
Flux d'exploitation typique (niveau élevé, non exploitable)
- L'attaquant s'inscrit ou utilise un compte avec des privilèges de contributeur (ou en compromet un).
- L'attaquant édite un brouillon ou crée une publication et ajoute du contenu malveillant dans un champ personnalisé (par exemple,
<script>…</script>ou des charges utiles basées sur des attributs commeonerror=…à l'intérieur d'une balise autorisée). - Le site stocke ce contenu dans postmeta.
- Lorsque la publication est chargée dans un contexte où le plugin ou le thème affiche ce champ personnalisé sans désinfection (page front-end, aperçu admin ou boîte méta), le navigateur exécute le code injecté.
- Si un administrateur consulte la page ou la publication affectée dans l'interface d'administration (ou si des visiteurs sont ciblés), le script injecté peut :
- Voler les cookies de l'administrateur (s'ils ne sont pas HttpOnly — bien que les meilleures pratiques modernes réduisent le vol de cookies mais tous les sites ne les suivent pas),
- Utiliser les privilèges d'administrateur pour créer un nouveau compte administrateur via l'API REST / les points de terminaison admin,
- Modifier les fichiers ou les paramètres des plugins/thèmes,
- Installer une porte dérobée ou persister davantage de logiciels malveillants,
- Exfiltrer des données.
Parce que l'exploitation nécessite souvent qu'un administrateur interagisse (visualise la publication dans l'admin ou clique sur un lien d'aperçu spécifique), Patchstack indique “Interaction utilisateur requise”, mais cette interaction peut être aussi simple que d'ouvrir l'éditeur de publication ou un lien d'aperçu conçu.
Étapes pratiques pour protéger votre site — actions immédiates (liste de contrôle)
- Mettre à jour le plugin
– Si vous utilisez AddFunc Head & Footer Code, mettez à jour vers la version 2.4 ou ultérieure immédiatement. C'est la remédiation canonique. - Si vous ne pouvez pas mettre à jour immédiatement
– Supprimez ou désactivez temporairement le plugin.
– Bloquez les comptes contributeurs de l'édition ou de l'ajout de champs personnalisés jusqu'à ce que le plugin soit mis à jour.
– Appliquez un patch virtuel au niveau du WAF (voir les conseils WAF ci-dessous). - Scannez à la recherche de contenu malveillant dans les champs personnalisés
– Utilisez WPCLI ou des requêtes DB directes pour trouver des valeurs méta contenant<script,onerror=,JavaScript :, ou du HTML suspect.
– Exemple (sauvegardez d'abord votre DB) :
wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
– Recherchez égalementonerror=,onload=,JavaScript :modèles.
– Examinez les entrées et supprimez ou assainissez les valeurs méta suspectes. - Audit des comptes d'utilisateurs
– Vérifiez tous les contributeurs et éditeurs : sont-ils légitimes ? Supprimez les comptes obsolètes ou suspects.
– Appliquez des mots de passe forts et l'authentification à deux facteurs pour les rôles privilégiés (Éditeur, Administrateur). - Vérifier les signes de compromission
– Recherchez des comptes administrateurs inconnus, des fichiers de plugin/thème inattendus, des fichiers récemment modifiés, des tâches planifiées et des connexions sortantes depuis le serveur.
– Exécutez un scan de malware (scanner de WPFirewall ou autre scanner réputé). - Faites tourner les identifiants et les clés API si une compromission est suspectée
– Changez les mots de passe administrateurs et toutes les clés API exposées.
– Invalidez les sessions si nécessaire (déconnexion forcée pour tous les utilisateurs). - Sauvegarde avant nettoyage
– Prenez une sauvegarde complète du site (fichiers et DB) avant la remédiation. Cela préserve les preuves et vous donne un point de retour. - Renforcez les champs personnalisés à l'avenir
– Exigez l'assainissement lors de l'enregistrement et l'échappement lors de la sortie — voir les recommandations de code ci-dessous.
1. Comment trouver des entrées XSS stockées malveillantes en toute sécurité
2. La recherche de contenu suspect dans la base de données est cruciale mais doit être effectuée avec prudence :
- 3. Créez toujours une sauvegarde avant d'exécuter des requêtes ou d'apporter des modifications.
- 4. Commencez par des requêtes en lecture seule pour identifier les entrées suspectes, puis examinez-les manuellement.
- 5. Exemples de requêtes de détection WPCLI :
6. # Trouver des postmeta qui contiennent <script"
wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';".
# Rechercher des gestionnaires d'événements en ligne
wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%onerror=%' OR meta_value LIKE '%onload=%';"
- 7. Exportez les valeurs méta suspectes et inspectez-les, puis décidez de les assainir ou de les supprimer.
5.8. Nettoyage des entrées suspectes. - 9. Si vous identifiez des valeurs méta malveillantes :
10. Si l'entrée est manifestement malveillante (blocs complets), supprimez la ligne méta.
11. Si l'entrée contient des données utiles mais aussi des balises injectées, assainissez le contenu :.
12. <?php
// Exemple : assainir une valeur de champ personnalisé sauvegardée
- $clean = wp_kses(
- $raw_meta_value,
array( // autoriser uniquement un ensemble restrictif de balises/attributs
- 'a' => array( 'href' => true, 'title' => true, 'rel' => true ),
<?php
- À la sortie, échappez toujours en fonction du contexte :
<?php
- Meilleur modèle : enregistrer la méta avec un rappel d'assainissement (fonctionne bien avec REST) :
<?php
- Vérifiez toujours la capacité avant de sauvegarder ou de rendre la méta réservée à l'administrateur. Utilisez des nonces pour les formulaires d'administration.
WAF et patching virtuel — protection immédiate au niveau du réseau
Lorsqu'une vulnérabilité de plugin existe et qu'une mise à jour immédiate n'est pas possible, un pare-feu d'application Web (WAF) bien configuré fournit un patching virtuel. Le patching virtuel signifie intercepter les requêtes malveillantes et les bloquer avant qu'elles n'atteignent le chemin de code vulnérable.
Les atténuations WAF typiques pour ce type de XSS stocké incluent :
- Bloquer les requêtes POST qui incluent des charges utiles de script suspectes dans des noms de champs méta connus (par exemple, contenus postmeta,
_personnalisé_*). - Bloquer ou assainir les requêtes qui contiennent
5.balises, attributs de gestionnaire d'événements (onerror=,onload=),JavaScript :URI, contenu de script encodé en base64, ou motifs d'obfuscation évidents. - Limiter le taux des POST qui créent ou mettent à jour des publications par des utilisateurs à faibles privilèges.
- Bloquer les signatures d'exploit connues et les encodages de charge utile.
Exemple de pseudo-règle (pour un moteur WAF générique) — conceptuel uniquement :
# Règle WAF en pseudocode : bloquer les balises de script dans les champs postmeta'
Si vous exécutez un WAF basé sur l'hôte ou un WAF cloud, configurez une règle qui inspecte le corps de la requête pour ces motifs et les bloque pour les utilisateurs avec des privilèges de Contributeur/Auteur. Cela fournit une atténuation immédiate pendant que vous mettez à jour.
Chez WPFirewall, nous fournissons des règles de patching virtuel ciblées qui détectent et bloquent les motifs utilisés dans les tentatives de XSS stockées, combinées à une surveillance et une notification lorsqu'une tentative bloquée s'est produite.
Exemples de règles WAF — style ModSecurity (exemple, ajustez pour votre environnement)
Ci-dessous se trouvent des modèles d'exemple à utiliser comme point de départ. Ceux-ci sont illustratifs — testez soigneusement pour éviter les faux positifs :
Exemple de règle ModSecurity # pour détecter les balises dans le corps POST"
Exemple de règle # pour détecter des attributs d'événement comme onerror= ou onload="
Important : testez toujours les règles dans un environnement de staging pour identifier les cas limites légitimes (certains contenus légitimes peuvent inclure du HTML autorisé) et ajustez les règles en conséquence.
Détection — journaux et indicateurs d'exploitation
Si vous soupçonnez qu'une exploitation a eu lieu :
- Vérifiez les journaux d'accès du serveur pour les POST qui créent ou modifient des posts (POST vers /wp-admin/post.php, /wp-json/wp/v2/posts).
- Vérifiez les journaux d'application (si vous en avez) pour des paramètres POST suspects.
- Recherchez des alertes de votre scanner de malware montrant des fichiers de plugin/thème modifiés, des fichiers inconnus ou des webshells.
- Vérifiez la liste des utilisateurs administrateurs pour des comptes administrateurs nouvellement créés.
- Recherchez des connexions sortantes de votre serveur vers des hôtes inconnus.
- Passez en revue les tâches cron récentes et les tâches planifiées pour des exécutions PHP inconnues.
Si vous trouvez du contenu injecté dans postmeta, traitez-le comme une compromission potentielle : effectuez une réponse complète à l'incident (quarantaine, instantané judiciaire, restauration à partir d'une sauvegarde propre si nécessaire).
Après une infection — remédiation et durcissement
Si vous trouvez des preuves que le site a été compromis :
- Isoler mettez le site hors ligne (déconnectez-le ou bloquez l'accès entrant) pendant l'enquête.
- Préserver les preuves: prenez un instantané complet, conservez les journaux (serveur web, base de données).
- Identifiez les mécanismes de persistance: vérifiez les utilisateurs administrateurs ajoutés, le fichier wp-config.php modifié, les fichiers de base remplacés, les plugins/thèmes malveillants, les tâches cron, les événements planifiés.
- Nettoyer: supprimer les fichiers malveillants et les entrées de base de données. En cas de doute, restaurer à partir d'une sauvegarde propre.
- Modifier les identifiants: réinitialiser tous les mots de passe, révoquer les clés API, faire tourner les clés SSH.
- Patch: mettre à jour le cœur de WordPress, les plugins et les thèmes vers les dernières versions.
- Renforcer: restreindre les permissions de fichiers, désactiver l'édition de fichiers via wp-config.php (
define('DISALLOW_FILE_EDIT', true)), appliquer l'authentification à deux facteurs pour tous les administrateurs, revoir le principe du moindre privilège pour tous les comptes. - Moniteur: activer la surveillance de la sécurité, la surveillance de l'intégrité des fichiers et les alertes pour les événements critiques.
Contrôles à long terme — réduire le risque d'abus de rôle et de HTML non fiable
- Minimiser le nombre de comptes pouvant éditer du contenu ; appliquer le moindre privilège.
- Exiger des flux de travail d'approbation pour le contenu soumis par les utilisateurs lorsque cela est possible (révision avant publication).
- Restreindre quels rôles peuvent ajouter des champs personnalisés ou utiliser des plugins qui exposent le rendu des champs personnalisés.
- Éduquer les contributeurs sur les risques d'incorporation de HTML dans les champs.
- Utiliser des en-têtes de politique de sécurité du contenu (CSP) pour limiter l'impact des scripts injectés (cela peut réduire la portée de certaines attaques XSS).
- Pour les sites avec de nombreux contributeurs, activer une séparation de rôle plus stricte et envisager des plugins de flux de modération.
Comment un WAF de confiance + une sécurité gérée réduisent le temps de remédiation
Un WAF géré et un service de sécurité fournissent :
- Patching virtuel rapide : bloquer immédiatement les tentatives d'exploitation sans avoir besoin de modifier le code de l'application.
- Mises à jour de signatures au fur et à mesure que la recherche est publiée afin que les règles capturent les charges utiles émergentes.
- Outils de scan et de suppression de logiciels malveillants pour trouver et remédier au contenu injecté.
- Surveillance et alertes afin que vous n'ayez pas à surveiller les journaux 24/7.
- Conseils lors de la réponse aux incidents et assistance pour le retour en arrière si nécessaire.
WPFirewall combine ces capacités avec une logique spécialisée pour WordPress (modèles de requêtes, points de terminaison REST, points de terminaison administratifs) afin que nous puissions détecter et atténuer les attaques ciblant des vecteurs WordPress courants comme le XSS stocké dans les métadonnées.
Notes pratiques de réglage du WAF (réduire les faux positifs)
- Exclure les IPs d'administrateurs de confiance du blocage agressif peut prévenir les interruptions de flux de travail administratifs — mais il faut équilibrer cela avec le risque de sécurité.
- Utilisez des règles qui correspondent aux noms de paramètres couramment utilisés pour les champs de métadonnées (meta[], postmeta, acf, champs personnalisés) plutôt que de bloquer tous
5.les tags globalement. - Journalisez les requêtes suspectes mais pas clairement malveillantes (mode alerte uniquement) pendant une période avant de bloquer — cela aide à ajuster les signatures aux modèles d'utilisation de votre site.
Exemple de plan d'intervention en cas d'incident (concise)
- Mettez à jour le plugin vers 2.4 (si possible).
- Si la mise à jour immédiate est impossible : activez la règle de patch virtuel qui inspecte les corps POST pour des scripts et des attributs d'événements ciblant les paramètres postmeta.
- Exécutez une requête DB pour trouver des valeurs de métadonnées suspectes ; exportez les résultats pour révision.
- Supprimez les entrées malveillantes confirmées et assainissez celles ambiguës.
- Réinitialisez les mots de passe pour tous les administrateurs ; appliquez la 2FA.
- Scannez le système de fichiers pour des fichiers modifiés et des fichiers PHP inconnus.
- Restaurez à partir d'une sauvegarde propre si la remédiation est incertaine.
- Surveillez les journaux pour des tentatives répétées ; bloquez les IPs fautives.
Recommandations conviviales pour les développeurs pour éliminer cette classe de bogue
- Toujours assainir lors de l'enregistrement et échapper lors de la sortie.
- Utilisez les API WordPress : register_post_meta avec des rappels d'assainissement, sanitize_text_field, wp_kses_post, esc_html, esc_attr.
- Utilisez des nonces et des vérifications de capacité pour toute opération d'enregistrement côté administrateur.
- Évitez de stocker du HTML brut sauf si absolument nécessaire ; si vous le faites, contraignez les tags et attributs autorisés avec wp_kses.
- Intégrez la sécurité dans le pipeline CI/CD : analyse statique, vérifications des dépendances et revues de sécurité avant les publications de plugins/thèmes.
Comment vérifier que votre site n'est plus vulnérable
- Assurez-vous que le code AddFunc Head & Footer est mis à jour vers 2.4 ou une version ultérieure.
- Vérifiez qu'il n'y a pas d'entrées postmeta avec
5.ou des attributs d'événement qui pourraient être exécutés. - Confirmez que les pages front-end et admin du site échappent la sortie des champs personnalisés.
- Vérifiez vos journaux WAF pour les tentatives bloquées et assurez-vous que vous avez activé la journalisation/l'alerte.
- Effectuez une analyse complète des logiciels malveillants et vérifiez l'intégrité des fichiers.
Commencez avec la protection gratuite de WPFirewall
Protéger votre site WordPress ne devrait pas être compliqué. Si vous souhaitez une protection de base immédiate pendant que vous examinez les mises à jour des plugins et nettoyez tout contenu suspect, envisagez de vous inscrire au plan de base gratuit de WPFirewall. Le plan gratuit comprend un pare-feu géré activement, une bande passante illimitée, un WAF, un scanner de logiciels malveillants et une couverture de mitigation pour les risques OWASP Top 10 — suffisamment pour bloquer de nombreuses tentatives d'exploitation courantes et donner à votre équipe le temps de mettre en œuvre des corrections en toute sécurité. Essayez WPFirewall Basic gratuitement ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Si vous souhaitez une suppression automatique des logiciels malveillants et un contrôle plus avancé comme les listes noires d'IP, nos plans payants ajoutent ces fonctionnalités à un coût annuel modeste.)
Recommandations finales — liste d'actions prioritaires (courte)
- Mettez à jour le code AddFunc Head & Footer vers 2.4+ maintenant.
- Si vous ne pouvez pas mettre à jour immédiatement, bloquez ou désactivez le plugin et appliquez les règles de patch virtuel WAF.
- Analysez et supprimez les entrées de champs personnalisés malveillants.
- Auditez les utilisateurs et appliquez des mots de passe/2FA pour les comptes privilégiés.
- Renforcez la désinfection au moment de l'enregistrement et l'échappement au moment de la sortie pour les champs personnalisés.
- Utilisez WPFirewall ou un WAF géré pour obtenir une protection et une surveillance immédiates.
Réflexions finales
Cette vulnérabilité rappelle que même des rôles apparemment à faible privilège et de petits plugins peuvent présenter un risque disproportionné si les données sont stockées et ensuite rendues sans désinfection et échappement appropriés. WordPress est flexible, ce qui est sa plus grande force — et aussi sa source de risque la plus fréquente lorsque le code suppose une confiance là où elle n'existe pas.
Appliquez la mise à jour, analysez et supprimez les valeurs meta suspectes, et placez un WAF devant votre site — non pas comme un substitut permanent à un code sûr, mais comme un contrôle compensatoire essentiel qui vous donne du temps pendant que vous corrigez la cause profonde. Si vous avez besoin d'aide pour mettre en œuvre des règles WAF, un patch virtuel ou un nettoyage post-incident, l'équipe de WPFirewall se spécialise dans une mitigation rapide, consciente de WordPress.
Si vous souhaitez un audit étape par étape ou de l'aide, contactez votre fournisseur de sécurité ou appuyez-vous sur le plan gratuit de WPFirewall pour obtenir une protection de base immédiate pendant que vous remédiez.
Restez en sécurité et considérez les champs personnalisés comme des entrées non fiables — assainissez, échappez et examinez.
— Équipe de sécurité WP-Firewall
