66 000 vulnérabilités prévues en 2026 : pourquoi le risque se concentre sur les sites que vous avez oubliés
Le 15 juin, la fondation FIRST a révisé sa prévision annuelle de divulgation de vulnérabilités. Elle attend maintenant environ 66 000 vulnérabilités publiées en 2026, contre une médiane de 59 427 annoncée quatre mois plus tôt. C'est un rythme qui approche les 70 000, du jamais vu.
Précisons tout de suite l'échelle : ce chiffre couvre l'ensemble des logiciels répertoriés, des systèmes d'exploitation aux équipements réseau. Il ne s'agit pas de 66 000 failles dans les sites web.
Le réflexe naturel, en lisant ce genre de chiffre, est de se demander si son site est à jour.
Ce n'est pourtant pas la bonne question. La bonne question, c'est plutôt : de combien de sites parle-t-on exactement?
Parce que la plupart des organisations avec qui nous travaillons ont plus d'éléments en ligne sous leur nom de domaine qu'elles ne le croient. Et ce sont précisément ceux-là qui posent problème.
Ce que FIRST a publié le 15 juin
La révision est importante : les divulgations réelles sont 46,3 % au-dessus de la projection de février, avec 6 420 vulnérabilités excédentaires enregistrées jusqu'en avril seulement.
FIRST attribue cette hausse à trois facteurs, et aucun n'est une dégradation de la qualité des logiciels :
- la découverte de vulnérabilités assistée par intelligence artificielle;
- une augmentation de 449 % en un an du volume d'avis de sécurité publiés par GitHub;
- une hausse de 3 119 % de l'activité de VulnCheck comme autorité d'attribution de dernier recours, qui a absorbé un important arriéré de vulnérabilités non assignées.
Autrement dit, la capacité de l'industrie à trouver et à documenter des failles vient de changer d'échelle. Éireann Leverett, qui pilote l'équipe de prévision de FIRST, résume la situation en disant que le défi pour les équipes de défense n'est plus la découverte des vulnérabilités, mais la capacité à les vérifier et à les prioriser à une échelle inédite.
Et voici la nuance que la plupart des manchettes ont escamotée.
Quand on filtre ces vulnérabilités pour ne garder que celles qui présentent un risque réel, la charge de correction n'a pas augmenté de façon significative. FIRST le mesure en croisant deux références : le catalogue des vulnérabilités activement exploitées de la CISA, et le score EPSS, qui estime la probabilité qu'une faille soit exploitée. Sur cette base, la proportion de cas véritablement urgents reste stable.
Le volume explose. Le risque exploitable, beaucoup moins.
Ce qui déplace complètement la question. Si la majorité des nouvelles failles ne vous concernent pas, l'enjeu n'est plus de suivre le volume. L'enjeu est de savoir précisément ce que vous exposez, pour pouvoir déterminer rapidement si une faille donnée vous touche.
Le problème n'est pas la découverte, c'est le délai
Le rapport d'enquête sur les compromissions de données de Verizon, publié le 19 mai, appuie ce constat par l'autre bout.
Pour la première fois en dix-neuf éditions, l'exploitation d'une vulnérabilité est devenue le principal vecteur d'accès initial dans les compromissions analysées : 31 % des cas, contre 20 % l'année précédente. Elle dépasse maintenant l'abus d'identifiants, longtemps en tête.
Le même rapport indique que seulement 26 % des vulnérabilités inscrites au catalogue des failles activement exploitées de la CISA avaient été entièrement corrigées en 2025, en baisse par rapport à 38 % l'année précédente. Le délai médian pour une résolution complète est passé de 32 à 43 jours.
Mettez les deux constats côte à côte. Les failles sont découvertes plus vite que jamais, et elles sont corrigées plus lentement qu'avant. C'est dans cet écart que les attaques se produisent.
Maintenant, posez-vous la question honnêtement : sur quel actif de votre organisation ce délai de correction est-il le plus long?
Ce n'est presque jamais le site principal. C'est celui dont plus personne ne s'occupe.
Ce que nous retrouvons lors des audits
Quand nous reprenons un environnement existant, que ce soit dans le cadre d'une migration ou d'un nouveau mandat d'entretien, certaines catégories reviennent avec une régularité frappante.
Des environnements de préproduction toujours accessibles. Créés pour valider une refonte, jamais fermés après la mise en ligne. Souvent sans mot de passe, parfois indexés par les moteurs de recherche.
Des sous-domaines de campagnes terminées. Un microsite pour un événement de 2022, une page de campagne saisonnière, un formulaire d'inscription pour un programme qui n'existe plus.
D'anciennes versions du site conservées au cas où. Généralement dans un sous-répertoire ou un sous-domaine, avec une version du gestionnaire de contenu figée à la date de la refonte, donc sans aucune mise à jour de sécurité depuis.
Des enregistrements DNS qui pointent vers des services résiliés. Un ancien outil d'infolettre, une plateforme d'hébergement de pages abandonnée, un service de formulaires que personne n'utilise plus.
Ce dernier cas mérite une explication, parce que le mécanisme est moins connu et que les conséquences sont sérieuses.
Le cas des enregistrements DNS orphelins
Un enregistrement DNS orphelin est une entrée qui continue de résoudre vers une ressource qui n'existe plus. Le service a été fermé, mais l'enregistrement, lui, est resté.
Sur beaucoup de plateformes, les noms de ressources sont attribués au premier arrivé. Si votre ancien sous-domaine pointe encore vers un nom disponible chez le fournisseur, n'importe qui peut réclamer ce nom et se mettre à servir du contenu depuis votre sous-domaine. Avec votre nom de domaine dans la barre d'adresse, et souvent avec votre certificat de sécurité.
Ce n'est pas une hypothèse théorique. Des chercheurs de watchTowr ont réenregistré environ 150 espaces de stockage Amazon S3 abandonnés, précédemment utilisés dans des produits logiciels commerciaux et libres, dans des systèmes gouvernementaux et dans des chaînes de déploiement. Le coût total de l'opération : 420,85 $ US. En deux mois, ces espaces abandonnés ont reçu plus de huit millions de requêtes, notamment pour des mises à jour logicielles, des binaires non signés, des images de machines virtuelles et des fichiers de configuration. Les requêtes provenaient d'agences gouvernementales de plusieurs pays, de réseaux militaires, d'institutions financières, d'universités et même d'entreprises de cybersécurité.
Un détail du rapport résume bien le phénomène : un des espaces avait été abandonné en 2015 et recevait toujours des requêtes dix ans plus tard.
À l'échelle d'une PME ou d'un organisme, on ne parle évidemment pas de huit millions de requêtes. Mais le mécanisme est identique, et l'effort requis pour trouver ces enregistrements est asymétrique. L'énumération de sous-domaines et la vérification des enregistrements se font de façon automatisée, à grande échelle. La vérification manuelle, elle, dépend de quelqu'un qui se souvient d'un enregistrement créé il y a trois ans, souvent par une personne qui a quitté l'organisation depuis.
Le scénario le plus coûteux : la préproduction avec de vraies données
Il y a un cas particulier qui transforme un oubli technique en enjeu de conformité.
Un environnement de préproduction est censé reproduire la production. En pratique, cela veut souvent dire qu'il contient une copie de la base de données. Avec les vrais membres, les vrais dons, les vraies inscriptions, les vrais formulaires remplis par de vraies personnes.
Cet environnement a rarement le même niveau de surveillance, de contrôle d'accès et de mise à jour que le site principal.
Au Québec, si cet environnement est compromis, vous n'avez plus seulement un problème technique à régler discrètement. Selon ce qui s'est effectivement produit, la situation peut constituer un incident de confidentialité au sens de la Loi 25, par exemple si des renseignements personnels ont fait l'objet d'un accès ou d'un usage non autorisé.
Et c'est là que le travail commence, parce que cette qualification ne se devine pas. Il faut établir ce qui a été accessible, évaluer si l'incident présente un risque de préjudice sérieux et, le cas échéant, en aviser la Commission d'accès à l'information ainsi que les personnes concernées. La Loi 25 exige par ailleurs la tenue d'un registre des incidents de confidentialité, à conserver au moins cinq ans, dont la Commission peut demander une copie.
Autrement dit, même dans le scénario favorable où l'analyse conclut à l'absence de préjudice sérieux, il faut avoir fait l'analyse et l'avoir consignée.
Le coût réel d'une préproduction oubliée n'est donc pas le coût du nettoyage. C'est le coût du nettoyage, plus celui de la conformité, plus le temps de direction consacré à une situation qui n'aurait jamais dû exister.
Faire l'inventaire, concrètement
La bonne nouvelle, c'est que cet exercice n'est ni long ni coûteux. Il est simplement rarement fait, parce que personne n'en est clairement responsable.
Voici la démarche que nous suivons.
- Lister tous les enregistrements DNS du domaine. Pas seulement ceux dont vous vous souvenez. L'ensemble de la zone, chez votre registraire ou votre fournisseur DNS.
- Vérifier ce qui répond encore. Pour chaque entrée, déterminer si la destination existe toujours et si elle vous appartient toujours. Une entrée qui pointe vers un service que vous avez résilié est à traiter en priorité.
- Attribuer un propriétaire à chaque élément, et investiguer ceux qui n'en ont pas. Un actif que personne ne reconnaît n'est pas un actif à supprimer rapidement. C'est celui qu'il faut comprendre en premier, et supprimer en dernier. Une entrée DNS non identifiée peut très bien être une validation de domaine pour un service de paiement, un enregistrement de courriel ou une dépendance de votre plateforme d'infolettre. La supprimer sans vérifier casse une fonction en production.
- Décider ensuite : réduire l'exposition, maintenir, ou retirer. Trois choses distinctes, qu'il vaut mieux ne pas confondre. Restreindre l'accès à un environnement réduit son exposition, mais un environnement toujours accessible, même derrière une authentification, doit continuer de recevoir ses mises à jour de sécurité. Et retirer un environnement de l'indexation empêche du contenu de test d'apparaître dans les résultats de recherche, ce qui est utile, mais ne constitue pas une protection : les outils qui recherchent des cibles vulnérables n'utilisent pas les moteurs de recherche, ils énumèrent directement les noms d'hôtes. Ce qui ne sert plus doit finir par être retiré, pas simplement mis de côté.
- Respecter l'ordre des opérations lors d'une suppression. Retirer l'enregistrement DNS d'abord, attendre l'expiration de la durée de vie de la mise en cache, puis supprimer la ressource. C'est la recommandation d'AWS et elle vaut pour n'importe quel fournisseur : l'ordre inverse crée une fenêtre pendant laquelle l'enregistrement pointe vers un nom devenu disponible.
- Purger les données sensibles des environnements de test. Une préproduction n'a presque jamais besoin des vraies coordonnées de vos membres pour valider une mise en page.
Ce que nous en retenons
La prévision de FIRST va faire les manchettes tout l'été, et la lecture facile sera celle de la panique. Ce n'est pas la nôtre.
Le volume de vulnérabilités publiées augmente fortement, mais la part qui exige une intervention rapide reste stable. Ce qui change vraiment, c'est que le coût de trouver une cible exposée continue de baisser, pendant que le délai moyen de correction, lui, augmente.
Dans ce contexte, l'écart de risque entre deux organisations ne se joue pas sur la qualité de leur site principal. Il se joue sur ce qu'elles savent de leur propre surface d'exposition.
C'est une question à laquelle il vaut la peine de pouvoir répondre avant l'automne, plutôt qu'un mardi matin de crise.
Vous ne savez plus exactement ce qui est encore accessible sous votre nom de domaine? Écrivez-nous, nous pouvons faire cet exercice avec vous. Concrètement, nous regardons les domaines et sous-domaines actifs, les environnements de préproduction et les anciens sites, les enregistrements DNS pointant vers des services tiers, et nous établissons avec vous qui est responsable de chaque élément. Vous en ressortez avec une liste de ce que vous exposez réellement et une recommandation pour chaque cas.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sources
Article rédigé le 25 juin 2026. Les données citées reflètent l'information disponible à cette date.
Prévision de vulnérabilités de FIRST (15 juin 2026)
- FIRST, communiqué de la prévision de mi-année 2026 (projection de 66 000 CVE, dérive de 46,3 %, 6 420 CVE excédentaires jusqu'en avril, hausse de 449 % du volume d'avis GitHub, hausse de 3 119 % de l'activité de VulnCheck, exploitabilité réelle stable une fois filtrée par le catalogue KEV de la CISA ou un score EPSS supérieur à 10 %)
- FIRST, billet de l'équipe de prévision
- FIRST, prévision initiale de février 2026 (médiane de 59 427 CVE)
- SecurityBrief, synthèse de la révision (citation d'Éireann Leverett)
Rapport d'enquête sur les compromissions de données de Verizon (19 mai 2026)
- Help Net Security, principaux constats du DBIR 2026 (première fois en dix-neuf éditions que l'exploitation de vulnérabilités devance le vol d'identifiants)
- watchTowr, analyse du DBIR 2026 (31 % des accès initiaux, contre 20 % l'année précédente)
- Nucleus Security, analyse du DBIR 2026 (26 % des vulnérabilités du catalogue KEV corrigées en 2025 contre 38 %, délai médian de résolution passé de 32 à 43 jours)
Ressources abandonnées et enregistrements DNS orphelins
- The Record, recherche de watchTowr sur les espaces de stockage S3 abandonnés (environ 150 espaces réenregistrés, plus de huit millions de requêtes en deux mois)
- CSO Online, analyse détaillée de la même recherche (espace abandonné en 2015 recevant toujours des requêtes dix ans plus tard)
- SANS NewsBites, synthèse de la recherche (coût total de 420,85 $ US pour le réenregistrement)
- Censys, mécanisme de la prise de contrôle de sous-domaine (asymétrie entre l'énumération automatisée et la vérification manuelle)
- AWS, prévention de la prise de contrôle de sous-domaine (ordre des opérations : retirer le DNS, attendre l'expiration de la durée de vie, puis supprimer la ressource)
Loi 25 (Québec)
