Ce que l'équipe sécurité de Drupal a publié le 23 septembre 2026
Le mercredi 23 septembre 2026, la Drupal Security Team a publié 36 avis de sécurité couvrant 16 projets contribués. Vingt d'entre eux concernent un seul module : Webform, la solution de formulaires la plus utilisée de l'écosystème, installée sur plus de 331 000 sites selon drupal.org.
Deux versions correctives sont sorties le même jour, et chacune regroupe l'ensemble des correctifs :
- Webform 6.3.1, pour les sites en Drupal 10.3 ou Drupal 11.
- Webform 6.2.12, pour la branche compatible Drupal 10.2, maintenue jusqu'à la fin de vie de Drupal 10.
La liste des vulnérabilités couvre l'accès aux soumissions, les fichiers téléversés, les exports temporaires, les imports distants, le rendu des valeurs, ainsi que des fonctionnalités annexes comme Webform Share, JSON:API ou Entity Print. Seize avis sont classés modérément critiques, trois peu critiques, et un seul critique.
Autrement dit : un audit de fond sur un module mature, dont chaque point relevé a reçu son propre avis public, son propre identifiant et sa propre description. C'est laborieux à lire, et c'est précisément ce qu'on attend d'un traitement sérieux.
L'alerte Webform du 23 septembre en quatre chiffres
36
avis de sécurité publiés le 23 septembre 2026, sur 16 projets contribués
20
avis pour le seul module Webform, dont un critique
18/25
score de risque de la faille d'exécution de code à distance SA-CONTRIB-2026-175
331 000
sites déclarant utiliser Webform, tous corrigeables le jour même
La faille critique SA-CONTRIB-2026-175 en détail
Un seul des vingt avis est classé critique : SA-CONTRIB-2026-175, référencé CVE-2026-96355, avec un score de 18 sur 25.
Le mécanisme
Webform ne filtrait pas suffisamment certains formats d'affichage lors du remplacement des jetons. Conséquence : une donnée saisie dans un formulaire pouvait être interprétée comme du code de gabarit au moment où la soumission est affichée. Selon la configuration du site, cela ouvre la voie à une divulgation d'informations, à une injection de code JavaScript persistante, ou à une exécution de code à distance sur le serveur.
Les conditions d'exploitation
C'est le point que les titres alarmistes omettent. Pour être vulnérable, un site doit remplir des conditions cumulatives :
- Le formulaire concerné doit utiliser un format personnalisé d'affichage des éléments à valeurs multiples.
- Ce format doit contenir des jetons reprenant les valeurs saisies par l'internaute.
- La portée réelle de l'impact dépend ensuite des modules activés et des réglages du site.
L'avis qualifie d'ailleurs l'exploitation de « théorique » et la configuration affectée de « peu courante ». À l'inverse, l'accès ne demande aucune authentification et la complexité d'attaque est jugée basique : une fois la configuration réunie, rien ne protège le site. D'où le classement critique, malgré la rareté du cas.
La lecture à faire en tant que responsable de site
Le score de 18/25 mesure un risque générique, pas votre risque. La bonne démarche n'est pas de paniquer sur le mot « RCE », mais de vérifier deux choses : la version de Webform installée, et l'existence de formats d'affichage personnalisés sur vos formulaires. Dans tous les cas, la réponse est la même : appliquer 6.3.1 ou 6.2.12, disponibles depuis le jour de l'annonce.
Pourquoi vingt avis pour un module ne sont pas un mauvais signe
Un observateur pressé conclura que Webform est un module fragile. C'est le contraire : ces vingt avis sont le produit d'une revue de sécurité approfondie, et leur publication simultanée suit un processus de divulgation coordonnée.
Trois éléments méritent d'être regardés de près :
- Rien n'a été publié avant le correctif. Les failles ont été signalées en privé à l'équipe sécurité, corrigées par les mainteneurs, puis annoncées le jour où les versions corrigées étaient téléchargeables. Le temps d'exposition publique est nul.
- Un avis par vulnérabilité. Il aurait été plus flatteur de publier une note unique intitulée « diverses corrections de sécurité ». La Drupal Security Team documente chaque vecteur, avec son score, ses conditions et son périmètre. C'est ce qui permet à une agence de décider en connaissance de cause.
- Les deux branches maintenues sont corrigées. Les sites restés en 6.2.x, compatibles Drupal 10.2, n'ont pas été laissés de côté au motif qu'une version plus récente existe.
Cette alerte suit de deux semaines celle du 9 septembre, qui avait touché 11 avis sur le module SAML SSO. Le rythme de publication reste hebdomadaire et prévisible, le mercredi, ce qui permet d'organiser la veille plutôt que de la subir.
Le parallèle WordPress : mêmes failles, autre traitement
La comparaison est instructive, à condition d'être honnête : l'écosystème WordPress est bien plus vaste, donc mécaniquement plus exposé, et son équipe de sécurité corrige elle aussi rapidement le cœur. La différence tient moins à la vitesse de correction qu'à la couverture et à la lisibilité de l'information.
L'été et la rentrée 2026 ont vu se succéder plusieurs failles majeures, dont une série sur des extensions de formulaires, exactement le même terrain que Webform :
- Forminator Forms : téléversement de fichier arbitraire non authentifié, CVE-2026-15748, CVSS 9.8, corrigé en version 1.56.2 le 31 juillet 2026. Environ 300 000 sites exécutaient encore une version vulnérable à la mi-août.
- Everest Forms : CVE-2026-19598, CVSS 9.8, plus de 100 000 sites exposés à une prise de contrôle complète.
- All-in-One WP Migration : injection SQL de second ordre non authentifiée, CVE-2026-19949, plus de 5 millions d'installations actives, corrigée en 7.110.
- The Events Calendar : deux vulnérabilités critiques reconnues le 24 août 2026, plus de 600 000 installations concernées, correctif publié en 6.17.4.1.
- Le cœur de WordPress : traversée de répertoire non authentifiée, CVE-2026-87902, CVSS 9.2, corrigée le 22 septembre 2026 et rétroportée jusqu'à la branche 4.7.
Deux écarts structurels expliquent l'inquiétude des exploitants de sites WordPress, et ils ne tiennent pas à la qualité du code :
- La couverture des extensions. Sur drupal.org, un module ayant une version stable est couvert par la politique d'avis de sécurité, et l'équipe sécurité intervient sur le projet. Sur WordPress, la sécurité d'une extension dépend d'abord de son éditeur ; l'information passe souvent par des acteurs tiers comme Patchstack ou Wordfence, avec des délais et des formats variables.
- La visibilité du risque résiduel. Un correctif publié ne protège personne tant qu'il n'est pas installé : 300 000 sites Forminator encore vulnérables deux semaines après le correctif le rappellent. C'est vrai pour les deux CMS, et c'est la vraie ligne de partage entre un site sûr et un site vulnérable.
La couverture ne vaut que pour les versions stables. Un module installé en version alpha, bêta ou dev ne bénéficie d'aucun avis de sécurité public, même s'il est vulnérable. Un site qui utilisait Webform 6.3.0-beta7 n'a reçu aucune alerte dédiée : il devait suivre la publication de la 6.3.1. Vérifier qu'aucune dépendance de production n'est restée sur une version instable fait partie du travail de maintenance.
Notre process : du bulletin de sécurité au site corrigé
Chez Akabia, la veille n'est pas un service à part : elle déclenche une chaîne outillée, identique pour tous les sites sous contrat de maintenance. Le mercredi, jour de publication des avis, la question n'est pas « y a-t-il des failles » mais « lesquels de nos sites sont concernés, et dans quelle version ».
1. Identifier les sites réellement concernés
Le croisement se fait sur le composer.lock de chaque projet, pas sur une impression générale.
# Verifier si le projet est vulnerable, avis de securite a l'appui
composer audit
# Version exacte du module en production
composer show drupal/webform | head -32. Appliquer le correctif de façon ciblée
Une mise à jour de sécurité ne se confond jamais avec une montée de version générale : on ne met à jour que le module concerné et ses dépendances, pour que la recette reste courte et le risque de régression limité.
# Correctif cible, sur une branche dediee
git checkout -b security/webform-sa-contrib-2026-175
composer update drupal/webform --with-dependencies
vendor/bin/drush updatedb -y
vendor/bin/drush cache:rebuild3. Faire valider par la chaîne d'intégration, puis déployer
Chaque correctif passe par une demande de fusion et par le pipeline GitLab CI du projet, qui valide le fichier Composer et l'installation des dépendances avant toute mise en production. Le déploiement applique ensuite les mises à jour de base de données, reconstruit le thème et vide les caches. Le message de commit porte la référence de l'avis, ce qui rend l'historique auditable : on sait quel correctif a été appliqué, quand, et sur quel site.
Ce que cela donne en pratique
Ce site, akabia.fr, utilisait Webform 6.3.0-beta7. Le passage en 6.3.1 est daté du 23 septembre 2026, le jour même de la publication des avis, et l'historique Git en porte la trace. Le même traitement est appliqué aux sites de nos clients sous contrat, selon la criticité de l'avis.
Pour bénéficier de cette veille et de ce circuit sur votre site : découvrir notre offre de maintenance et TMA Drupal.
Questions fréquentes sur l'alerte de sécurité Webform
Mon site utilise Webform : que dois-je faire exactement ?
Vérifier la version installée, puis passer en 6.3.1 si vous êtes en 6.3.x, ou en 6.2.12 si vous êtes en 6.2.x. Les deux versions contiennent l'ensemble des correctifs publiés le 23 septembre 2026. La commande composer audit, lancée à la racine du projet, indique si votre version est encore concernée par un avis.
La faille critique de Webform a-t-elle été exploitée ?
L'avis SA-CONTRIB-2026-175 qualifie l'exploitation de théorique au moment de la publication, et la configuration affectée de peu courante. Cela ne dispense pas d'appliquer le correctif : le code corrigé étant public, la comparaison avec la version précédente indique aux attaquants où chercher.
Vingt avis pour un seul module, est-ce le signe d'un module peu fiable ?
Non. Ils proviennent d'une revue de sécurité approfondie, publiée après correction et regroupée dans deux versions correctives. Publier un avis par vulnérabilité, avec son score et ses conditions, est plus exigeant que d'annoncer « diverses corrections » : c'est ce qui permet de décider en connaissance de cause.
Drupal est-il plus sûr que WordPress ?
La question utile n'est pas celle du code, mais celle du processus et de la maintenance. Drupal dispose d'une équipe sécurité centrale qui couvre aussi les modules contribués ayant une version stable, avec des avis normalisés et un calendrier de publication régulier. Dans les deux cas, un site non mis à jour reste vulnérable, quel que soit le CMS.
À quelle fréquence Drupal publie-t-il des avis de sécurité ?
Les avis pour les projets contribués paraissent le mercredi, ce qui permet d'organiser la veille. Leur volume varie fortement d'une semaine à l'autre : 20 avis le 9 septembre 2026, 36 le 23 septembre. Ce qui compte n'est pas le nombre, mais le délai entre la publication et l'application du correctif sur votre site.
Peut-on automatiser complètement l'application des correctifs ?
La détection s'automatise très bien avec composer audit et le module Update Manager. L'application se prépare et se teste : une mise à jour ciblée, une branche dédiée, une chaîne d'intégration qui valide, puis un déploiement. C'est ce qui permet de corriger le jour même sans casser un site en production.
