La sécurité Drupal est l’un des rares domaines du monde des CMS open source où le processus publié vaut mieux que la réputation de la plateforme. L’équipe de sécurité Drupal applique un calendrier de divulgation fixe, note chaque avis sur une échelle numérique documentée et coordonne les correctifs sur le cœur comme sur des dizaines de milliers de projets contribués.

Le bilan sur le terrain est moins bon que ce processus ne le mérite. Des sites Drupal sont bel et bien compromis, et la cause n’est presque jamais que personne ne savait. L’avis a été publié, à l’heure, un mercredi. Le correctif a atteint la production la semaine suivante. Cet écart est le sujet de cet article, et le durcissement, les pare-feu et les droits de fichiers existent tous pour le rendre survivable ou pour le raccourcir.

Votre risque dépend de votre vitesse de correction, pas des modules que vous utilisez. Les avis sur le cœur arrivent dans une fenêtre mensuelle du mercredi et les avis sur les projets contribués tous les mercredis, chacun noté de 0 à 25 sur une échelle publiée. Des failles hautement critiques du cœur ont été exploitées en quelques heures après la divulgation : après l’avis d’injection SQL de 2014, la consigne officielle était de considérer tout site non corrigé dans les sept heures comme déjà compromis. Un site incapable de déployer un correctif du cœur en une journée de travail porte la quasi-totalité du risque existant.

Comment fonctionne réellement le processus d’avis de sécurité Drupal

La plupart des personnes qui exploitent un site Drupal n’ont jamais lu les documents de processus, et c’est dommage : ils disent exactement quel préavis vous obtenez, sous quelle forme et quels jours.

Les fenêtres de publication

L’équipe de sécurité publie selon un calendrier. Les avis sur les projets contribués sortent tous les mercredis. Le cœur dispose d’une fenêtre de correction de bogues et de fonctionnalités le premier mercredi du mois et d’une fenêtre de publication de sécurité le troisième, comme l’expose la documentation sur le calendrier des publications de sécurité. Une fenêtre n’est pas la promesse que quelque chose sortira ; elle existe pour que les administrateurs sachent quels jours surveiller.

Il arrive qu’un préavis soit donné. Avant une publication hautement critique du cœur, l’équipe peut publier une annonce de service public, généralement le lundi. PSA-2026-05-18 l’a fait pour la publication du 20 mai 2026, en indiquant une fenêtre de 17:00 à 21:00 UTC et en demandant aux propriétaires de passer d’abord au dernier correctif de leur branche, afin que les problèmes de mise à niveau apparaissent tôt. Deux jours, c’est le préavis maximal que vous obtiendrez.

Avis du cœur et avis des projets contribués

Ce sont deux systèmes aux garanties différentes. Les avis du cœur couvrent les branches mineures prises en charge, deux à la fois, la plus récente et celle qui la précède. En pratique, le calendrier des publications du cœur désigne 11.4.x et 11.3.x, 10.6.x restant couverte tant que Drupal 10 court jusqu’à sa fin de vie le 9 décembre 2026. Début septembre 2026, les versions actuelles sont 11.4.5, 11.3.16 et 10.6.15. Drupal 12.0.0 et 11.5.0 sont attendus la semaine du 7 décembre 2026, moment où la prise en charge de 11.3.x et de 10.6.x prendra fin.

La couverture des projets contribués est facultative et conditionnelle. Des avis ne sont émis que pour les versions stables des branches majeures prises en charge des projets dont les mainteneurs ont demandé et obtenu cette couverture, en application de la politique de processus et de permissions des avis de sécurité. Un module en version alpha, bêta ou candidate se situe hors du système, tout comme celui dont le mainteneur n’a jamais adhéré. Aucun de ces deux faits n’est visible depuis l’interface d’administration lorsque le site tourne normalement.

Le volume constitue la vraie charge de travail. Le mercredi 26 août 2026, l’équipe a publié dix avis de projets contribués en une seule journée, tous modérément critiques. Un site utilisant soixante modules sera nommé plusieurs fois par an, et ce flux coûte plus cher dans la durée que les urgences du cœur.

Le score de risque, et pourquoi ce n’est pas CVSS

Chaque avis porte une note sur 25. L’échelle repose sur le NIST Common Misuse Scoring System, NISTIR 7864, et elle est documentée sur la page des niveaux de risque de sécurité. Six métriques l’alimentent : la complexité d’accès, l’authentification requise, l’impact sur la confidentialité, l’impact sur l’intégrité, l’existence d’un exploit connu et la diffusion des cibles. Les bandes vont de non critique de 0 à 4, peu critique de 5 à 9, modérément critique de 10 à 14, critique de 15 à 19 et hautement critique de 20 à 25.

Parce que la diffusion des cibles entre dans le score, une faille qui ne mord que sur une configuration rare se place plus bas qu’elle ne le ferait sous CVSS. SA-CORE-2026-005 du 17 juin 2026, un problème d’injection d’objet PHP suivi sous CVE-2026-55803, a obtenu 18 et a été classé critique plutôt que hautement critique exactement pour cette raison.

Quand un module contribué devient non maintenu

L’équipe de sécurité ne peut contraindre aucun mainteneur bénévole à corriger quoi que ce soit. Lorsqu’un mainteneur cesse de répondre, la procédure documentée consiste à marquer le projet comme non maintenu après des tentatives de contact répétées. La page du projet avertit alors les propriétaires de choisir une solution activement maintenue, ou de payer quelqu’un pour corriger le défaut afin que le module puisse être republié.

Ce conseil est juste et coûteux, car le jour où un module est marqué non maintenu, il est en général structurant, et le remplacer suppose migration de données, modifications de gabarits et test de régression complet. Le moment économique pour agir est la version qui précède l’abandon, quand le mainteneur s’est tu mais que rien n’est cassé, et presque personne ne regarde à ce moment-là.

Drupal 7 est en fin de vie, et le support étendu n’équivaut pas à la sécurité

Drupal 7 a atteint sa fin de vie le 5 janvier 2025, confirmée par PSA-2025-01-06. Après cette date, l’équipe de sécurité a cessé d’assurer le support et les avis pour le cœur de Drupal 7 ainsi que pour ses modules et thèmes contribués. L’annonce était explicite : les problèmes de sécurité de Drupal 7 peuvent désormais être divulgués publiquement sans coordination, et des failles de type zero day peuvent survenir.

Il existe un marché commercial de support étendu. La Drupal Association a certifié des prestataires, dont HeroDevs et Tag1 Consulting, dans le cadre d’un Extended Security Support Provider Program, et ils produisent bel et bien des correctifs. C’est mieux que rien, mais ce n’est pas la même chose qu’être pris en charge. Le prestataire corrige le cœur et un ensemble défini de modules qu’il a choisi de couvrir, selon son propre calendrier, pour les clients qui paient. Le reste de l’écosystème dont dépend votre site sort du périmètre.

Un CMS non maintenu est aussi difficile à défendre dans un questionnaire d’assurance fournisseur ou face à un assureur après un incident. Notre guide sur les coûts, options et échéances de migration Drupal expose ce que coûte la sortie.

Le motif historique : Drupalgeddon et la suite

Trois incidents ont façonné la façon dont la communauté pense la vitesse de correction. Chacun était une faille d’injection ou d’exécution de code à distance dans le cœur, et chacun a vu une exploitation automatisée de masse en quelques heures ou quelques jours.

La fenêtre de sept heures d’octobre 2014

Le Drupalgeddon d’origine était SA-CORE-2014-005, publié le 15 octobre 2014. CVE-2014-3704 était une faille d’injection SQL dans la couche d’abstraction de base de données de Drupal 7, exploitable par des utilisateurs anonymes, notée 25 sur 25. Tout site Drupal 7 inférieur à 7.32 était affecté.

C’est la suite qui en a fait un jalon. PSA-2014-003 a indiqué aux propriétaires que des attaques automatisées avaient commencé à compromettre des sites non corrigés dans les heures suivant l’annonce, et qu’ils devaient supposer que tout site non corrigé avant 23:00 UTC ce jour-là, soit sept heures après la publication, avait été compromis. Non pas pouvait l’avoir été. L’avait été. L’avis prévenait que les attaquants pouvaient avoir emporté toutes les données et installé des portes dérobées, ce qui transforme un problème de correctif en problème de réponse à incident.

Drupalgeddon 2 et 3

SA-CORE-2018-002, publié le 28 mars 2018, portait sur CVE-2018-7600 : une faille d’exécution de code à distance touchant plusieurs sous-systèmes de Drupal 7 et Drupal 8, notée 24 sur 25. Elle affectait Drupal 7.0 jusqu’à 7.57 et les branches 8.x jusqu’à 8.5.0, et des exploits publics ont suivi en une quinzaine de jours.

Quatre semaines plus tard, SA-CORE-2018-004 est arrivé le 25 avril 2018. CVE-2018-7602 était une autre faille d’exécution de code à distance dans du code voisin, notée 20 sur 25, et l’avis précisait qu’elle était déjà exploitée dans la nature. L’intervalle est la leçon : les sites qui avaient corrigé en mars puis cessé d’être attentifs se sont retrouvés exposés à nouveau en avril.

Mai 2026, et ce qui n’a pas changé

Le motif n’appartient pas à l’histoire. SA-CORE-2026-004 a été publié le 20 mai 2026 : CVE-2026-9082, une faille d’injection SQL touchant les sites sur PostgreSQL, notée hautement critique à 23 sur 25, couvrant toutes les branches de 8.9 jusqu’à 11.3.9. Le 22 mai à 04:30 UTC, l’avis a été amendé pour consigner des tentatives d’exploitation détectées dans la nature, moins de 48 heures entre la publication et les attaques observées.

Rien de tout cela ne vise l’équipe de sécurité. Elle a donné deux jours de préavis, livré dans la fenêtre annoncée et mis à jour l’avis quand la situation a changé. Le mode de défaillance se trouve du côté de l’exploitant : aucun chemin répété de l’avis jusqu’à un site de production corrigé.

Où la sécurité Drupal échoue vraiment en pratique

Le cœur fait les gros titres et c’est le moindre des soucis. Dans les sites que nous auditons, le constat qui compte est rarement une version du cœur non corrigée, car les mises à jour du cœur apparaissent dans l’interface d’administration et quelqu’un les remarque. L’exposition est ailleurs.

L’inventaire de modules que personne ne possède

Un site Drupal de taille moyenne utilise entre quarante et quatre-vingts modules contribués, chacun avec un mainteneur et une cadence distincts. La question à laquelle presque personne ne sait répondre sur demande est de savoir lesquels ont encore un mainteneur actif, lesquels sont couverts par la politique d’avis et lesquels n’ont pas reçu de commit depuis deux ans. Produire cette liste prend un après-midi.

Le module sur mesure que personne n’assume

Le constat sérieux le plus fréquent est un module sur mesure écrit par un prestataire qui est parti. Il fait généralement quelque chose de la famille de l’intégration : un flux CRM, un gestionnaire de formulaire spécifique, un rappel de paiement. Il a été écrit contre une API plus ancienne, n’a pas de tests, et personne dans l’équipe ne sait dire ce qu’il valide. Le code sur mesure sort du système d’avis par définition : aucun courriel du mercredi ne vous dira qu’il contient une injection SQL, et le rapport d’état affichera tout comme à jour. Il demande la même discipline de revue que tout autre travail de développement logiciel.

La pile sous Drupal

Drupal, c’est du PHP, et les versions de PHP atteignent leur fin de vie selon leur propre calendrier. Un site peut être entièrement corrigé au niveau du CMS et tourner malgré tout sur une version de PHP qui a cessé de recevoir des correctifs de sécurité il y a un an, parce que l’hébergement n’a jamais fait partie de la conversation sur la maintenance. Les recommandations sur les droits et la propriété des fichiers reposent sur le principe que le serveur web ne doit pas pouvoir écrire les fichiers qu’il exécute, et pourtant beaucoup de sites tournent avec un répertoire de code inscriptible parce que cela simplifiait un script de déploiement.

Comment un site Drupal devrait réellement être corrigé

La réponse est ennuyeuse, ce qui explique qu’elle reste lettre morte. Aucun outillage ne supprime le besoin d’un chemin répété de l’avis à la production, et le construire une fois coûte moins cher que la première urgence.

Le flux de travail Composer

Tout, depuis Drupal 8, est un projet Composer. Mettez à jour les paquets du cœur avec leurs dépendances, puis appliquez les mises à jour de base de données et reconstruisez le cache :

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

Drush peut être remplacé par update.php. Consultez le rapport d’état avant et après. L’important n’est pas les commandes, mais le fait qu’elles s’exécutent ailleurs qu’en production d’abord.

Une préproduction qui est vraiment une copie

Un environnement de préproduction n’aide que s’il reflète la production : le même jeu de modules, la même version de PHP, une base de données récente et assainie. Une préproduction périmée produit un résultat vert qui ne veut rien dire, ce qui est pire que pas de préproduction du tout, car elle fabrique de la confiance.

La séquence consiste à descendre la production vers la préproduction, appliquer la mise à jour, exécuter les mises à jour de base de données, parcourir les pages et les formulaires qui rendent le site commercialement utile, puis déployer. Avec un pipeline qui fonctionne, cela prend 45 à 90 minutes. Sans, une journée et demie.

L’automatisation et ses limites

Les mises à jour automatisées de dépendances aident surtout sur le flux des modules contribués, l’extrémité à fort volume et faible gravité. Un robot qui ouvre une requête de fusion par mise à jour de module, avec des tests exécutés sur chacune, transforme une passe manuelle mensuelle en file de revue. Le cœur suit la même voie : les travaux d’Automatic Updates reposent sur le module Package Manager, livré dans le cœur mais encore expérimental.

Le budget temps réaliste

Un site Drupal maintenu coûte environ une demi-journée par mois en mises à jour de modules de routine, plus une à trois heures pour chaque publication de sécurité du cœur qui s’applique. Ajoutez une réserve pour les une ou deux publications hautement critiques de l’année qui doivent être faites le soir même. C’est le chiffre que la plupart des équipes internes n’ont jamais budgété, et c’est pourquoi le travail glisse.

Le durcissement au-delà des correctifs

Le durcissement ne remplace pas la correction. Il réduit le nombre de vulnérabilités publiées qui sont exploitables sur votre installation, et il achète du temps quand un correctif ne peut pas partir immédiatement. Les points propres à Drupal sont peu coûteux et permanents.

Hôtes de confiance et système de fichiers

Définissez les motifs d’hôtes de confiance. Drupal utilise le mécanisme d’hôtes de confiance de Symfony, configuré par le paramètre trusted_host_patterns dans settings.php sous forme d’expressions régulières correspondant aux domaines sur lesquels votre site répond. Les requêtes portant tout autre en-tête Host sont rejetées avec un code 400. Sans cela, un attaquant peut empoisonner les liens de réinitialisation de mot de passe et les URL absolues mises en cache au moyen d’un en-tête forgé.

Utilisez le système de fichiers privé pour tout ce qui ne doit pas être lisible publiquement, et assurez-vous que PHP ne peut pas s’exécuter dans le répertoire de fichiers public. Drupal fournit un fichier .htaccess qui bloque l’exécution sous Apache, mais nginx n’a pas de fichier équivalent à déposer et la règle doit être écrite à la main dans la configuration du serveur. Les sites passés d’Apache à nginx il y a des années ont fréquemment perdu cette protection en silence.

Appliquez ensuite le modèle de propriété : répertoires en 750, fichiers de code en 640, le répertoire de fichiers inscriptible par le serveur web et par rien d’autre, et settings.php lisible uniquement par son propriétaire.

Permissions, routes d’administration et passe de revue

Restreignez les routes d’administration. Il n’y a aucune raison pour que les chemins de connexion et d’administration d’un site dont les éditeurs travaillent depuis trois bureaux soient joignables depuis l’internet entier, et une liste d’adresses IP autorisées ou un proxy authentifiant supprime toute une classe d’attaques sur les identifiants.

Auditez ensuite la grille des permissions. Elle grossit à chaque module installé, et le constat a presque toujours la même forme : un rôle d’éditeur qui peut administrer les filtres de texte, ou un rôle qui peut exécuter du PHP arbitraire. L’un comme l’autre convertit un mot de passe d’éditeur volé en exécution de code à distance, de sorte qu’un courriel d’hameçonnage devient une compromission du serveur.

Lancez le module Security Review avant de discuter de quoi que ce soit d’autre. Il automatise les contrôles fastidieux à la main : droits du système de fichiers, formats de texte dangereux, PHP ou JavaScript dans le contenu, exposition des rapports d’erreur, extensions de téléversement, échecs de connexion, permissions dangereuses et configuration des hôtes de confiance. La version 3.1.3, publiée en janvier 2026, prend en charge Drupal 10.3 et au-delà ainsi que Drupal 11.

Ce qu’apporte un pare-feu et ce qu’il n’apporte pas

Un pare-feu applicatif web est un correctif virtuel, et c’est ainsi que la Drupal Association positionne Drupal Steward, le service payant qu’elle exploite avec l’équipe de sécurité. Il applique une atténuation au niveau réseau pour certaines vulnérabilités hautement critiques du cœur, protégeant un site pendant l’écart entre l’avis et le déploiement. Le tarif publié est inférieur à 20 dollars américains par mois pour un site servant un million de requêtes HTTP, et inférieur à 100 dollars américains au-delà de dix millions.

Les limites sont énoncées par le projet lui-même : tous les problèmes ne peuvent pas être atténués ainsi, et le mécanisme ne couvre que les vulnérabilités exploitées par une requête vers le serveur web. Un pare-feu ne fait rien contre un mot de passe administrateur compromis, une mise à jour de module malveillante ou une faille dans votre propre code. Traitez-le comme une assurance pour la fenêtre de correction, et non comme une raison de l’élargir, ce qui est aussi le point de vue de notre check-list de durcissement de la sécurité WordPress.

Ce que coûte une compromission et à quoi ressemble la reprise

Se remettre d’une compromission Drupal n’est pas un correctif. Dès qu’un attaquant a obtenu l’exécution de code, l’hypothèse de travail est que des fichiers ont été écrits, des identifiants emportés et un mécanisme de persistance installé, ce qui est précisément ce que l’équipe de sécurité a dit aux propriétaires de sites Drupal 7 en 2014. Nettoyer sur place un site compromis, c’est deviner en se faisant passer pour de la remédiation.

L’approche défendable consiste à reconstruire la base de code depuis la gestion de versions sur un nouvel hébergement, à ne restaurer que le contenu et les fichiers téléversés après inspection, à faire tourner tous les identifiants que le site détenait, et à conserver l’image disque compromise plutôt que de la supprimer. C’est cette dernière étape que l’on saute sous la pression, et c’est la seule preuve de ce qui s’est passé.

Le coût commercial est rarement la reconstruction. Ce sont l’indisponibilité, le travail de forensique, la communication client et la procédure réglementaire. Une reconstruction en conditions d’incident représente typiquement 5 000 à 20 000 livres sterling d’ingénierie, généralement la plus petite ligne du total.

Obligations britanniques en matière de protection des données

Si des données personnelles ont été consultées ou ont pu l’être, l’horloge du RGPD britannique démarre au moment où vous en prenez connaissance, pas quand vous achevez votre enquête. Les recommandations de l’ICO sur les violations exigent qu’une violation notifiable soit signalée sans retard injustifié et au plus tard 72 heures après en avoir pris connaissance, et si vous prenez plus de temps, vous devez motiver ce délai. Lorsque la violation est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes, vous devez également informer ces personnes sans retard injustifié.

L’ICO est clair : un tableau incomplet n’est pas une raison de manquer l’échéance. Signalez ce que vous savez et complétez ensuite. L’absence de notification lorsqu’elle est requise peut valoir une amende allant jusqu’à 8,7 millions de livres sterling ou 2 pour cent du chiffre d’affaires mondial.

Cette horloge explique pourquoi la question de la forensique compte. Un site sans journaux et sans trace de la version qui tournait ne peut pas dire à quelles données on a accédé, et il finit par déclarer le pire des cas. C’est l’argument en faveur d’un audit de sécurité de site web avant un incident plutôt qu’après.

Ce que devrait couvrir un contrat de maintenance de sécurité Drupal

Un contrat qui promet seulement d’appliquer les mises à jour ne vaut pas la peine d’être acheté, car appliquer les mises à jour est la moitié facile. Ce que vous payez, c’est le chemin de réponse le jour où un avis hautement critique tombe, et le livrable qui prouve qu’il fonctionne est une répétition.

Le périmètre qui vaut son prix couvre la surveillance des flux d’avis pour votre jeu exact de modules, un cycle mensuel de correctifs avec préproduction, tests et plan de retour arrière, une fenêtre de réponse hors heures ouvrées convenue pour les publications hautement critiques du cœur, une revue trimestrielle des modules abandonnés avec chiffrage des remplacements, le suivi des versions de PHP et de la plateforme, et une revue annuelle de la configuration.

Au Royaume-Uni, les formules de surveillance seule se situent autour de 250 à 450 livres sterling par mois. Un contrat incluant préproduction, tests et déploiement pour un site de taille moyenne se rapproche plutôt de 600 à 1 500 livres sterling par mois, à l’échelle du nombre de modules et du volume de code sur mesure, car les deux décident de la quantité de tests de régression nécessaire à chaque cycle. Face à des tarifs journaliers d’agence de 600 à 900 livres sterling, le haut de cette fourchette achète environ deux jours d’ingénieur. Notre note sur les tarifs et la sélection des développeurs Drupal donne les chiffres.

Refermer la fenêtre

Drupal vous donne plus de préavis et plus de structure que presque toute plateforme comparable. Les avis suivent un calendrier et les publications hautement critiques arrivent avec deux jours de préavis. Rien de tout cela n’aide un site qui met une quinzaine de jours à déployer un correctif d’une ligne.

Mecanik prend en charge la correction et le durcissement Drupal dans le cadre de notre audit de sécurité de site web et de nos travaux continus de développement logiciel. La première mission est en général un inventaire plutôt qu’une correction, car la plupart des sites ne savent pas dire lesquels de leurs modules sont encore maintenus. Si vous évaluez la plateforme elle-même, notre guide 2026 du développement web Drupal traite le sujet.

Questions fréquentes

À quelle fréquence Drupal publie-t-il des mises à jour de sécurité ? Les avis sur les projets contribués paraissent tous les mercredis, et le cœur de Drupal dispose d’une fenêtre de publication de sécurité le troisième mercredi de chaque mois, même si une fenêtre ne garantit pas une publication. Les publications hautement critiques du cœur sont généralement précédées d’une annonce de service public environ deux jours avant, indiquant la date et la fenêtre horaire.

Que signifie un score de risque Drupal de 20 sur 25 ? Drupal note chaque avis de 0 à 25 avec un système fondé sur le NIST Common Misuse Scoring System, combinant la complexité d’accès, l’authentification requise, l’impact sur la confidentialité et l’intégrité, l’existence d’un exploit connu et le nombre de sites affectés. Tout ce qui se situe entre 20 et 25 est hautement critique, ce qui veut dire corriger le jour même.

Drupal 7 est-il encore sûr à exploiter en 2026 ? Non. Drupal 7 a atteint sa fin de vie le 5 janvier 2025 et l’équipe de sécurité Drupal n’émet plus d’avis pour son cœur, ses modules contribués ou ses thèmes, si bien que des failles peuvent être divulguées publiquement sans correctif coordonné. Le support étendu commercial couvre un ensemble défini de code aux conditions du prestataire, ce qui aide pendant une migration mais n’équivaut pas à être pris en charge.

À quelle vitesse les attaquants exploitent-ils une vulnérabilité Drupal ? En quelques heures dans les pires cas. Après l’avis d’injection SQL d’octobre 2014, l’équipe de sécurité Drupal a demandé aux propriétaires de supposer que tout site non corrigé dans les sept heures avait déjà été compromis. En mai 2026, des tentatives d’exploitation contre une injection SQL hautement critique du cœur ont été détectées dans la nature moins de deux jours après la publication.

Un pare-feu applicatif web rend-il inutile la correction de Drupal ? Non. Un pare-feu comme Drupal Steward fournit un correctif virtuel pour certaines failles hautement critiques du cœur exploitées par une requête web, ce qui achète du temps pendant la fenêtre de déploiement. Il ne peut rien contre un mot de passe administrateur volé, un module compromis ou une faille dans votre propre code, il réduit donc le risque de l’écart au lieu de le refermer.