Monthly Threat Report Juillet 2026

Introduction

Le Rapport mensuel sur les menaces de Hornetsecurity by Proofpoint présente chaque mois des analyses sur les tendances de sécurité M365, les menaces véhiculées par email et l’actualité de la cybersécurité. Cette édition porte sur les événements du secteur survenus en juin 2026. Comme il s’agit d’une édition consacrée à l’actualité et aux commentaires, le rapport privilégie ce mois-ci une analyse approfondie des menaces émergentes et des recherches du secteur plutôt que des sections statistiques.

Un même thème relie la plupart des sujets abordés : l’intelligence artificielle participe désormais activement aux deux côtés de l’équation de sécurité. Des chercheurs ont documenté la première opération de ransomware menée de bout en bout par un agent d’IA autonome. Microsoft a publié le plus important Patch Tuesday de l’histoire du programme, une hausse du volume attribuée en partie à la découverte de vulnérabilités assistée par l’IA. De son côté, notre Threat Intelligence Lab a suivi un kit de phishing usurpant une marque et conçu pour la prise de contrôle de comptes à grande échelle. Enfin, nous présentons la nouvelle génération de la spécification DMARC, qui arrive à un moment opportun alors que les pressions liées à l’usurpation et à l’authentification continuent de s’intensifier.

Résumé exécutif

• Des chercheurs ont documenté JadePuffer, la première opération de ransomware rendue publique et menée de bout en bout par un agent autonome reposant sur un grand modèle de langage (LLM). L’agent a pris en charge la reconnaissance, le vol d’identifiants, les mouvements latéraux, l’élévation de privilèges et le chiffrement sans intervention humaine. Il a exploité CVE-2025-3248 dans Langflow pour l’accès initial et CVE-2021-29441 dans Alibaba Nacos pendant l’intrusion. Il a chiffré 1 342 éléments de configuration de service et, dans une séquence documentée, a diagnostiqué puis corrigé un échec de connexion en 31 secondes.
• Le Patch Tuesday de Microsoft de juin a corrigé plus de 200 vulnérabilités, soit la plus importante publication unique de l’histoire du programme. Elle comprenait notamment une vulnérabilité zero-day activement exploitée dans Exchange Server. CVE-2026-42897 permet à un attaquant non authentifié d’exécuter du JavaScript arbitraire dans la session Outlook Web Access d’une victime au moyen d’un email spécialement conçu. Exchange Server 2016, 2019 et Subscription Edition sur site sont concernés.
• Notre Threat Intelligence Lab a analysé une campagne de phishing imitant la procédure de vérification de Meta et ciblant les propriétaires et administrateurs francophones de Pages Facebook. Le kit exploite la crédibilité des badges de vérification pour collecter non seulement des identifiants, mais aussi des codes d’authentification multifacteur (MFA) et des documents d’identité. Cela révèle un objectif de prise de contrôle complète du compte, et non un simple vol d’identifiants.
• Le volume record de correctifs a été attribué en partie à la découverte de vulnérabilités assistée par l’IA, la même catégorie de capacité que celle présentée dans notre rapport du mois dernier sur le Project Glasswing d’Anthropic. La convergence entre la découverte accélérée par l’IA et les intrusions menées par l’IA réduit le délai entre la découverte d’une faille et son exploitation.
• L’IETF a publié une spécification DMARC de nouvelle génération (RFC 9989), qui remplace la RFC 7489 d’origine. Cette mise à jour normalise la découverte du domaine de l’entreprise, clarifie l’héritage et l’alignement des politiques, et répartit les rapports dans des spécifications complémentaires. Elle intervient alors que les fournisseurs de boîtes aux lettres renforcent leurs exigences d’authentification des expéditeurs.

Vue d’ensemble des menaces

Phishing lié à la vérification Meta : la confiance envers une marque détournée pour prendre le contrôle de comptes

Notre Threat Intelligence Lab a identifié et analysé une campagne de phishing usurpant l’identité de Meta afin de cibler les propriétaires et administrateurs francophones de Pages Facebook, les petites entreprises et les équipes marketing. Notre analyse technique complète est disponible sur le blog de sécurité Hornetsecurity. Cette campagne se distingue pour deux raisons : elle s’appuie sur un prétexte positif plutôt que sur une menace, et elle va bien au-delà du vol d’identifiants pour viser une prise de contrôle complète du compte.

La plupart des campagnes de phishing qui usurpent l’identité d’une plateforme commencent par susciter la peur, généralement au moyen d’un avertissement indiquant qu’un compte a été suspendu ou qu’il sera supprimé. Cette campagne inverse ce schéma. L’appât propose au destinataire quelque chose de souhaitable, la possibilité d’obtenir un badge de verification, et l’associe à un délai peu contraignant, avec une invitation à « activer sous 24 heures ». La confiance, la récompense et une légère urgence forment un prétexte qu’un administrateur de Page très occupé aura plus de mal à écarter.

Chaîne d’attaque

Étape 1 : l’attaquant diffuse des emails de phishing via la plateforme AppSheet de Google, profitant de la réputation d’envoi d’un service Google légitime pour améliorer la délivrabilité et contourner les filtres de réputation basiques.

Étape 2 : les destinataires qui cliquent sont redirigés via le domaine sw[.]run vers une fausse interface du Centre de comptes Meta, hébergée sur l’infrastructure de l’attaquant à l’adresse finn2[.]xyz.

Étape 3 : la page de destination demande les informations progressivement plutôt que toutes à la fois. Elle sollicite successivement les informations de la Page, les données personnelles, les identifiants Facebook, les codes MFA et les documents d’identité. Cette approche par étapes imite un véritable processus de vérification et réduit le risque que la victime abandonne.

Étape 4 : les données collectées sont chiffrées côté client au moyen de clés Advanced Encryption Standard (AES) codées en dur, puis stockées temporairement dans le localStorage du navigateur sous les clés __ck_clv1 à __ck_clv6. Elles sont ensuite exfiltrées sous forme de profils de victimes chiffrés vers un endpoint backend situé à /api/authentication. Le kit effectue également des recherches externes sur l’adresse IP et la géolocalisation via apip[.]cc afin d’enrichir chaque fiche de victime.

Le kit inclut une prise en charge configurable de douze langues : anglais, allemand, français, espagnol, italien, néerlandais, portugais, russe, chinois, vietnamien, japonais et coréen. Cela indique une opération conçue pour être réutilisée dans des régions bien au-delà des cibles francophones observées.

Indicateurs de compromission (IOC)

Infrastructure contrôlée par l’attaquant :

• hxxps://sw[.]run (redirection)
• hxxps://finn2[.]xyz (faux Centre de comptes Meta)

Diffusion et enrichissement :

• Emails de phishing envoyés via Google AppSheet
• Enrichissement des données de la victime via apip[.]cc

Artefacts sur l’hôte :

• Clés de stockage local __ck_clv1 à __ck_clv6
• Endpoint d’exfiltration /api/authentication

Pourquoi est-ce important ?

La collecte de codes MFA et de documents d’identité est l’élément qui distingue cette campagne d’un phishing d’identifiants classique. La récupération d’un mot de passe ne donne à l’attaquant qu’un seul facteur. En revanche, récupérer le mot de passe, un code MFA valide et un document d’identité officiel lui donne tout ce dont il a besoin pour prendre le contrôle d’un compte, satisfaire une vérification renforcée et, dans de nombreux cas, réussir ensuite la procédure de récupération du compte. Pour une entreprise qui utilise une Page Facebook pour échanger avec ses clients, faire de la publicité et entretenir son image de marque, la perte de cette Page a un impact opérationnel et réputationnel direct.

L’utilisation d’un prétexte positif fondé sur une récompense est également importante pour la sensibilisation. Depuis des années, les utilisateurs apprennent à se méfier des menaces et de l’urgence. Une proposition de badge de vérification ne déclenche aucun de ces signaux d’alerte. Le message durable à transmettre est plus simple et indépendant de la plateforme : les notifications légitimes d’une plateforme ne demandent jamais de saisir un mot de passe, un code MFA ou une photo de pièce d’identité via un lien contenu dans un email. Le statut de vérification doit être contrôlé directement sur la plateforme officielle, au moyen d’une URL enregistrée dans les favoris ou de l’application mobile, jamais depuis un lien reçu par email.

Incidents majeurs et événements du secteur

JadePuffer : la première attaque de ransomware entièrement menée par un agent d’IA

Le 4 juillet, Bleeping Computer a présenté JadePuffer comme la première opération de ransomware connue menée du début à la fin par un agent LLM plutôt que par un opérateur humain, sur la base d’une étude publiée le 1er juillet par l’équipe Threat Research de Sysdig. Infosecurity Magazine a couvert indépendamment les mêmes conclusions. Les articles utilisent le terme « agentic threat actor » (ATA) pour désigner cette catégorie d’adversaire : au lieu d’un humain utilisant une boîte à outils, c’est l’agent d’IA lui-même qui mène l’intrusion.

Cette distinction n’est pas marketing. Pendant toute l’intrusion, l’agent a tout exécuté seul : reconnaissance de l’environnement, extraction d’identifiants, déplacement vers les systèmes voisins, mise en place de la persistance, élévation de privilèges et chiffrement final des données. Il s’est adapté aux échecs en temps réel, comme le ferait un opérateur humain confronté à des obstacles.

Chaîne d’attaque

Étape 1 : l’intrusion a commencé par l’exploitation de CVE-2025-3248, une faille de Langflow, framework open source populaire pour créer des applications LLM, qui permet à un attaquant non authentifié d’exécuter du code arbitraire. L’agent a utilisé ce point d’appui comme canal de diffusion pour toute l’opération, en y faisant transiter les charges utiles suivantes.

Étape 2 : une fois à l’intérieur, l’agent a cartographié l’hôte et recherché des secrets. Il a ciblé les clés API de fournisseurs LLM, les identifiants de fournisseurs Cloud et les connexions aux bases de données. Il a exporté la base PostgreSQL utilisée par Langflow, puis a exploré un stockage d’objets MinIO adjacent afin d’en extraire les fichiers de configuration et d’environnement.

Étape 3 : pour conserver son point d’appui, l’agent a planifié une tâche cron sur l’hôte Langflow, qui contactait l’infrastructure de l’attaquant toutes les 30 minutes.

Étape 4 : l’agent s’est ensuite déplacé vers un serveur de production hébergeant une base MySQL et Alibaba Nacos (Naming and Configuration Service). L’instance Nacos était vulnérable à CVE-2021-29441, un contournement de l’authentification que l’agent a utilisé pour créer un compte administrateur sous son contrôle.

Étape 5 : pour la phase finale, l’agent a retourné la base de données de la victime contre elle. Il a appliqué la fonction AES_ENCRYPT() de MySQL aux 1 342 éléments de configuration de service détenus par Nacos, supprimé les tables de configuration et d’historique d’origine, puis laissé sa demande de paiement dans une nouvelle table de rançon.

La preuve la plus forte de l’absence d’un humain au clavier vient d’une séquence de 31 secondes pendant la prise de contrôle de Nacos. L’agent a rencontré un échec de connexion administrateur, puis a rétabli le fonctionnement en environ une demi-minute. Les articles indiquent également que l’agent a laissé dans ses charges utiles des commentaires continus sur ses propres objectifs, en précisant le but de chaque étape. Les opérateurs humains n’annotent pas de cette manière des commandes ponctuelles destinées à être jetées.

La demande de rançon trahit elle aussi l’origine automatisée de l’attaque. L’adresse Bitcoin utilisée est l’adresse d’exemple figurant dans la documentation destinée aux développeurs Bitcoin, que l’agent a manifestement reproduite à partir de ses données d’entraînement. Toute victime qui aurait payé aurait envoyé les fonds vers une adresse que l’attaquant ne contrôlait pas. La clé de chiffrement constitue une deuxième impasse : l’agent l’a générée de manière aléatoire sans l’enregistrer ni l’exfiltrer. Les données de configuration chiffrées sont donc irrécupérables, avec ou sans paiement.

Pourquoi est-ce un événement majeur ?

JadePuffer est le signal que de nombreux spécialistes de la sécurité attendaient. L’environnement ciblé était une pile d’IA et de données auto-hébergée, avec un accès d’administration exposé à Internet et des identifiants par défaut non modifiés. Autrement dit, une cible qu’un attaquant humain compétent aurait également compromise. Ce qui a changé, c’est l’identité de l’opérateur. Le principal enseignement des analyses est que les outils agentiques abaissent le seuil nécessaire pour mener une attaque sérieuse : une opération de ce type n’exige plus une expertise en ransomware, mais seulement un agent dirigé vers une infrastructure exposée.

Cela rejoint directement une tendance présentée le mois dernier. Dans notre rapport de juin sur le Project Glasswing d’Anthropic, nous indiquions que l’apparition en exploitation active, plutôt qu’en divulgation coordonnée, de la première génération de vulnérabilités découvertes par l’IA marquerait le moment où le volet offensif de la sécurité assistée par l’IA aurait rattrapé son retard. Un agent autonome qui combine deux vulnérabilités connues pour mettre en œuvre une opération d’extorsion constitue un signal similaire. Ces deux capacités, découverte accélérée par l’IA et intrusion menée par l’IA, réduisent le délai entre la connaissance d’une faille et son utilisation contre une infrastructure exposée.

Les enseignements défensifs restent classiques, et c’est précisément le point important. Tout ce que JadePuffer a exploité pouvait être corrigé de manière simple : appliquer les correctifs aux failles connues comme CVE-2025-3248, modifier les identifiants et les clés de signature par défaut, et ne pas exposer les interfaces d’administration à Internet. Les outils agentiques ne changent pas la liste des mesures à prendre, mais leur cadence. Les erreurs de configuration qui attendaient autrefois qu’un attaquant humain les découvre sont désormais trouvées et exploitées avec la vitesse et la régularité d’une machine.

Patch Tuesday de Microsoft de juin : publication record et vulnérabilité zero-day activement exploitée dans Exchange

Le Patch Tuesday de Microsoft du 9 juin a été le plus important de l’histoire du programme. Bleeping Computer a indiqué que la publication corrigeait 200 vulnérabilités Microsoft, tandis que The Hacker News et Dark Reading en ont compté un nombre record de 206, dont quelques éléments non liés à Microsoft. Les médias s’accordent sur l’essentiel : il s’agissait d’un mois record, avec plus de 30 vulnérabilités classées critiques, et l’augmentation du volume a été attribuée en partie à la découverte de vulnérabilités assistée par l’IA.

CVE-2026-42897 affectant Exchange sur site

Comme cette publication couvre de nombreuses informations de sécurité liées à M365, cette CVE mérite une attention particulière. Certains lecteurs pourraient voir les articles sur CVE-2026-42897 et craindre le pire, mais cette vulnérabilité ne concerne que les versions d’Exchange sur site. Exchange Online n’est PAS affecté.

CVE-2026-42897 est une vulnérabilité d’usurpation activement exploitée dans Exchange Server. Cette faille de type cross-site scripting (XSS) permet à un attaquant distant non authentifié d’exécuter du JavaScript arbitraire dans la session Outlook Web Access d’une victime. Pour l’exploiter, il suffit que l’attaquant envoie un email spécialement conçu et que le destinataire l’ouvre dans Outlook Web Access sous certaines conditions d’interaction. Les produits concernés sont Exchange Server 2016, Exchange Server 2019 et Exchange Server Subscription Edition sur site.

La chronologie est importante, car l’exploitation a précédé le correctif. La CISA a ajouté CVE-2026-42897 à son catalogue Known Exploited Vulnerabilities le 15 mai 2026 et demandé aux agences de la Federal Civilian Executive Branch d’appliquer les mesures d’atténuation. La même semaine, The Hacker News a indiqué que Microsoft fournissait une mesure temporaire via Exchange Emergency Mitigation Service (EEMS), dans l’attente d’un correctif permanent. Microsoft a publié ce correctif le 9 juin. Un détail de déploiement compte pour les anciennes versions : les mises à jour de juin pour Exchange Server 2016 et 2019 ne sont disponibles que pour les entreprises inscrites à la période 2 du programme Extended Security Update (ESU), tandis qu’Exchange Server Subscription Edition reçoit directement la mise à jour. Là encore, les entreprises qui utilisent Exchange Online hébergé ne sont pas concernées. Il s’agit d’une vulnérabilité du produit Exchange Server sur site, exactement le type de faille de messagerie exposée à Internet que les affiliés de ransomware exploitent régulièrement.

Autres correctifs notables

Outre la faille Exchange, la publication comprenait plusieurs vulnérabilités zero-day rendues publiques, mises en avant par Bleeping Computer et The Hacker News :

• CVE-2026-45586: faille d’élévation de privilèges dans Windows Collaborative Translation Framework (CTFMON), permettant d’obtenir des privilèges SYSTEM.
• CVE-2026-49160: vulnérabilité par déni de service dans Windows HTTP.sys, décrite comme une attaque « HTTP/2 Bomb » dans laquelle de petites requêtes spécialement conçues forcent le serveur à allouer une quantité disproportionnée de mémoire.
• CVE-2026-50507: contournement d’une fonctionnalité de sécurité BitLocker.

Bleeping Computer a également signalé plusieurs failles critiques d’exécution de code à distance affectant Microsoft Office, Outlook, Word et Excel, qui sont les surfaces côté client les plus pertinentes pour les entreprises centrées sur M365. Comme elles peuvent être déclenchées par des documents malveillants transmis par email, elles doivent être placées dans le même niveau de priorité que le correctif Exchange pour toute entreprise dont le principal risque vient des emails entrants.

Pourquoi est-ce important ?

Deux éléments ressortent ce mois-ci. Le premier est la vulnérabilité zero-day d’Exchange activement exploitée, qui constitue un correctif prioritaire à tous égards. Un attaquant non authentifié capable d’exécuter du JavaScript dans la session webmail authentifiée d’un utilisateur est bien placé pour lire les emails, manipuler l’interface et poursuivre vers une compromission plus large du compte. Les entreprises qui ne peuvent pas appliquer immédiatement le correctif doivent confirmer que les mesures EEMS sont actives et traiter ce changement comme une urgence.

Le second élément est le volume record de correctifs lui-même, ainsi que sa cause. The Hacker News et Dark Reading associent tous deux la hausse du nombre de correctifs à la découverte de vulnérabilités assistée par l’IA, la même catégorie de capacité que celle à l’origine des résultats du Project Glasswing présentés en juin. C’est le pendant défensif de ce que représente JadePuffer côté attaquant. Une découverte plus rapide produit davantage de correctifs, ce qui est positif, mais élargit aussi la fenêtre d’exposition des entreprises dont le rythme de mise à jour ne suit pas le volume de correctifs critiques publiés chaque mois. La vitesse d’application des correctifs, notamment sur les systèmes exposés à Internet, devient la variable qui détermine le plus directement le niveau d’exposition.

L’IETF publie la nouvelle génération de DMARC (RFC 9989)

L’évolution la plus importante de la période en matière d’authentification des emails est l’arrivée d’une spécification DMARC de nouvelle génération. Domain-based Message Authentication, Reporting, and Conformance (DMARC) est la couche de politique qui indique aux serveurs de réception quoi faire lorsqu’un message échoue aux contrôles d’alignement SPF et DKIM. Cette technologie régit l’authentification des expéditeurs depuis la spécification d’origine publiée en 2015. L’IETF a désormais publié une spécification DMARC mise à jour, désignée RFC 9989, qui remplace la RFC 7489 d’origine.

Proofpoint a publié une présentation des changements dans « Next generation DMARC: what’s changing and why it matters », rédigée par Craig Temple le 11 juin, ainsi qu’une série plus approfondie en plusieurs parties sur la découverte des domaines et des politiques, et sur la préparation à l’application. La section ci-dessous propose une vue d’ensemble et non un guide complet. Les spécialistes qui préparent une migration doivent s’appuyer sur ces articles et sur la RFC elle-même.

Selon la synthèse de Proofpoint, cette mise à jour doit être comprise comme dix années d’améliorations opérationnelles plutôt que comme une réinvention. Les principaux changements se répartissent en trois domaines :

• Découverte normalisée du domaine de l’entreprise. La RFC 9989 remplace les méthodes de recherche incohérentes et propres à chaque fournisseur par une méthode normalisée pour déterminer la limite du domaine d’une entreprise. Cela influe directement sur la manière dont les sous-domaines héritent de la politique de leurs domaines parents et ferme des failles que les attaquants exploitaient pour contourner une protection anti-usurpation appliquée de manière incohérente.
• Alignement et gestion des emails indirects plus clairs. La spécification resserre la logique d’alignement, notamment pour distinguer le mode souple du mode strict, et normalise le traitement des flux d’emails indirects comme le transfert et les listes de diffusion, qui causent depuis longtemps des échecs injustifiés.
• Rapports répartis dans des spécifications complémentaires. Les rapports agrégés (RUA) et les rapports d’échec (RUF) ont été séparés de la spécification principale et placés dans leurs propres documents afin de pouvoir évoluer indépendamment. Les rapports gagnent un nouveau contexte lié à la RFC 9989, avec notamment des champs pour la méthode de découverte et l’état de test. Les sélecteurs DKIM deviennent également obligatoires lorsque les résultats DKIM sont signalés.

Pourquoi est-ce important ?

Le calendrier est révélateur. Depuis deux ans, les principaux fournisseurs de boîtes aux lettres relèvent progressivement le niveau d’exigence concernant l’authentification des expéditeurs et poussent les propriétaires de domaines vers des politiques d’application. La RFC 9989 accélère cette évolution en supprimant des ambiguïtés persistantes. Les destinataires interpréteront donc les politiques de manière plus cohérente, et les échecs d’authentification deviendront plus visibles et moins dépendants des particularités d’implémentation d’un fournisseur.

Pour les équipes de défense, il s’agit d’un progrès net face au type d’usurpation présenté plus haut dans ce rapport. Le phishing par usurpation de marque et badge de vérification réussit en partie parce que l’application incohérente de l’authentification laisse de l’espace aux domaines d’envoi ressemblants ou usurpés. Une évaluation DMARC plus stricte et normalisée réduit cet espace. En contrepartie, les entreprises disposant d’une infrastructure d’envoi dispersée ou mal inventoriée peuvent voir des emails légitimes signalés plus agressivement pendant la transition si leur alignement n’est pas correct. Le travail à mener maintenant est peu spectaculaire mais familier : inventorier toutes les sources d’envoi, valider l’alignement selon les nouvelles règles de découverte et progresser vers une politique d’application avant que les destinataires aient fini d’adopter la norme. Une solution de gestion DMARC fiable peut faciliter ce processus.

Prévisions pour les prochains mois

• Les acteurs malveillants agentiques passeront de la preuve de concept à des outils courants. JadePuffer démontre qu’un agent d’IA peut enchaîner des vulnérabilités connues jusqu’à constituer une opération d’extorsion complète. Nous prévoyons que les activités suivantes viseront surtout les frameworks d’applications exposés à Internet, les outils d’IA et de données, les référentiels de configuration et les interfaces d’administration de bases de données exposées, car un opérateur automatisé peut les analyser à grande échelle. L’économie favorise le volume : il faut donc s’attendre à davantage de tentatives contre davantage de cibles, plutôt qu’à des intrusions uniques plus complexes.
• La découverte de vulnérabilités assistée par l’IA continuera d’augmenter le volume de correctifs, et la vitesse d’application distinguera les entreprises résilientes des entreprises exposées. Le Patch Tuesday record de juin ne devrait pas rester une exception. À mesure que la découverte progresse plus vite que la correction, la fenêtre d’exposition entre divulgation et exploitation devient déterminante, surtout pour les systèmes exposés à Internet.
• Exchange Server sur site restera une cible prioritaire. Avec CVE-2026-42897 activement exploitée et une longue série de failles Exchange ayant attiré les groupes de ransomware, les entreprises qui n’ont pas terminé leur migration hors d’Exchange sur site, ou qui ne peuvent pas appliquer rapidement les correctifs, continueront d’apparaître dans les rapports d’incident pendant le second semestre 2026.
• Les appâts liés à la vérification de marque s’étendront au-delà de Meta et du simple vol d’identifiants. Le modèle de prise de contrôle de compte analysé ce mois-ci, qui collecte des codes MFA et des documents d’identité au lieu de se limiter aux mots de passe, peut être adapté à toute plateforme proposant un badge de vérification ou de confiance. Il faut s’attendre à ce que ce prétexte se propage aux marques des réseaux sociaux, de la finance et des places de marché.
• L’adoption de DMARC RFC 9989 sera inégale pendant la transition. Comme les destinataires mettront en œuvre les nouvelles règles de découverte du domaine de l’entreprise et d’alignement selon leur propre calendrier, les entreprises dont l’inventaire des sources d’envoi est incomplet doivent s’attendre à des problèmes intermittents de délivrabilité. Les attaquants chercheront les domaines pour lesquels les anciennes et les nouvelles interprétations divergent.

Recommandations mensuelles

• Renforcer et inventorier les outils applicatifs et d’IA exposés à Internet. Appliquez le correctif de CVE-2025-3248 dans Langflow, modifiez les identifiants et clés de signature par défaut, notamment les clés JWT par défaut de Nacos et les identifiants MinIO par défaut, puis limitez l’accès aux interfaces d’administration des bases de données et de configuration aux réseaux connus. Les attaquants agentiques commencent par énumérer ces surfaces, et les contrôles qui arrêtent un opérateur humain arrêtent tout aussi bien un agent.
• Appliquer immédiatement les mises à jour Microsoft de juin, en donnant la priorité à la vulnérabilité zero-day activement exploitée dans Exchange Server. Traitez CVE-2026-42897 comme un changement d’urgence pour tout déploiement sur site d’Exchange Server 2016, 2019 ou Subscription Edition. Vérifiez que les mesures Exchange Emergency Mitigation Service (EEMS) sont actives lorsqu’une mise à jour immédiate n’est pas possible. Dans le même cycle, accordez la priorité aux correctifs critiques d’exécution de code à distance pour Office, Outlook, Word et Excel dans les entreprises dont le principal risque vient des emails entrants.
• Former les utilisateurs à reconnaître les appâts fondés sur une récompense ou un badge de vérification, et pas seulement les menaces. La campagne Meta analysée commence par une proposition plutôt que par un avertissement et demande des codes MFA et des documents d’identité. Rappelez, dans le cadre de la sensibilisation à la sécurité, que les plateformes légitimes ne demandent jamais de mots de passe, de codes MFA ou de documents d’identité via un lien reçu par email, et que le statut de vérification doit toujours être contrôlé directement sur la plateforme officielle.
• Réévaluer votre posture DMARC avant l’adoption de la RFC 9989. Inventoriez toutes les sources d’envoi légitimes, confirmez l’alignement SPF et DKIM selon les nouvelles règles de découverte du domaine de l’entreprise, mettez à niveau vos rapports pour capturer les nouveaux champs RFC 9989 et progressez vers une politique d’application (p=reject) avant que les destinataires aient terminé le déploiement de la norme. Une évaluation DMARC cohérente et normalisée est l’une des défenses structurelles les plus efficaces contre l’usurpation de marque présentée dans ce rapport.
• Intégrer les scénarios d’attaque agentique dans la priorisation des correctifs et la gestion de l’exposition. Partez du principe que l’intervalle entre la divulgation publique d’une faille exposée à Internet et son exploitation active continuera de diminuer. Maintenez un inventaire précis de la surface d’attaque externe, liez la priorité des correctifs à l’exposition réelle plutôt qu’au seul score de gravité, et entraînez-vous à appliquer rapidement des correctifs d’urgence sur les systèmes exposés à Internet.

---

À propos d’Hornetsecurity

Hornetsecurity est l’un des principaux fournisseurs mondiaux de solutions de sécurité, de conformité, de sauvegarde et de sensibilisation à la sécurité basées sur le cloud de nouvelle génération, qui aident les entreprises et les organisations de toutes tailles dans le monde entier. Son produit phare, 365 Total Protection, est la solution de sécurité en cloud pour Microsoft 365 la plus complète du marché. Poussée par l’innovation et l’excellence en matière de cybersécurité, Hornetsecurity construit un avenir numérique plus sûr et des cultures de sécurité durables grâce à son portefeuille primé. Hornetsecurity est présent dans plus de 120 pays grâce à son réseau de distribution international, de plus de 12 000 partenaires de distribution et MSP. Ses services haut de gamme sont utilisés par plus de 125 000 clients. Pour plus d’informations, visitez le site www.hornetsecurity.com.