Le 18 mai 2026 à 23h35, un message dans notre canal Teams. Drupal annonce un patch highly critical pour le 20 mai, entre 17h et 23h UTC. Pas de détails sur la nature de la faille, ni sur les versions affectées dans le détail. Juste une certitude : Une petite vingtaine de sites Drupal hébergés, dont des plateformes sensibles (aéroport régional, plateforme ministérielle, industriels internationaux, institut hospitalier), allaient devoir être à jour, en sécurité, sans casse, dans la fenêtre la plus serrée possible.
Voici comment on s'est organisé. Pas comme un cas d'école, mais comme ça s'est vraiment passé : avec les arbitrages, les imprévus, les congés tombés au mauvais moment, et la décision finale qui n'a pas été la plus spectaculaire.
Le SA-CORE-2026-004 (CVE-2026-9082) a fini par être noté 23/25 sur l'échelle de risque Drupal, le plus haut niveau possible. Une injection SQL exploitable par un utilisateur anonyme, sur n'importe quel site Drupal utilisant PostgreSQL, dans les versions ≥ 8.9. Et à partir du 22 mai, l'éditeur a confirmé que des tentatives d'exploitation étaient observées dans la nature.
Ce qui rend ce type d'incident particulier en 2026, ce n'est pas la faille en elle-même (il y en a chaque année). C'est la vitesse d'exploitation que l'IA permet désormais. Entre la divulgation publique et les premiers scans automatisés à grande échelle, il ne se passe plus des jours. Il se passe des heures. Parfois moins.
L'autre nouveauté, c'est que dans la même release, Drupal embarquait les correctifs Symfony et Twig publiés en coordination avec Fabien Potencier. Donc même les sites en MySQL ou MariaDB, non concernés par l'injection SQL principale, devaient être mis à jour pour récupérer les correctifs de dépendances. Aucun parc Drupal n'était à l'écart.
À retenir : la sévérité affichée d'une faille n'est qu'une partie de l'histoire. Ce qui détermine vraiment l'urgence, c'est le délai entre la publication du correctif et l'exploitation à grande échelle. Et ce délai se réduit à chaque release.
Lundi 18 mai, 23h35. Le PSA-2026-05-18 tombe sur drupal.org. Il indique seulement la fenêtre de publication (mercredi soir) et le niveau critique. Pas la nature de la faille, pas les versions affectées en détail. Premier réflexe : poster le lien dans le canal Teams interne de l'équipe Drupal et donner le contexte. "Petite pépite explosive pour pimenter la semaine."
Mardi matin, échange à trois entre dev, archi et devops. Trois questions à clarifier avant d'embarquer l'équipe :
La réponse à la première question existait déjà : nos référentiels internes (Projet Sentinel puisé depuis la configuration Apache/PHP, le README des repos hosting pour l'inventaire, les documentations, etc.. ) listent tous les environnements, leurs versions, leurs serveurs. C'est ce qui nous a permis, en quelques heures, de générer un fichier de suivi structuré : un onglet par projet, avec hébergeur, état, priorité, planning, responsable MAJ, CDP en charge de la communication client, et version PHP / Drupal de chaque environnement.
Ce fichier n'est pas une feuille Excel improvisée. C'est la matérialisation d'un inventaire tenu à jour en continu. Sans cet inventaire, on aurait perdu une journée à reconstituer le périmètre. Avec, on a pu attaquer le mardi midi.
Le mardi 19 mai à 16h30, le mail "Alerte Sécurité" part sur tout le canal Teams Agence. L'objectif : aligner toute l'équipe (dev, CDP, hébergement) sur le même niveau d'information.
Quelques points qui me paraissent importants dans ce message :
En parallèle, on remplit le fichier de suivi avec une priorisation de 1 à 5, où 1 est le plus critique. Les sites prio 1 et 2 sont ceux à forte exposition publique, à fort trafic, ou portant des enjeux régaliens (un site ministériel, l'aéroport, des industriels grand public). Pour eux, on monte une cellule rapprochée avec des points plus fréquents et une planification de déploiement renforcée.
La communication client part dès le mardi soir, gérée par les Chefs de Projet identifiés dans le fichier. Le ton est sobre, factuel : on rappelle qu'un patch critique va sortir, qu'on a anticipé, qu'on tient au courant. Pas de panique, pas de pitch commercial. Juste de l'information utile.
Côté technique, on commence dès le mardi à monter les versions mineures sur certains projets en retard. L'idée est simple : plus on est proche de la dernière version mineure avant la divulgation, plus on a de chances que le patch s'applique sans frottement. C'est de l'anticipation pure, qui ne coûte presque rien en effort, et qui économise plusieurs heures le jour J.
Mercredi 20 mai. Dans l'après-midi, Fabien Potencier publie sur le compte Drupal Security un message qui confirme que les dépendances Symfony et Twig sont déjà disponibles et qu'on peut commencer à mettre à jour avant le patch Drupal. On embraie immédiatement sur cette partie.
Vers 18h UTC, le SA-CORE-2026-004 est publié officiellement avec les versions corrigées : 10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12, 11.3.10. La nature de la faille devient claire : injection SQL ciblant PostgreSQL uniquement.
C'est là que la discipline de l'anticipation paie. Pour les projets sur lesquels on avait déjà préparé les branches release, le passage à la version corrigée se fait par un composer update ciblé et une revue rapide.
Le déploiement suit un parcours non négociable :
Sur certains projets en cours de recette (un simulateur en pré-prod sur une plateforme client, des features non encore mergées sur master ailleurs), on a fait des branches hotfix/sa-core-2026-05-20 à part, qui n'embarquent que le patch. Le merge des features se fera après, sur un cycle normal. C'est moins élégant mais c'est ce qui évite d'introduire un effet de bord en production sous pression.
Au total : preprod patchée dans la journée du 20-21 mai, prod déployée entre le 21 et le 22 mai matin. Aucune régression remontée. Aucune anomalie post-déploiement.
Une partie du REX me paraît intéressante à partager, parce qu'elle dépasse le cas Drupal.
On parle beaucoup de l'accélération que l'IA apporte aux attaquants et c'est vrai, c'est mesurable, on le voit dans les délais d'exploitation post-divulgation. Mais il y a un autre phénomène qui monte en parallèle : la compromission de la chaîne d'approvisionnement logicielle. Et la semaine de notre patch Drupal en a fourni deux illustrations particulièrement nettes.
Le 11 mai, 84 versions malveillantes ont été publiées sur 42 packages @tanstack/* en six minutes, dont @tanstack/react-router (12 millions de téléchargements hebdomadaires). Une attaque qui portait des certificats de provenance SLSA valides, donc indétectable par les contrôles cryptographiques classiques. Aucun token npm volé, aucun compte mainteneur phishé : les attaquants ont exploité une chaîne de failles GitHub Actions pour s'insérer dans le pipeline de publication.
Neuf jours plus tard, le 20 mai (le même jour que notre patch Drupal), GitHub a confirmé l'exfiltration d'environ 3 800 dépôts internes après qu'un employé ait installé une extension VS Code malveillante. Même groupe d'attaquants présumé que pour TanStack. Le vecteur d'attaque, cette fois, c'était l'outil de développement lui-même.
Conséquence pratique : la pression pour patcher vite coexiste avec l'obligation de patcher prudemment. Un composer update ou un npm install lancé sans réflexion peut désormais embarquer du code malveillant si une dépendance transitive a été compromise. C'est exactement le piège qu'on doit éviter.
Quelques principes qu'on essaie de tenir :
Patcher en 6h sans avoir cassé une prod, c'est du travail. Patcher en 6h en ayant introduit une régression non détectée, c'est un incident qui aurait pu être évité.
Après coup, l'analyse technique a confirmé qu'aucun de nos clients n'utilisait PostgreSQL sur ses sites Drupal. La faille principale ne nous concernait pas directement. Mais les mises à jour Symfony et Twig embarquées, elles, étaient pertinentes pour tout le parc.
On aurait pu se dire, dès qu'on a su que la faille était PostgreSQL-only, qu'il n'y avait pas urgence. Ce n'est pas le choix qu'on a fait, pour deux raisons :
Ce qu'on garde de cet épisode, ce n'est pas tant l'exploit technique du déploiement rapide : beaucoup d'agences savent faire ça. C'est plutôt la chaîne complète : veille en amont, inventaire à jour, fichier de pilotage instantané, priorisation transparente, communication client structurée, anticipation pré-patch, exécution sécurisée, communication post-déploiement. Et la capacité d'une équipe (dev, archi, devops, CDP, direction) à s'aligner sans friction, à prendre chacun son périmètre avec discernement, et à adapter cette chaîne quand quelqu'un est en congé, quand un hébergeur partenaire prend du temps à répondre, ou quand une feature en recette complique le merge
C'est ce qu'on appelle, en interne, le service de veille sécurité intégré à la TMA. Ce n'est pas une option commerciale, c'est la condition de fonctionnement de toute infrastructure web qu'on prend en charge. Quand un PSA highly critical tombe un jour, on est content que toute cette organisation soit déjà en place.
Si la question de la sécurité des sites en production vous intéresse, ces sujets connexes ont été couverts sur ce blog :
Si votre site Drupal n'est pas couvert par une veille sécurité active, ou si vous voulez challenger votre dispositif actuel, parlons-en. On sera direct sur ce qu'on voit, et sur ce qu'on ferait à votre place.
.webp)
