La plupart des propriétaires de sites Drupal avec qui je parle gèrent les mises à jour de sécurité Drupal de la même façon. Ce sont les correctifs que la Drupal Security Team publie pour le core et les modules contrib. Un développeur voit le security advisory. Un ticket part dans le prochain sprint. Le patch est mis en ligne quelques jours plus tard, parfois deux semaines plus tard.
Pendant des années, cela suffisait. Plus maintenant.
La raison est simple : l’IA. Un modèle de langage peut lire un patch de sécurité et écrire à partir de lui une attaque qui fonctionne. En mai 2026, il a fallu 51 minutes à des chercheurs.
Sur le Slack Drupal, j’ai vu une version encore plus courte : « il faut moins de 10 minutes pour créer un exploit à partir de n’importe quel SA ».
Je prends cela au sérieux. Dans cet article, je montre ce qui a changé et comment vous préparer à chaque security release. J’explique aussi pourquoi, selon moi, les mises à jour de sécurité ne sont plus une tâche de développeur. C’est le travail d’une équipe de support sous contrat.
Dans cet article :
- Qu’est-ce qui a changé dans la sécurité Drupal entre 2018 et 2026 ?
- Pourquoi un security advisory est-il aujourd’hui une recette d’exploit ?
- Que signifient des exploits plus rapides pour votre site Drupal ?
- Comment vous préparer à chaque mise à jour de sécurité Drupal ?
- Pourquoi les mises à jour de sécurité Drupal relèvent-elles du support et non des développeurs ?
- Ma recommandation
Qu’est-ce qui a changé dans la sécurité Drupal entre 2018 et 2026 ?
Deux vulnérabilités critiques du core Drupal le montrent le mieux. Huit ans et un outil les séparent : l’IA.
En mars 2018, Drupal a publié SA-CORE-2018-002, connu sous le nom de Drupalgeddon 2. Il a fallu environ deux semaines pour qu’un code d’exploit public apparaisse. Les hébergeurs ont eu le temps d’ajouter une protection. Les propriétaires de sites ont eu le temps de planifier la mise à jour.
En mai 2026, Drupal a publié SA-CORE-2026-004. Il s’agissait d’une injection SQL dans le core, CVE-2026-9082. Des chercheurs de Miggo Security ont décrit comment ils ont construit un exploit pour cette faille. Entre la détection du patch et un exploit fonctionnel, il s’est écoulé 51 minutes. Ils ont utilisé Claude et dépensé moins de 10 dollars en tokens. Un humain a quand même dû guider le modèle à un moment.
Deux jours plus tard, Drupal a mis à jour l’advisory : « exploit attempts are now being detected in the wild ». La CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities. Imperva a compté plus de 15 000 tentatives d’attaque. Elles ont visé près de 6 000 sites Drupal dans 65 pays.
Deux semaines en 2018. 51 minutes en 2026. Tout est dit.
La Drupal Security Team fait le même constat. Dans PSA-2026-10-12, consacré à une release critique du core, elle a écrit que « exploits might be developed within hours or days ». Elle a aussi demandé aux propriétaires de sites de réserver du temps pour les mises à jour le jour de la release.
À lire aussi : Guide pour éviter les problèmes de sécurité de Drupal : meilleures pratiques et mesures proactives
Pourquoi un security advisory est-il aujourd’hui une recette d’exploit ?
Chaque security release publie le correctif. Le correctif est un diff de code. Le diff montre quelle fonction était vulnérable. Il montre aussi quelle entrée elle ne vérifiait pas.
Avant l’IA, transformer un diff en attaque demandait une personne expérimentée et plusieurs jours de travail. Aujourd’hui, un modèle lit le diff et trouve le chemin vulnérable. Il écrit la requête et la teste sur une installation Drupal toute neuve. Un humain corrige quelques erreurs en route. La barrière de compétences a disparu. Le coût est inférieur à celui d’un déjeuner.
Les attaquants ne choisissent pas non plus leurs cibles à la main. Ils scannent Internet à la recherche de sites Drupal, vérifient la version et lancent l’attaque. C’est pourquoi Imperva a vu des milliers de tentatives en quelques jours.
La question n’est donc plus « quelqu’un prendra-t-il la peine de nous attaquer ? ». La question est « combien d’heures après la release notre patch sera-t-il en ligne ? ».
Que signifient des exploits plus rapides pour votre site Drupal ?
Je vois trois conséquences.
La fenêtre de release est votre échéance. Les releases de sécurité du core Drupal sortent le mercredi, dans une fenêtre annoncée. Si votre mise à jour passe en ligne le jeudi, votre site reste exposé une journée entière. Les scanners tournent déjà.
Vous ne pouvez pas patcher une version non supportée. Seules les branches Drupal supportées reçoivent des correctifs de sécurité. En octobre 2026, il s’agissait de 11.4.x, 11.3.x et 10.6.x. Drupal 10.5, 11.2 et les versions plus anciennes sont en fin de vie et ne reçoivent plus de correctifs. Votre site tourne sur l’une d’elles ? Alors aucun contrat de support ne vous aidera le jour de la release. Il vous faut d’abord une mise à niveau de la version de Drupal vers une branche supportée.
Le core n’est que la moitié du travail. Le 9 octobre 2026, la Security Team a publié 26 advisories contrib en une seule journée. L’un d’eux était classé highly critical. Chaque module contrib de votre site est une porte d’entrée possible. Quelqu’un doit lire ces advisories, vérifier lesquels concernent votre site et mettre à jour.
Drupal Steward offre une certaine protection. La Security Team le dit clairement : pas contre tous les exploits. Un web application firewall vous fait gagner quelques heures. Il ne remplace pas le patch.
À lire aussi : Comment mettre à niveau Drupal 8, 9 ou 10 vers Drupal 11
Comment vous préparer à chaque mise à jour de sécurité Drupal ?
L’essentiel du travail se fait avant le jour de la release, pas pendant. Voici ce que je ferais si j’étais propriétaire d’un site Drupal :
- Restez sur une branche supportée. Vérifiez votre version maintenant, pas le jour de la release. Si vous êtes sur une version non supportée, planifiez la mise à niveau tout de suite.
- Suivez la dernière patch release. La Security Team le demande avant chaque release critique. Ainsi, une mise à jour de sécurité tient en une ligne. Pas en une bataille avec les dépendances Composer.
- Gardez le staging aligné sur la production. Même version de PHP, même base de données, mêmes modules. Lancez vos tests régulièrement pour savoir à quoi ressemble un résultat « vert ».
- Décidez qui déploie et qui valide. Nommément, avec un suppléant. Les releases du core arrivent en général l’après-midi et le soir, heure européenne. Souvent après le départ de votre équipe.
- Préparez un rollback. Une sauvegarde de la base de données et une release taguée vers laquelle revenir en quelques minutes.
- Surveillez les logs après le déploiement. Repérez les requêtes inhabituelles, les nouveaux comptes administrateur et les fichiers PHP dans le répertoire files.
- N’oubliez pas le contrib. Les advisories des modules sortent chaque semaine, pas seulement avec les releases du core.
Rien de tout cela n’est difficile. Tout demande du temps, des accès et quelqu’un qui connaît le projet. C’est là le vrai problème.
Nous détaillons le processus de mise à jour dans Mise à jour de Drupal : comment bien s’en occuper ?. Si vous ne connaissez pas l’état de votre site, commencez par un audit de sécurité Drupal.
Pourquoi les mises à jour de sécurité Drupal relèvent-elles du support et non des développeurs ?
Un ticket dans le prochain sprint fonctionnait quand un exploit prenait deux semaines. Cela ne fonctionne plus quand il prend 51 minutes.
Faites le calcul. Un attaquant a besoin de moins d’une heure. Si votre processus de mise à jour prend trois jours, vous perdez à chaque fois. Vous ne gagnez que si le patch est en ligne quelques heures après la release. À chaque fois, sans réunion.
Vos développeurs savent utiliser Composer. Le problème n’est pas la compétence. C’est la disponibilité et la responsabilité :
- Quelqu’un suit chaque semaine le calendrier de sécurité Drupal et le flux des advisories.
- Quelqu’un maintient un staging opérationnel, pour tester un patch en quelques minutes.
- Quelqu’un a des heures réservées le jour de la release, pas un backlog de sprint plein.
- Quelqu’un assume la responsabilité quand la mise à jour casse un module à 20 h.
Je vois souvent l’inverse. L’agence précédente « va jeter un œil ». Ou la seule personne qui connaît le site est en vacances. Nous décrivons d’autres situations de ce type dans 10 problèmes de maintenance Drupal courants et comment les éviter.
Il vous faut une équipe responsable du site. Pas un ticket qui attend une telle équipe.
Ma recommandation
Traitez les mises à jour de sécurité Drupal comme un service sous contrat, pas comme une tâche du backlog. Cela veut dire des heures réservées, une équipe identifiée et un délai de réaction convenu.
C’est exactement le rôle de notre support Drupal. Vous disposez d’un forfait mensuel d’heures garanties et d’une équipe qui connaît votre projet. Vous avez aussi un processus clair pour les jours de release critique.
Concrètement :
- Suivi des mises à jour de sécurité. Nous suivons les advisories du core et du contrib. Nous vous disons lesquels concernent votre site avant que vous ne le demandiez.
- Capacité réservée. Les heures sont planifiées à l’avance. Une security release n’entre pas en concurrence avec votre sprint.
- SLA pour les incidents. Délai de réaction garanti pour les problèmes critiques, à partir d’une heure dans le forfait Enterprise.
- Environnements et processus. Environnements de staging et de dev, Jira Service Desk et Slack. Estimations avant le début du travail et rapport mensuel des heures consommées.
- Pas d’engagement long. Trois mois minimum, puis résiliation mensuelle.
Vous hésitez entre un support et une équipe dédiée ? Nous comparons les deux dans Équipe de développement vs support : quel service de développement web choisir ?.
Vous voulez qu’une équipe prenne en charge la sécurité de votre site Drupal ?
C’est ainsi que nous travaillons par exemple avec Exide Group. Nous avons repris leur site, construit sur une version précoce de Drupal 8, où installer des patchs de sécurité sans régressions était difficile. Nous avons nettoyé le code et introduit Composer, des environnements de test et l’intégration continue. Depuis, nous maintenons le site à jour et continuons à le développer. Les détails sont dans l’étude de cas Exide Group.
Nous travaillons avec Drupal et PHP depuis plus de 15 ans. Nous sommes certifiés ISO 27001:2022. C’est utile quand votre équipe sécurité ou vos achats commencent à poser des questions.
La prochaine release critique arrivera. Parlez-nous du support Drupal et faites des mises à jour de sécurité la responsabilité de quelqu’un.
