Ce que révèlent les analyses de CVE-2026-96367 et CVE-2026-96360
Les deux CVE ciblent le module Webform, l'un des modules Drupal les plus déployés pour la gestion de formulaires avancés. Les analyses publiées sur des forums spécialisés pointent deux classes de vulnérabilités distinctes.
CVE-2026-96367 — XSS stocké via les données soumises par un utilisateur non authentifié. Un contenu malveillant injecté dans un champ de formulaire peut être stocké en base de données et restitué sans assainissement suffisant dans l'interface d'administration ou dans les e-mails de notification. Le résultat : un script s'exécute dans le navigateur d'un administrateur, ouvrant la voie à une prise de contrôle de session ou à une escalade de privilèges.
CVE-2026-96360 — Attributs HTML inattendus sur les éléments de formulaire. Webform permet de définir des attributs HTML personnalisés sur les champs. Dans certaines configurations, des attributs non filtrés peuvent être injectés par un utilisateur autorisé à modifier un formulaire et persister dans le rendu final.
Ces deux vulnérabilités partagent un mécanisme commun : la confiance implicite accordée aux données provenant du formulaire ou de la configuration du formulaire, sans vérification systématique à la sortie.
Les surfaces d'attaque spécifiques à Webform
1. Le stockage
Webform peut enregistrer les soumissions en base de données. Cette fonctionnalité est pratique, mais elle fait de chaque soumission une donnée persistante, potentiellement réaffichée dans des contextes variés. La faille XSS stockée prend racine ici : si les données sont stockées sans encodage et restituées sans filtre dans un contexte HTML, le contenu malveillant survit à la soumission.
2. Le rendu
Drupal dispose d'un système de rendu robuste, mais certains cas aux limites — champs personnalisés, templates surchargés, tokens Webform dans des zones de texte filtré — peuvent court-circuiter les protections standard. Un template Twig surchargé qui affiche {{ submission.value }} sans |escape ou sans la couche de rendu Drupal est une porte d'entrée.
3. Les attributs personnalisés
C'est la surface exposée par CVE-2026-96360. Quand les attributs HTML supplémentaires ne sont pas passés au travers d'une liste blanche stricte, un utilisateur avec les droits de modification de formulaire peut injecter du contenu arbitraire dans le HTML rendu.
Ce qu'un décideur peut faire immédiatement
- Vérifier la version de Webform — la version du module doit être alignée avec les recommandations publiées par l'équipe sécurité Drupal.
- Auditer les soumissions stockées — cherchez des patterns caractéristiques d'injection XSS dans les enregistrements existants.
- Passer en revue les attributs personnalisés — pour chaque formulaire en production, listez les éléments qui utilisent des attributs HTML supplémentaires et vérifiez leur origine.
- Restreindre les droits de modification des formulaires — le principe du moindre privilège s'applique ici. La modification d'un formulaire critique doit être réservée à un rôle clairement identifié.
- Activer la Content Security Policy — une CSP bien configurée réduit significativement l'impact d'un XSS en empêchant l'exécution de scripts injectés.
Mettre en place une hygiène continue
Surveillance des attributs inattendus
Mettez en place une surveillance périodique des configurations Webform. La gestion de configuration Drupal versionnée sous Git est votre alliée : un attribut data-x="javascript:..." dans un diff de configuration doit déclencher une alerte, pas passer inaperçu.
Journalisation des soumissions à risque
Les WAF et les modules de journalisation Drupal peuvent être configurés pour alerter sur des patterns d'injection dans les soumissions de formulaires. Ce n'est pas un remplacement du patch, mais un filet de détection.
Revues de sécurité régulières
Planifiez des revues de configuration de sécurité à intervalle fixe — au minimum avant chaque mise en production majeure et après chaque ajout de formulaire critique.
Gouvernance : rôles, processus et jeu d'essai sécurité
Pour chaque formulaire critique, identifiez explicitement : qui peut créer ou modifier le formulaire, qui peut consulter les soumissions, qui valide les changements de configuration avant mise en production. Ces distinctions doivent se traduire dans la configuration des permissions Drupal.
Un changement sur un formulaire Webform doit suivre le même circuit qu'un changement de code : branche dédiée, revue, déploiement via la gestion de configuration. Un formulaire modifié directement en production sans passer par Git est une dette opérationnelle — et un risque.
Construisez un jeu d'essai minimal reproductible après chaque mise à jour Webform, couvrant les injections XSS typiques dans les champs texte, et vérifiez que ni l'interface d'administration ni les notifications e-mail n'exécutent de script.
La mise à jour est nécessaire. La sécurité durable demande plus.
Ces deux CVE illustrent une tension structurelle dans l'exploitation d'un module aussi puissant que Webform : la flexibilité qu'il offre est exactement ce qui crée des surfaces d'attaque si elle n'est pas encadrée. Ce qui fait la différence entre une organisation qui subit les alertes de sécurité et une organisation qui les absorbe sans incident, c'est la rigueur des processus autour du module : qui peut faire quoi, ce qui est surveillé, ce qui est testé avant chaque déploiement.