Une faille vient d’être publiée : combien de temps me reste-t-il

Il n’existe pas un délai, il en existe plusieurs

La question m’arrive presque toujours formulée de la même façon : une faille vient d’être publiée sur une extension que j’utilise, est-ce que ça peut attendre lundi. Elle est légitime. Mettre à jour un vendredi soir sur une boutique qui encaisse, c’est accepter un risque de casse au pire moment de la semaine, sans personne pour réparer avant le lundi matin. Le problème, c’est que le calendrier n’est pas le vôtre.

Ce qui rend la décision difficile n’est pas seulement que le délai soit court. C’est qu’il est impossible à connaître à l’avance. Deux failles publiées la même semaine, avec des scores de gravité identiques, peuvent donner lieu à des attaques automatisées en quelques heures pour l’une et rester sans exploitation observée pendant près d’un mois pour l’autre. Vous ne saurez laquelle était laquelle qu’après coup, et si vous avez parié sur la mauvaise, vous l’apprendrez par vos clients.

Je préfère donc donner la mesure statistique d’abord, puis quatre chronologies réelles qui montrent l’écart entre elles, et enfin une grille de décision qui ne demande pas de deviner l’avenir.

Quatre chronologies réelles, quatre réponses différentes

Quelques heures. Le 17 juillet 2026, WordPress publie en urgence les versions 7.0.2, 6.9.5 et 6.8.6 pour corriger deux failles qui, enchaînées, permettent une exécution de code à distance sans authentification. Des codes de démonstration publics sont apparus quelques heures après la divulgation, et l’exploitation en conditions réelles a été confirmée par plusieurs équipes dans les jours qui ont suivi. Dans ce cas précis, attendre le week-end n’était pas une option, et WordPress.org a d’ailleurs forcé les mises à jour automatiques sur les versions concernées.

Quelques jours. Une faille de contournement d’authentification dans l’extension Burst Statistics, CVE-2026-8181, score 9,8, a été découverte le 8 mai 2026 et corrigée quatre jours plus tard, le 12 mai 2026, en version 3.4.2. Plus de 7 400 attaques ont été bloquées en vingt-quatre heures. Le correctif était disponible, encore fallait-il l’appliquer.

Presque un mois. L’extension Everest Forms Pro, CVE-2026-3300, score 9,8 elle aussi, a reçu son correctif le 18 mars 2026. L’exploitation active n’a été observée qu’à partir du 13 avril 2026. Un marchand qui aurait mis à jour trois semaines après la publication s’en serait tiré. Rien ne le lui garantissait au moment de décider.

Plusieurs semaines, puis un pic. Gravity SMTP, CVE-2026-4020, a été corrigée le 17 mars 2026 en version 2.1.5. L’exploitation de masse n’a démarré qu’à partir de début mai 2026, avec un pic les 6 et 7 juin 2026. Presque trois mois entre le correctif et le sommet des attaques : une boutique non mise à jour depuis mars restait une cible parfaitement valable en juin.

Deux de ces quatre failles portent exactement le même score de gravité et n’ont pas eu la même chronologie du tout. C’est précisément pour cela qu’un score ne suffit pas à décider.

Le paradoxe : c’est le correctif qui déclenche l’attaque

C’est le point que les marchands comprennent le plus mal, et je le comprends : intuitivement, un correctif publié devrait être une bonne nouvelle qui rend le site plus sûr. C’est vrai pour les sites qui l’installent. Pour les autres, il fait exactement l’inverse.

La publication d’une nouvelle version est un événement public. Le code corrigé est comparable au code précédent, la différence est visible, et cette différence indique où se trouvait le défaut et ce qui a dû être filtré. À partir de ce moment-là, la faille n’est plus une hypothèse : c’est une information vérifiable, applicable en série sur toutes les installations qui n’ont pas encore bougé. C’est ce qui explique que la fenêtre la plus dangereuse ne soit pas avant la publication du correctif, mais juste après.

Conséquence directe : le jour où votre tableau de bord affiche « mise à jour disponible », vous n’êtes pas au début d’un délai confortable, vous êtes déjà entré dans la course. Et il faut ajouter le cas inverse : 46 % des vulnérabilités n’ont aucun correctif disponible au moment où elles sont rendues publiques. Dans ces situations, la mise à jour n’est même pas une option, et la seule marge de manœuvre est une atténuation temporaire, en attendant.