Les chercheurs en sécurité publient du code d’exploitation pour aider les défenseurs à comprendre les vulnérabilités. Les attaquants lisent les mêmes instructions et certains les mettent en pratique avant que les équipes de sécurité aient fini d’évaluer le risque.
Dans un cas, des hackers ont exploité une vulnérabilité seulement 35 minutes après que le code public de preuve de concept (PoC) est devenu disponible, selon une nouvelle étude de CrowdStrike.
L’entreprise de cybersécurité a constaté que 91 % des vulnérabilités associées à des PoC publics qu’elle a observées comme exploitées entre janvier et juillet 2026 avaient été attaquées dans les 48 heures suivant la publication du PoC. Le délai médian avant exploitation était inférieur à un jour.
Publiés le 5 novembre, ces résultats mettent en évidence un défi croissant pour les équipes de sécurité : les recherches sur les vulnérabilités accessibles au public peuvent accélérer les attaques contre des systèmes qui n’ont pas encore été corrigés.
- Selon CrowdStrike, l’exploitation commence en quelques heures
- La faille de cPanel montre comment les recherches publiques peuvent accélérer les attaques
- Des hackers liés au Bélarus adaptent un exploit Linux en moins d’un jour
- Un acteur lié à l’Iran découvert avec un exploit Fortinet modifié
- L’IA pourrait accélérer le développement des exploits
- Que doivent faire les équipes de sécurité lorsque les fenêtres de correction se réduisent
- Les recherches publiques sur les vulnérabilités créent un compromis en matière de sécurité
Selon CrowdStrike, l’exploitation commence en quelques heures
Dans son analyse des délais de militarisation des vulnérabilités, CrowdStrike a examiné les exploitations observées par son équipe Counter Adversary Operations entre janvier et juillet 2026.
L’entreprise a fait état de trois conclusions clés :
Conclusion | Observation de CrowdStrike |
| Exploitation la plus rapide observée | 35 minutes après la publication du PoC public |
| Délai médian avant exploitation | Moins de 24 heures |
| Exploitation dans les 48 heures | 91 % des vulnérabilités observées comme exploitées et associées à des PoC publics |
Ces chiffres concernent les vulnérabilités dont CrowdStrike a observé l’exploitation par des attaquants et pour lesquelles des PoC publics étaient disponibles. Ils ne signifient pas que 91 % de toutes les vulnérabilités divulguées ont été exploitées.
Le précédent rapport de CrowdStrike, 2026 Threat Hunting Report a établi que 88 % des vulnérabilités observées comme exploitées et associées à des PoC publics avaient été attaquées dans les 48 heures entre janvier et juin.
La nouvelle analyse prolonge cette période d’observation jusqu’en juillet.
Selon CrowdStrike, les avis de sécurité publics, les analyses techniques, les outils de balayage et les exemples d’exploitation peuvent réduire les efforts nécessaires au développement d’attaques.
Les attaquants moins expérimentés peuvent adapter du code existant, tandis que les groupes plus compétents peuvent s’appuyer sur les recherches publiées pour accélérer leurs opérations.
Trois cas impliquant des produits cPanel, Linux et Fortinet illustrent la façon dont les attaquants utilisent ces informations.
La faille de cPanel montre comment les recherches publiques peuvent accélérer les attaques
Le premier cas concernait CVE-2026-41940, une vulnérabilité de contournement de l’authentification affectant certaines versions de cPanel, WebHost Manager (WHM) et WordPress Squared.
La faille pouvait permettre à un attaquant distant non authentifié d’obtenir un accès non autorisé aux panneaux de contrôle concernés.
CrowdStrike a établi la chronologie suivante :
Date | Événement |
| 3 avril | La première exploitation présumée est identifiée au moyen d’une enquête rétrospective |
| 28 avril | cPanel divulgue publiquement CVE-2026-41940 |
| 29 avril | Des chercheurs publient des instructions techniques d’exploitation et un générateur d’artefacts de détection |
| 30 avril | CrowdStrike commence à observer une exploitation opportuniste à grande échelle |
CrowdStrike a analysé le générateur d’artefacts de détection publié et constaté qu’une légère modification du code pouvait le transformer en exploit fonctionnel.
Le code modifié pouvait changer le mot de passe root, permettant à un attaquant d’accéder au terminal WHM avec des privilèges root.
L’entreprise a déclaré que la plupart, voire la totalité, des exploitations observées par la suite suivaient les techniques décrites dans les recherches publiées.
Toutefois, son enquête rétrospective a également trouvé des éléments indiquant qu’un seul attaquant exploitait probablement la vulnérabilité en tant que zero-day depuis au moins le 3 avril.
CrowdStrike n’a pas déterminé comment cet attaquant avait initialement découvert la faille ou obtenu un exploit.
La distinction est importante. La divulgation publique n’a pas nécessairement déclenché la première attaque, mais les conclusions de CrowdStrike suggèrent que la publication technique ultérieure a contribué à étendre l’exploitation.
L’entreprise a indiqué que plusieurs acteurs malveillants ciblaient parfois les mêmes systèmes cPanel vulnérables, créant une concurrence pour l’accès.
Des hackers liés au Bélarus adaptent un exploit Linux en moins d’un jour
Le deuxième cas concernait CopyFail, suivi sous la référence CVE-2026-31431, une vulnérabilité Linux d’élévation de privilèges en local.
Des chercheurs ont publié des détails techniques et un code PoC le 29 avril.
Bien que la faille ait déjà été corrigée dans le noyau Linux principal, CrowdStrike a indiqué que de nombreuses distributions Linux majeures n’avaient pas encore reçu les correctifs.
Ses chercheurs ont confirmé que l’exploit fonctionnait contre un système Ubuntu 24.04 entièrement corrigé à ce moment-là.
Le 30 avril, CrowdStrike a observé l’acteur malveillant UMBRAL BISON, lié au Bélarus, utiliser une version modifiée de l’exploit public contre une organisation gouvernementale ukrainienne.
L’attaque a élevé les privilèges du compte du serveur web www-data à root.
Grâce à ces privilèges élevés, les attaquants ont déployé un agent de commande et de contrôle Poseidon associé au framework Mythic.
CrowdStrike a indiqué que son capteur Falcon avait interrompu l’agent lors de son exécution.
Les attaquants avaient également modifié le PoC d’origine pour améliorer son efficacité.
Selon CrowdStrike, ces modifications comprenaient :
- Exécution à l’exécution : déplacement de la logique principale de l’exploit dans une chaîne évaluée pendant l’exécution, ce qui rend certaines techniques d’analyse statique moins efficaces.
- Gestion des erreurs : ajout d’une gestion structurée pour améliorer la fiabilité.
- Adaptation opérationnelle : modification de code accessible au public pour l’utiliser contre des cibles réelles.
Ce cas montre comment les attaquants peuvent adapter des recherches existantes en une journée, plutôt que de développer un exploit à partir de zéro.
Un acteur lié à l’Iran découvert avec un exploit Fortinet modifié
CrowdStrike a également identifié un exploit modifié ciblant CVE-2024-55591, une vulnérabilité de contournement de l’authentification affectant Fortinet FortiOS et FortiProxy.
En février 2026, des chercheurs ont découvert un répertoire exposé contrôlé par l’acteur malveillant STATIC KITTEN, lié à l’Iran.
Le répertoire contenait environ 1,9 Go de données réparties sur plus de 20 000 fichiers, dont une version modifiée d’un exploit publié pour la vulnérabilité Fortinet.
Le PoC d’origine, publié en janvier 2025, était conçu pour exécuter une seule commande fournie par l’utilisateur.
La version modifiée contenait 13 charges utiles codées en dur conçues pour effectuer des actions supplémentaires, notamment :
- Énumération des comptes utilisateurs et des groupes.
- Création de comptes administrateur.
- Modification des autorisations d’accès.
- Établissement d’un accès persistant par l’intermédiaire de comptes de porte dérobée.
Certaines charges utiles créaient des comptes dotés de privilèges élevés, ce qui pouvait permettre aux attaquants de conserver l’accès aux systèmes compromis.
Toutefois, CrowdStrike n’a pas pu déterminer si STATIC KITTEN avait modifié l’exploit lui-même ou obtenu le code modifié ailleurs.
L’entreprise a également indiqué qu’elle n’avait pas observé d’autres acteurs malveillants utiliser cet exploit modifié précis ou l’infrastructure qui l’hébergeait.
Contrairement aux cas de cPanel et de CopyFail, la découverte concernant Fortinet n’établit pas que le code modifié a été déployé lors d’une intrusion confirmée.
Elle montre toutefois comment un exploit public peut être transformé, d’un outil de démonstration, en un code doté de multiples capacités associées à l’accès non autorisé et à la persistance.
L’IA pourrait accélérer le développement des exploits
CrowdStrike a également examiné comment l’intelligence artificielle pourrait accélérer la découverte et l’exploitation des vulnérabilités.
L’entreprise s’attend à ce que les attaquants utilisent de plus en plus des outils d’IA pour analyser les vulnérabilités, adapter le code des exploits et intégrer des recherches de sécurité assistées par l’IA publiées par d’autres.
Elle a identifié trois approches possibles :
- Tenter de contourner les garde-fous des modèles d’IA avancés afin d’obtenir une assistance offensive.
- Modifier des modèles à poids ouverts pour affaiblir ou supprimer les garde-fous.
- Réutiliser des recherches sur les vulnérabilités développées avec l’aide de l’IA et publiées par des chercheurs en sécurité.
Toutefois, CrowdStrike a reconnu qu’il reste difficile d’identifier l’implication directe de l’IA dans un exploit précis.
Un code bien structuré, des commentaires détaillés et des améliorations apportées à des PoC existants peuvent suggérer l’aide de l’IA, mais des développeurs humains expérimentés peuvent produire des résultats similaires.
L’entreprise a cité CopyFail et la vulnérabilité WordPress connue sous le nom de wp2shell comme exemples de recherches ayant, selon les informations disponibles, impliqué une assistance de l’IA.
Ces informations n’établissent pas que les attaquants étudiés par CrowdStrike ont directement utilisé l’IA lors de leurs intrusions.
La préoccupation la plus immédiate est que des recherches sur les vulnérabilités de plus en plus accessibles, qu’elles soient développées par des humains ou avec l’aide de l’IA, puissent réduire le temps nécessaire à la production d’exploits fonctionnels.
Que doivent faire les équipes de sécurité lorsque les fenêtres de correction se réduisent
Les conclusions de CrowdStrike soulèvent des questions sur les stratégies de gestion des vulnérabilités qui reposent principalement sur les scores de gravité et les cycles de correction planifiés.
Un score élevé du Common Vulnerability Scoring System (CVSS) indique la gravité technique, mais n’établit pas nécessairement si des attaquants exploitent activement une vulnérabilité.
Les organisations doivent également prendre en compte la disponibilité publique d’un exploit, l’exposition, la facilité d’exploitation et les signes d’une activité malveillante.
Pour les défenseurs, cette étude fait ressortir plusieurs priorités :
Priorité | Action recommandée |
| Identifier les systèmes exposés | Tenir à jour un inventaire précis des actifs accessibles depuis Internet et des logiciels concernés |
| Surveiller les exploits publics | Suivre les PoC récemment publiés, les recommandations d’exploitation et les renseignements pertinents sur les menaces |
| Hiérarchiser selon le risque réel | Prendre en compte l’exploitation active, la disponibilité d’un exploit, l’exposition et l’impact sur l’activité, en complément du CVSS |
| Appliquer des protections temporaires | Utiliser les mesures d’atténuation prises en charge par le fournisseur, les restrictions d’accès ou l’isolation lorsqu’une correction immédiate n’est pas possible |
| Rechercher les signes d’une compromission éventuelle | Examiner les activités suspectes lorsque l’exploitation a pu commencer avant la remédiation |
| Vérifier la remédiation | Confirmer que les correctifs et les mesures compensatoires fonctionnent comme prévu |
Ces mesures ne peuvent pas garantir une protection contre les attaques qui commencent quelques minutes après la publication du code d’exploitation.
Elles peuvent aider les organisations à identifier plus rapidement les expositions à haut risque et à réduire les possibilités d’action des attaquants pendant le déploiement des correctifs définitifs.
Les capacités de détection et de réponse sont également importantes lorsque l’exploitation commence avant l’application d’un correctif.
Les recherches publiques sur les vulnérabilités créent un compromis en matière de sécurité
Les recherches publiques sur les vulnérabilités restent essentielles pour aider les défenseurs à comprendre les faiblesses des logiciels, à valider les protections et à élaborer des correctifs.
Mais ces mêmes détails techniques peuvent également fournir aux attaquants du code réutilisable et des recommandations d’exploitation.
Les conclusions de CrowdStrike illustrent les deux aspects de ce problème.
Le cas de cPanel suggère que les recherches publiques peuvent accélérer l’exploitation déjà en cours. L’incident CopyFail montre à quelle vitesse les attaquants peuvent modifier un PoC récemment publié, tandis que la découverte concernant Fortinet démontre comment un code d’exploitation existant peut être enrichi de capacités supplémentaires.
Les conclusions n’établissent pas que les chercheurs doivent cesser de publier des informations sur les vulnérabilités. Elles renforcent plutôt l’importance de la divulgation coordonnée, d’une remédiation rapide et de capacités de détection tenant compte de la rapidité des exploitations.
Pour les équipes de sécurité, la principale leçon est qu’un PoC nouvellement publié doit être considéré comme un signal urgent invitant à évaluer l’exposition.
Lorsqu’une organisation entame son prochain cycle de correction planifié, les attaquants utilisent peut-être déjà ce code.
Autre information : Des hackers ont manipulé les réglages de réfrigération de trois établissements français de banques de sang par l’intermédiaire d’une compromission chez un fournisseur tiers, mais les systèmes de surveillance ont détecté les changements avant qu’aucun produit sanguin ne soit endommagé.