Ce que l'équipe sécurité de Drupal a publié le 9 septembre 2026
Le mercredi 9 septembre 2026, la Drupal Security Team a publié 20 avis de sécurité visant des projets contribués. Neuf sont classés « Critical », onze « Moderately critical ». Fait inhabituel, 11 de ces avis, numérotés de SA-CONTRIB-2026-141 à SA-CONTRIB-2026-151, concernent un seul module : SAML SSO - Service Provider, de nom machine miniorange_saml, maintenu par la société miniOrange.
Ce module transforme un site Drupal en fournisseur de service SAML 2.0 : les utilisateurs se connectent avec le compte de leur organisation, géré par un fournisseur d'identité comme Microsoft Entra ID, Okta, ADFS, Google Workspace ou Shibboleth. Drupal.org recense environ 2 600 sites qui déclarent l'utiliser, sur Drupal 9.3, 10 et 11.
Les quatre failles critiques :
- Contrôle d'accès insuffisant (SA-CONTRIB-2026-141, score 18/25) : des utilisateurs non autorisés pouvaient accéder à des fonctions d'administration du module et modifier sa configuration.
- Validation de certificat incorrecte (SA-CONTRIB-2026-142, 15/25) : les certificats TLS n'étaient pas vérifiés lors des requêtes HTTPS sortantes, ce qui permet à un attaquant placé sur le réseau de se faire passer pour un service de confiance.
- Redirection ouverte (SA-CONTRIB-2026-143, 16/25) : des utilisateurs authentifiés pouvaient être redirigés vers un site externe, un levier classique d'hameçonnage.
- Pratiques cryptographiques faibles (SA-CONTRIB-2026-144, 15/25) : comparaison de signatures non réalisée en temps constant et identifiants de requêtes SAML prévisibles.
Les sept autres avis, modérément critiques, portent sur un contournement d'authentification, deux failles XSS, des identifiants embarqués dans le code, une fuite d'informations, une protection insuffisante contre le rejeu d'assertions SAML et une falsification de requête côté serveur (SSRF). Tous sont corrigés par la version 3.2.0, publiée le même jour. Selon les avis, aucune exploitation active n'est connue à ce stade : le risque reste théorique, mais le code corrigé est désormais public et les attaquants peuvent comparer les deux versions.
Source : The Drop Times, 10 septembre 2026 et avis de sécurité des projets contribués sur drupal.org.
L'alerte SAML SSO en quatre chiffres
Pourquoi une faille SAML SSO pèse plus lourd qu'une autre
Un module SSO n'est pas une fonctionnalité parmi d'autres : c'est la porte d'entrée du site. Les organisations qui l'installent sont justement celles qui ont le plus à protéger : intranets RH, extranets partenaires, portails d'administrations et de collectivités, espaces clients de grands comptes.
Dans ce contexte, chaque faille a un effet de levier :
- Un contrôle d'accès défaillant sur la configuration SAML permet, en théorie, de modifier le fournisseur d'identité de confiance ou la correspondance des rôles, donc de s'ouvrir un accès.
- Une redirection ouverte sur un domaine officiel donne une crédibilité maximale à un lien d'hameçonnage envoyé aux agents ou aux salariés.
- Des assertions rejouables ou des identifiants prévisibles affaiblissent précisément la garantie qu'apporte SAML : « cette personne a bien été authentifiée par son organisation ».
Le calendrier aggrave le constat. Ce même module avait déjà fait l'objet d'une faille XSS critique en février 2026 (corrigée en 3.1.3), puis d'un contournement d'authentification critique en avril (corrigé en 3.1.4). Un site mis en ligne l'an dernier et jamais mis à jour cumule aujourd'hui les treize failles.
Drupal est réputé sûr, son écosystème demande un suivi
La réputation de sécurité de Drupal est méritée : une équipe sécurité dédiée, un processus de divulgation coordonné, des avis publiés à date fixe le mercredi, des correctifs livrés en même temps que l'annonce. C'est l'une des raisons pour lesquelles ministères, universités et grands groupes le choisissent.
Mais cette réputation porte sur un processus, pas sur l'état d'un site donné. Un projet Drupal courant embarque plusieurs dizaines de modules contribués, chacun maintenu par des bénévoles ou par une entreprise, à des rythmes très différents. L'alerte SAML SSO en est l'illustration : le système a fonctionné (les failles ont été signalées, corrigées et documentées), et pourtant chaque site reste vulnérable tant que quelqu'un n'a pas appliqué la 3.2.0.
Trois réalités à garder en tête :
- Le badge de couverture de sécurité ne vaut que pour les versions stables : un module installé en version alpha, bêta ou en
devne fait l'objet d'aucun avis public, même s'il est vulnérable. - Les correctifs ne sont pas toujours applicables en un clic : un saut de version mineure peut exiger des mises à jour en cascade, une version de PHP plus récente ou la reprise d'un patch local.
- La publication d'un correctif ouvre une course : le code corrigé étant public, la comparaison avec l'ancienne version guide les attaquants vers la faille. En octobre 2014, lors de la faille surnommée Drupalgeddon, des attaques automatisées ont commencé dans les sept heures suivant la publication du correctif, d'après l'annonce PSA-2014-003 de l'équipe sécurité.
Un site « livré et oublié » ne reste donc pas au niveau de sécurité de sa mise en production : il recule à chaque mercredi de publication.
Vous utilisez SAML SSO - Service Provider (miniorange_saml) ? Toute version antérieure à la 3.2.0 est concernée par les 11 avis du 9 septembre 2026. Aucune mesure de contournement n'est proposée : la mise à jour vers la 3.2.0 est la seule correction. Les autres modules SAML de l'écosystème, comme SAML Authentication (samlauth) ou simplesamlphp_auth, ne sont pas visés par ces avis.
Ce que couvre concrètement une TMA Drupal chez Akabia
La Tierce Maintenance Applicative (TMA) désigne l'ensemble des interventions qui maintiennent un site en condition opérationnelle et sécurisée après sa mise en ligne. Chez Akabia, un contrat de maintenance et TMA Drupal repose sur quatre engagements.
Veille de sécurité continue
Chaque avis publié par la Drupal Security Team est croisé avec le composer.lock des sites sous contrat. La question n'est pas « y a-t-il une faille dans Drupal ? » mais « ce site précis, dans cette version précise, est-il concerné ? ». Pour l'alerte du 9 septembre, la réponse est connue le jour même.
Application des correctifs dans un circuit maîtrisé
Chaque intervention est tracée sur une branche Git dédiée, testée sur un environnement de préproduction, puis déployée. Pour une mise à jour de sécurité, la séquence type est la suivante :
# Mettre à jour uniquement le module concerné et ses dépendances
composer update drupal/miniorange_saml --with-dependencies
# Vérifier qu'aucune vulnérabilité connue ne subsiste
composer audit
# Appliquer les éventuelles mises à jour de base de données puis vider les caches
vendor/bin/drush updatedb -y
vendor/bin/drush cache:rebuildTests de non-régression
Une mise à jour de module SSO est l'exemple type de correctif que les équipes internes repoussent : si l'authentification casse, plus personne ne se connecte. C'est précisément ce que la préproduction doit sécuriser. Avant la mise en production, on vérifie au minimum la connexion depuis le fournisseur d'identité de test, la déconnexion, l'attribution des rôles Drupal à partir des attributs SAML et la création des comptes au premier accès. On conserve aussi un compte administrateur local, hors SSO, pour ne jamais perdre la main sur le site. Les tests automatisés de la chaîne CI/CD complètent ces contrôles manuels sur le reste du site.
Suivi et reporting
La supervision des serveurs (disponibilité, temps de réponse, charge) détecte les anomalies après déploiement, et un rapport mensuel détaille les interventions réalisées, le temps consommé et l'état de santé global de l'application. Le client sait à tout moment ce qui a été corrigé et ce qui reste à planifier.
Check-list : votre site Drupal est-il à jour ?
Pas besoin d'être développeur pour poser les bonnes questions. Voici les points à vérifier, ou à faire vérifier par votre prestataire, cette semaine.
- Le rapport des mises à jour disponibles (
/admin/reports/updates, module Update Manager activé) n'affiche aucune ligne rouge « Mise à jour de sécurité requise ». - Les notifications par e-mail de ce module sont configurées (
/admin/reports/updates/settings) et envoyées à une adresse réellement lue, pas à celle d'un ancien prestataire. - La commande
composer audit, lancée à la racine du projet, répond « No security vulnerability advisories found ». - Vous savez si votre site utilise un module d'authentification SAML ou CAS et dans quelle version.
- Les modules installés en version alpha, bêta ou
devsont identifiés, puisqu'ils échappent aux avis de sécurité publics. - Une personne nommée est chargée de suivre les avis publiés chaque mercredi sur drupal.org et de vous alerter en cas de faille critique.
- Un délai d'application des correctifs critiques est défini par écrit, avec un environnement de préproduction pour les tester.
- Les sauvegardes de la base et des fichiers sont récentes et une restauration a déjà été testée.
Si l'une de ces lignes appelle un « je ne sais pas », votre site n'est pas forcément compromis, mais personne n'est en mesure de l'affirmer. C'est ce vide que comble un contrat de maintenance.
Questions fréquentes sur l'alerte SAML SSO Drupal
Mon site utilise l'authentification SAML : suis-je forcément concerné ?
Non. Les 11 avis du 9 septembre 2026 visent uniquement le module SAML SSO - Service Provider (miniorange_saml) dans ses versions antérieures à la 3.2.0. Les autres modules SAML, comme samlauth ou simplesamlphp_auth, ne sont pas concernés par cette série. Le plus simple est de vérifier le fichier composer.lock ou le rapport des mises à jour de votre site.
Ces failles sont-elles déjà exploitées ?
Au moment de la publication, les avis indiquent une exploitation théorique : aucune attaque active n'était connue. Ce statut peut évoluer rapidement, car le correctif public permet d'identifier le code vulnérable. Il faut donc traiter une faille critique comme urgente, sans attendre de signalement d'exploitation.
Dans quel délai faut-il appliquer un correctif de sécurité Drupal ?
Pour une faille critique, l'objectif raisonnable est de quelques jours au plus, après un passage en préproduction. Les failles modérées peuvent être regroupées dans la maintenance planifiée suivante. L'essentiel est que ce délai soit défini à l'avance, et non négocié au moment de l'alerte.
Peut-on automatiser complètement les mises à jour de sécurité ?
La détection s'automatise très bien avec composer audit ou le module Update Manager. L'application, en revanche, doit rester contrôlée : une mise à jour de module d'authentification peut bloquer toutes les connexions si elle n'est pas testée. L'automatisation accélère le travail sans remplacer la validation humaine.
Quelle différence entre TMA et simple hébergement infogéré ?
L'infogérance couvre le serveur : système, PHP, base de données, disponibilité. La TMA couvre l'application Drupal elle-même : cœur, modules contribués, code spécifique, correctifs et évolutions. Une faille dans un module comme miniorange_saml relève de la TMA, pas de l'hébergeur.
