Dix heures pour patcher : la fin du cycle de correction tranquille

Le 8 avril 2026, les mainteneurs de Marimo publient un avis décrivant CVE-2026-39987. Neuf heures et quarante-et-une minutes plus tard, un premier attaquant obtient un shell racine sur une instance vulnérable. Pas de code public, pas d'exploit commercial ; juste la lecture de l'advisory, reconstruite en pratique. Cet épisode n'est pas une anomalie, c'est le nouveau normal. Les équipes sécurité qui continuent de raisonner en « fenêtre de 72 heures après Patch Tuesday » travaillent dans un référentiel de temps dépassé. Il faut arrêter de s'en excuser et réorganiser la chaîne de patching autour d'une contrainte plus dure : moins de dix heures entre la disclosure et la compromission probable.

Le temps réel du risque a changé d'ordre de grandeur

En 2020, une moyenne sectorielle plaçait le délai disclosure-to-exploit autour de 28 jours. En 2023, Log4Shell l'avait déjà fait passer sous la barre des 24 heures sur certaines classes de vulnérabilités. Aujourd'hui, avec Marimo, on mesure 9 h 41. Le facteur de compression n'est pas accidentel : les advisories publics fournissent des indices techniques exploitables (endpoint exact, condition d'authentification, version vulnérable) et des LLM peuvent maintenant transformer ce texte en requête HTTP en quelques itérations. L'attaquant qui construit un exploit à partir d'un advisory ne lit plus un PDF, il pilote un assistant qui écrit le payload.

Pour BlueHammer (CVE-2026-33824), la situation est encore plus tendue : l'exploitation a précédé la disponibilité du correctif. Les clients Microsoft n'ont pas eu de fenêtre du tout — ils ont appris l'existence de la faille au moment du patch, et les premières victimes étaient déjà compromises. Ce cas de figure, autrefois réservé aux APT étatiques, devient régulier.

Ce qui ne marche plus

Trois hypothèses silencieuses du patch management classique ont sauté.

La première est la fenêtre de test de 7 à 14 jours. Elle reste légitime pour les patches « confort », mais elle est ingérable pour les CVE à exploitation active. Les équipes qui valident un correctif Windows en deux semaines opèrent pendant 13 jours sur une infrastructure connue vulnérable, avec les attaquants qui le savent.

La deuxième est la priorisation par CVSS seul. Un CVSS 6.5 comme celui du zero-day SharePoint CVE-2026-32201 a été exploité en prod avant même que beaucoup d'équipes le voient dans leur backlog. L'indicateur pertinent n'est plus le score de sévérité : c'est le signal d'exploitation active (KEV, EPSS, honeypots commerciaux).

La troisième est l'hypothèse que « l'attaquant n'a pas encore construit l'exploit ». Cette hypothèse était vraie quand les advisories étaient vagues. Elle est fausse quand un LLM peut générer une preuve de concept à partir d'un paragraphe de description technique.

Ce qui marche encore

Trois pratiques passent la nouvelle contrainte. La première est la segmentation dure. Un service vulnérable isolé derrière un mTLS ou un VPN Zero Trust gagne du temps même sans patch — les 10 heures se jouent sur ce qui est réellement joignable depuis Internet. La seconde est la télémétrie en amont du patch : savoir avant le Patch Tuesday qui est exposé sur quel service, avec quelle version. Cette cartographie est le seul moyen de traiter 163 CVE en 48 heures sans y laisser la peau de l'équipe. La troisième est le patching automatisé par vague, où la validation fonctionnelle est confiée à un petit pool de serveurs canari et l'extension se fait en heures, pas en jours.

Ce qu'il faut changer maintenant

Trois chantiers concrets, dans l'ordre de priorité. D'abord, câbler un flux KEV-first : tout CVE ajouté au catalogue CISA KEV déclenche un ticket P1 avec SLA de 72 heures, indépendamment du CVSS. Ensuite, réduire le cycle de validation interne à 48 heures par automatisation (tests d'intégration déclenchés automatiquement sur canari). Enfin, sortir de la liste blanche des services exposés tout ce qui n'est pas absolument nécessaire — un service Marimo ou nginx-ui publié sur Internet ne devrait simplement pas exister côté périmètre.

Pour aller plus loin, relire notre analyse des outils de sécurité eux-mêmes devenus vecteurs d'attaque, le dossier sur le Patch Tuesday d'avril 2026, l'effondrement de l'enrichissement côté NIST/NVD, ainsi que l'étude de cas MCPwn sur nginx-ui.

Conclusion

La fenêtre de 10 heures n'est pas négociable, elle est mesurée. Les organisations qui continuent de raisonner en semaines finiront par payer la différence, en incidents ou en rançons. La bonne nouvelle : les outils pour tenir ce tempo existent. La mauvaise : ils demandent un investissement initial que beaucoup de DSI ont encore du mal à défendre en comité de direction. L'arbitrage budgétaire de 2026 n'est plus « sécurité vs. productivité », c'est « automatisation du patching vs. incident à six chiffres ».