DBIR 2026 : l'exploitation de failles devient la première porte d'entrée
par detektd team
Le Data Breach Investigations Report (DBIR) de Verizon est la référence annuelle sur la manière dont les intrusions se produisent réellement. L'édition 2026, publiée en mai, couvre les incidents survenus entre le 1er novembre 2024 et le 31 octobre 2025, soit plus de 22 000 violations de données confirmées dans 145 pays. Pour la première fois depuis que le rapport suit ce critère, la porte d'entrée la plus fréquente n'est ni le phishing ni le vol d'identifiants : c'est l'exploitation d'une vulnérabilité.
des intrusions analysées ont commencé par l'exploitation d'une vulnérabilité, contre 20 % un an plus tôt (Verizon DBIR 2026)
Le classement s'inverse
La part de l'exploitation passe de 20 % à 31 % des accès initiaux, une hausse de 55 % en un an. Le phishing tombe à 16 % et l'abus d'identifiants à 13 %. Les cibles les plus exploitées restent celles qui sont exposées à Internet par construction : applications web, VPN et équipements d'accès distant. Ces derniers ont d'ailleurs été regroupés dans une catégorie « réseau » à part, passée de 1,5 % à 5 % des intrusions.
Le reste du rapport confirme la tendance. Un rançongiciel est présent dans 48 % des intrusions (contre 44 %), même si 69 % des victimes ont refusé de payer et que la rançon médiane versée baisse à 139 875 dollars. Et un tiers (prestataire, éditeur, hébergeur) est impliqué dans 48 % des cas, une proportion en hausse d'environ 60 % sur un an.
Le vrai problème : la vitesse de correction
Verizon a croisé ses données avec celles de plus de 13 000 organisations, soit 527 millions d'occurrences de vulnérabilités (contre 68,7 millions en 2022). Le constat est net : parmi les failles figurant au catalogue KEV de la CISA, c'est-à-dire celles dont l'exploitation active est confirmée, seules 26 % ont été entièrement corrigées sur la période, contre 38 % l'année précédente. Le délai médian de correction passe de 32 à 43 jours, et sept jours après la publication, 60 à 70 % de ces failles sont encore ouvertes.
La mécanique est connue. Dès qu'un correctif sort, il suffit de comparer le code avant et après pour situer la faille, puis de balayer Internet à la recherche des serveurs qui exposent encore l'ancienne version. L'exemple récent de React2Shell le montre : publiée le 3 décembre 2025, cette faille des React Server Components avait une preuve de concept publique dès le lendemain, et entrait au catalogue KEV le 5 décembre. Le rapport ajoute un détail utile pour prioriser : la probabilité de réexploitation d'une faille diminue environ de moitié à 30 jours, puis à 90 jours, puis vers neuf mois. Les premières semaines sont donc décisives.
des failles activement exploitées ont été entièrement corrigées sur l'année, contre 38 % un an plus tôt (Verizon DBIR 2026)
Ce que ça change pour une application web
Une application web cumule les deux facteurs du rapport : elle est exposée en permanence, et elle repose sur une pile de composants tiers (framework, CMS, bibliothèques, serveur) dont chacun a son propre calendrier de failles. La première difficulté n'est pas de corriger, mais de savoir ce qui tourne réellement en production. Une version figée dans un fichier de verrouillage, une image Docker qui n'a pas été reconstruite ou un sous-domaine de préproduction oublié suffisent à garder une faille ouverte longtemps après le correctif.
# JavaScript: known advisories for the installed tree npm audit --omit=dev # Any ecosystem: OSV database (npm, PyPI, Go, Maven, Composer...) osv-scanner scan source -r . # Which of those are actively exploited? CISA's KEV feed curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \ | jq -r '.vulnerabilities[] | select(.dateAdded >= "2026-09-01") | .cveID + " " + .product'
- Tenez un inventaire de ce qui est exposé : domaines, sous-domaines, versions de framework et de CMS réellement servies.
- Priorisez par exploitation réelle (KEV, score EPSS) plutôt que par le seul score CVSS : une faille « moyenne » exploitée passe avant une faille « critique » théorique.
- Fixez-vous un délai cible pour les failles exploitées, de l'ordre de quelques jours, et automatisez les mises à jour de sécurité (Dependabot, Renovate) pour l'atteindre.
- Réduisez ce qui trahit vos versions (en-têtes X-Powered-By et Server, balise meta generator, fichiers de build publics) : cela ne corrige rien, mais retire une cible facile aux scans de masse.
Ce que detektd vérifie
detektd voit votre application comme un attaquant la voit depuis Internet. Il identifie les frameworks et CMS servis et leur version quand elle est visible, les compare aux failles connues (dont React2Shell, les CVE de Next.js, d'Angular ou de WordPress), et repère les surfaces qui ne devraient pas être publiques : consoles d'administration, tableaux de bord, fichiers de build ou de configuration exposés. Avec la surveillance hebdomadaire, ces vérifications sont relancées chaque semaine, avec les failles ajoutées entre deux scans.
Certificats TLS : de 398 à 47 jours, le renouvellement manuel a vécu
Depuis le 15 mars 2026, un certificat public ne peut plus dépasser 200 jours. Ce sera 100 jours en 2027 et 47 jours en 2029, et Let's Encrypt descendra à 45 jours dès 2028. Le calendrier, les raisons, et ce qu'il faut automatiser pour qu'un certificat expiré ne coupe plus jamais votre site.
Quand un prompt devient un shell : ce que Microsoft a trouvé dans les frameworks d'agents
En mai, l'équipe de recherche Microsoft Defender a publié deux CVE critiques dans Semantic Kernel, où une injection de prompt pouvait aboutir à une exécution de code sur la machine hôte. Le problème ne se limite pas à un framework.