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

> La question n’est pas rhétorique et la réponse mesurée est plus courte que ce que la plupart des marchands imaginent. Voici les délais réellement observés entre la publication d’une faille et les premières attaques de masse.

- Source canonique : [https://allaux.fr/securite/combien-de-temps-pour-appliquer-un-correctif](https://allaux.fr/securite/combien-de-temps-pour-appliquer-un-correctif)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Lisez l’avis pour deux points seulement : la faille est-elle exploitable sans authentification, et votre version figure-t-elle dans la plage affectée. Si les deux réponses sont oui, appliquez le correctif dans la foulée plutôt qu’à la prochaine fenêtre de maintenance, après sauvegarde des fichiers et de la base. Si un compte est nécessaire pour l’exploiter, la mise à jour peut rejoindre votre cycle habituel.

## 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.

| Valeur | Description |
|---|---|
| 5 heures | délai médian entre la divulgation publique d’une faille et les premières attaques de masse |
| 1 sur 2 | environ la moitié des vulnérabilités à fort impact sont exploitées dans les 24 heures suivant la divulgation |
| 46 % | des vulnérabilités n’avaient aucun correctif disponible au moment de leur divulgation publique |

Source : Patchstack, State of WordPress Security in 2026 (chiffres portant sur 2025)

## 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.

## Ce qui fait passer une faille de « à la prochaine maintenance » à « ce soir »

1. **Elle est exploitable sans authentification** — C’est le critère le plus lourd. Tant qu’il faut un compte, même client, l’attaque se prépare. Si aucun compte n’est nécessaire, elle s’automatise sur l’ensemble du web sans effort supplémentaire, et votre boutique sera atteinte par un balayage général, pas par quelqu’un qui vous visait.
2. **L’extension est très installée** — Plus le parc est large, plus l’automatisation est rentable pour un attaquant. Une extension présente sur des dizaines de milliers de sites justifie qu’on écrive un outil ; un module présent sur trois cents boutiques, beaucoup moins. Ce n’est pas une garantie, c’est une probabilité.
3. **Le correctif est déjà public** — Si la version corrigée est sortie, la différence de code est consultable, et le compte à rebours a commencé au moment de sa publication, pas au moment où vous l’avez lue. Une faille annoncée sans correctif disponible est paradoxalement moins urgente à traiter par mise à jour, puisqu’il n’y en a pas : elle est urgente à atténuer.
4. **Aucune atténuation n’est possible** — Si vous pouvez désactiver la fonctionnalité concernée, retirer le module s’il n’est pas utilisé, restreindre l’accès au point d’entrée visé ou bloquer une route au niveau du pare-feu applicatif, vous achetez du temps et vous pouvez mettre à jour sereinement en semaine. Si rien de tout cela n’est possible sans casser une fonction de vente, il ne reste que la mise à jour, et elle est pour ce soir.

## Sans inventaire, cette grille ne sert à rien

> Tout ce qui précède suppose deux choses que beaucoup de boutiques n’ont pas. D’abord la liste exacte et à jour de ce qui tourne sur le site : extensions, thèmes, versions installées, y compris ce qui a été ajouté une fois pour un test et jamais retiré. Sans cette liste, vous ne savez même pas si l’avis de sécurité que vous venez de lire vous concerne. Ensuite un moyen de mettre à jour sans casser la boutique : une sauvegarde restaurable et testée, un environnement de préproduction, une fenêtre d’intervention connue de tout le monde. Sans cela, la vraie raison pour laquelle une mise à jour attend le week-end n’est pas la prudence, c’est la peur de casser quelque chose qu’on ne saurait pas réparer. Et cette peur-là, elle, est réparable.

## Pour aller plus loin

- **Surveiller les failles qui concernent ma boutique** — Comment être prévenu au moment de la publication plutôt que trois semaines après. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Mise à jour de sécurité en urgence** — Ce que je fais concrètement quand la réponse à la question de cette page est « ce soir ». ([/wordpress-woocommerce/mise-a-jour/urgence-securite](/wordpress-woocommerce/mise-a-jour/urgence-securite))
- **Sauvegarder sa boutique avant intervention** — Le préalable qui transforme une mise à jour risquée en opération réversible. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Modules et extensions abandonnés** — Le cas où aucun correctif ne viendra jamais, quel que soit le délai que vous vous donnez. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))

## FAQ

### Une faille avec un score de gravité élevé est-elle forcément exploitée en premier ?

Non. Le score mesure l’impact potentiel, pas l’intérêt qu’un attaquant trouve à automatiser l’attaque. Deux failles citées sur cette page portent le même score de 9,8 : l’une a été exploitée activement environ un mois après son correctif, l’autre a donné lieu à plus de 7 400 attaques bloquées en vingt-quatre heures. Le nombre d’installations et l’absence d’authentification pèsent souvent plus lourd que le score.

### Concrètement, est-ce que je peux attendre le week-end ?

Si la faille est exploitable sans authentification, sur une extension largement installée, avec un correctif déjà public et aucune atténuation possible : non. Si l’un de ces quatre points tombe, vous avez de la marge, mais je vous conseille de la mesurer en jours, pas en semaines. Le délai médian jusqu’aux attaques de masse est de cinq heures.

### Que faire si aucun correctif n’existe encore ?

C’est le cas de près de la moitié des vulnérabilités au moment de leur divulgation. Il faut alors réduire l’exposition : désactiver ou retirer le composant s’il n’est pas indispensable, restreindre l’accès à la fonctionnalité concernée, bloquer le point d’entrée visé au niveau du pare-feu applicatif, et surveiller les journaux. Ces mesures sont temporaires et doivent être levées une fois le correctif appliqué.

### Les mises à jour automatiques règlent-elles la question ?

En partie seulement. Elles couvrent bien ce qui passe par le canal officiel de mise à jour, et elles peuvent être forcées par l’éditeur en cas d’urgence, comme cela a été fait pour les versions de WordPress publiées le 17 juillet 2026. Elles ne couvrent pas les composants installés à la main, ni ceux dont l’éditeur distribue lui-même les versions. Ce sont ceux-là qu’il faut suivre manuellement.

### Comment savoir si j’ai été touché avant d’avoir mis à jour ?

Mettre à jour ne nettoie rien : si l’exploitation a eu lieu avant, l’accès obtenu reste en place. Après une mise à jour tardive sur une faille critique, je passe en revue les comptes administrateurs, les fichiers modifiés récemment, les tâches planifiées inhabituelles et les journaux d’accès sur la période concernée.