Faille zero-day
Une vulnérabilité exploitée ou rendue publique avant que l'éditeur du logiciel ait publié un correctif.
Définition
Une faille zero-day est une vulnérabilité exploitée ou rendue publique avant que l’éditeur du logiciel ait publié un correctif. Le nom vient du nombre de jours dont l’éditeur a disposé pour la corriger : zéro. Sur WordPress, elle touche presque toujours une extension ou un thème, plus rarement le cœur.
Qu’est-ce qu’une faille zero-day ?
Une vulnérabilité que des pirates connaissent alors que l’éditeur n’a encore rien publié pour la fermer.
L’expression s’écrit aussi zero day, sans trait d’union, ou 0-day. Toute vulnérabilité logicielle passe par la même suite d’états. Elle est introduite dans le code, souvent des mois ou des années avant que quiconque la remarque. Elle est découverte, par un chercheur, par le développeur lui-même ou par un pirate. Elle est publiée, avec un identifiant CVE lorsqu’elle est enregistrée. Un correctif sort, puis il est appliqué, site par site. On parle de zero-day tant que le correctif n’existe pas : soit parce que la faille est exploitée avant que l’éditeur en ait connaissance, soit parce qu’elle a été publiée avant qu’il ait pu la corriger.
Trois mots se croisent souvent. La faille est le défaut dans le code. L’exploit zero day est le programme ou la requête qui permet d’exploiter ce défaut. L’attaque zero-day est l’utilisation de cet exploit contre des sites réels pendant que la faille n’a pas de correctif. Le glossaire du NIST, l’institut américain des normes, définit l’attaque zero-day comme l’exploitation d’une vulnérabilité jusque-là inconnue.
Comment fonctionne une attaque zero-day ?
Comme une attaque ordinaire, à une différence près : il n’existe aucune version sûre vers laquelle se mettre à jour.
| Étape | Ce qui se passe | Ce que peut faire le site |
|---|---|---|
| Faille introduite | Le défaut existe, personne ne le connaît | Rien de ciblé, seulement réduire ce qui est installé |
| Faille exploitée ou publiée sans correctif | C’est la fenêtre zero-day | Filtrer, désactiver l’extension si possible, surveiller |
| Correctif publié | La faille devient une faille connue et corrigée | Mettre à jour sans attendre |
| Correctif appliqué | Le site sort de la plage touchée | Vérifier la version servie |
Dès qu’une faille d’extension est publiée, des robots balaient les sites WordPress à la recherche de cette extension, sans choisir leur cible. Un petit site n’est pas visé pour lui-même : il est trouvé parce qu’il fait tourner le bon code dans la mauvaise version.
Quels sont les risques d’une faille zero-day ?
Les mêmes que pour toute faille grave, sans la parade habituelle.
Tout dépend de ce que la vulnérabilité permet. Les plus graves donnent à un pirate le moyen d’exécuter son propre code sur le serveur : il dépose alors une porte dérobée, crée un compte administrateur ou installe un logiciel malveillant. D’autres lui permettent d’accéder à la base de données, donc aux comptes et aux données des utilisateurs, ou d’injecter du contenu, comme des redirections malveillantes ou des pages de spam.
La menace propre à la zero-day tient au calendrier. Les outils de sécurité qui reconnaissent les attaques connues n’ont encore aucune règle pour celle-ci, et la mise à jour n’existe pas. Le site encaisse l’attaque avec ce qu’il avait déjà en place.
Zero-day ou faille connue non corrigée ?
Deux risques différents, qui ne se traitent pas avec les mêmes gestes.
Une faille dont le correctif est sorti mais n’a pas été appliqué n’est plus une zero-day. Le site reste exposé, mais par choix ou par oubli : la solution existe, il suffit de mettre à jour. C’est le risque que traite une mise à jour WordPress régulière, et celui qu’un contrat de maintenance doit fermer en quelques jours.
La zero-day est l’autre cas : même un site parfaitement à jour est exposé, puisque la version la plus récente contient encore la faille. Aucun réglage ne la fait disparaître. On ne peut que réduire ce qu’un attaquant atteint, retarder ce qu’il réussit et prévoir comment revenir en arrière.
Un site à jour n’est pas un site sans faille. Il est à jour par rapport à ce qui est connu et corrigé. C’est nécessaire, et c’est tout ce qu’une mise à jour peut promettre.
Des exemples de failles zero-day sur WordPress
Les plus graves visent des extensions répandues qui reçoivent des fichiers ou exécutent du code.
L’extension File Manager en est un cas documenté. La base nationale américaine des vulnérabilités indique que sa faille, enregistrée sous la référence CVE-2020-25213, permettait à un visiteur sans compte d’envoyer et d’exécuter du code PHP sur le site, et qu’elle a été exploitée en août et en septembre 2020. La version corrective 6.9 est datée du 1er septembre 2020 dans le journal des modifications de l’extension : les premières attaques ont donc précédé le correctif. L’agence américaine de cybersécurité l’a inscrite dans son catalogue des vulnérabilités activement exploitées.
Le cœur de WordPress n’est pas à l’abri pour autant. Le même catalogue compte trois failles du cœur ajoutées en 2026, dont deux qui, enchaînées, permettent l’exécution de code sans authentification sur une installation par défaut. Le cœur reste cependant la couche la plus surveillée et la plus vite corrigée, et ses versions de sécurité s’installent automatiquement.
Comment se protéger des attaques zero-day ?
En préparant le site à encaisser une faille qu’on ne connaît pas encore.
Installer moins
Chaque extension est une source possible de faille future. Supprimer celles qui ne servent plus, plutôt que les désactiver, réduit la surface d’attaque d’autant. Une extension abandonnée est la pire candidate : sa prochaine faille risque de ne jamais être corrigée.
Filtrer en amont
Un pare-feu applicatif web peut bloquer une forme d’attaque avant même que la faille soit corrigée, lorsque son éditeur diffuse une règle dès la publication. C’est l’une des rares protections qui agit pendant la fenêtre.
Mettre à jour dès que le correctif sort
La fenêtre se ferme côté éditeur à la publication du correctif, mais côté site seulement quand il est appliqué. Plus ce délai est court, moins la faille reste exploitable chez vous.
Limiter les droits
Une faille exploitée depuis un compte d’abonné fait moins de dégâts si personne n’a plus de droits que nécessaire. Le principe vaut aussi contre l’élévation de privilèges.
Pouvoir revenir en arrière
Une sauvegarde récente, stockée hors du serveur et déjà testée, transforme une intrusion en incident réparable. Sans elle, la restauration après piratage devient un nettoyage à l’aveugle.
Ce que montre un site réel
Relevé du 2 octobre 2026 sur ilti.fr, en lecture seule. Le site fait tourner trente extensions. Croisées avec la base publique wpvulnerability.net, dix-sept d’entre elles ont déjà fait l’objet d’au moins une faille publiée, deux cents au total sur leur histoire. Aucune ne touche les versions installées aujourd’hui. Deux extensions actives ont pourtant connu une vraie fenêtre sans correctif. Le 22 avril 2026, trois failles de l’extension qui gère les en-têtes de sécurité sont publiées pour toutes les versions jusqu’à la 1.19.2, marquées sans correctif. La version 1.19.2 datait de décembre 2024 : la faille existait donc depuis seize mois sans être connue. Les versions correctives sortent le 25 avril, trois jours plus tard. Le 23 juillet 2026, une injection SQL est publiée dans l’extension de tableaux et de graphiques, sans correctif lui non plus. La version 4.0.7 sort le 30 juillet, sept jours plus tard. Le site tourne aujourd’hui en 1.19.5 et en 4.0.9, hors de ces plages. Ce relevé ne dit pas à quelle date ces versions ont été installées, donc pas combien de jours le site lui-même a été exposé. Les mises à jour automatiques de WordPress sont désactivées pour vingt-neuf extensions sur trente : la durée de la fenêtre côté site dépend entièrement du rythme de la maintenance.
Questions fréquentes
Pourquoi parle-t-on de « zero day » ?
Parce que l’éditeur a eu zéro jour pour corriger la faille au moment où elle est exploitée ou rendue publique. L’expression vient de l’anglais et s’écrit aussi 0-day. En français, on lit parfois « faille du jour zéro ».
Une extension de sécurité détecte-t-elle une faille zero-day ?
Pas la faille elle-même, puisqu’aucune signature n’existe encore. Elle peut en revanche bloquer des comportements suspects, comme l’envoi d’un fichier PHP ou une requête anormale, et donner l’alerte si un fichier du site change. C’est une protection partielle, utile, mais pas une garantie.
Que faire si une faille sans correctif touche une extension que j’utilise ?
Désactiver l’extension si le site peut s’en passer quelques jours, ou la remplacer. Si elle est indispensable, vérifier qu’une règle de filtrage existe, surveiller les fichiers et les comptes administrateurs, et appliquer le correctif le jour de sa sortie.
Les failles zero-day sont-elles fréquentes sur un petit site ?
Elle ne choisit pas sa cible : un robot qui balaie le web frappe toutes les installations de l’extension touchée, quelle que soit leur taille. Un petit site est exposé dès qu’il utilise l’extension concernée, et il l’est plus longtemps si personne ne surveille la sortie du correctif.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.