LDLC envoie actuellement des e-mails pour prévenir ses clients d’une nouvelle fuite de données. « Nous vous informons qu’un acte malveillant a permis un accès non autorisé à l’un de nos systèmes d’information, susceptible d’avoir entraîné la consultation de certaines données vous concernant », indique l’entreprise dans le courrier.

Les données concernées ? Pratiquement tout ce qu’il est possible d’avoir hors informations bancaires et de connexion : nom, prénom, adresse postale, adresse e-mail, fax, téléphone portable, téléphone fixe, langue du client, type de salutation (monsieur, madame…), codes clients techniques, type de client (particulier ou professionnel), date de dernière connexion sur le compte client web et date d’inscription sur le site.

« Vos données bancaires (RIB, numéro de carte), vos identifiants de connexion ou mots de passe n’ont pas été concernés », se dépêche d’ajouter LDLC. L’entreprise dit avoir immédiatement isolé la partie concernée de son infrastructure, révisé sa stratégie d’accès correspondante et notifié l’incident à la CNIL, « conformément à la réglementation applicable ».

Comme toujours dans ce genre de cas, les données dérobées « pourraient être utilisées pour des tentatives de fraude et de hameçonnage (phishing) », prévient LDLC. S’ensuivent plusieurs conseils, comme ne pas cliquer sur des liens reçus par SMS ou e-mail, ou ne jamais communiquer ses informations personnelles, identifiants et coordonnées bancaires par e-mail, SMS ou au téléphone. On fera remarquer, non sans ironie, qu’un nombre croissant d’entreprises s’en chargent pour nous.

Pour LDLC, c’est le quatrième incident de ce type depuis 2021. Cette année-là, l’entreprise annonçait avoir été attaquée par le groupe de pirates Ragnar Locker, qui avait mis en vente 29,5 Go de données internes. Puis 2024 avait marqué un doublé : d’abord le 29 février avec le vol des données de 1,5 million de clients, puis en décembre, sans savoir cette fois combien de personnes sont concernées.

LDLC envoie actuellement des e-mails pour prévenir ses clients d’une nouvelle fuite de données. « Nous vous informons qu’un acte malveillant a permis un accès non autorisé à l’un de nos systèmes d’information, susceptible d’avoir entraîné la consultation de certaines données vous concernant », indique l’entreprise dans le courrier.

Les données concernées ? Pratiquement tout ce qu’il est possible d’avoir hors informations bancaires et de connexion : nom, prénom, adresse postale, adresse e-mail, fax, téléphone portable, téléphone fixe, langue du client, type de salutation (monsieur, madame…), codes clients techniques, type de client (particulier ou professionnel), date de dernière connexion sur le compte client web et date d’inscription sur le site.

« Vos données bancaires (RIB, numéro de carte), vos identifiants de connexion ou mots de passe n’ont pas été concernés », se dépêche d’ajouter LDLC. L’entreprise dit avoir immédiatement isolé la partie concernée de son infrastructure, révisé sa stratégie d’accès correspondante et notifié l’incident à la CNIL, « conformément à la réglementation applicable ».

Comme toujours dans ce genre de cas, les données dérobées « pourraient être utilisées pour des tentatives de fraude et de hameçonnage (phishing) », prévient LDLC. S’ensuivent plusieurs conseils, comme ne pas cliquer sur des liens reçus par SMS ou e-mail, ou ne jamais communiquer ses informations personnelles, identifiants et coordonnées bancaires par e-mail, SMS ou au téléphone. On fera remarquer, non sans ironie, qu’un nombre croissant d’entreprises s’en chargent pour nous.

Pour LDLC, c’est le quatrième incident de ce type depuis 2021. Cette année-là, l’entreprise annonçait avoir été attaquée par le groupe de pirates Ragnar Locker, qui avait mis en vente 29,5 Go de données internes. Puis 2024 avait marqué un doublé : d’abord le 29 février avec le vol des données de 1,5 million de clients, puis en décembre, sans savoir cette fois combien de personnes sont concernées.

Avec ses 21 centimètres et ses 7 kilos, Comando détonne parmi les chiens de la garde nationale mexicaine. Adopté par l’institution il y a quelques mois, le chihuahua est désormais formé pour participer aux opérations de recherche et de sauvetage.

© photo Toya Sarno Jordan/REUTERS

Il y a du travail

L’ANSSI a publié le premier point de situation de son dispositif REACTIV. Le rapport est sobre et direct, alignant les causes des différents incidents cyber des deux derniers mois contre les ministères, avec des chiffres éloquents.

Le dispositif REACTIV (pour REponse & ACTion Interministérielle face aux Violations de données) a été créé par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) à la demande du Premier ministre Sébastien Lecornu. Annoncée publiquement le 7 septembre, elle constitue une réorientation des moyens opérationnels de l’ANSSI vers deux tâches : le traitement des comptes utilisateurs compromis et l’analyse des violations de données.

Cybersécurité : l’ANSSI lance son mécanisme REACTIV dédié aux services de l’État – Next

Comme nous l’indiquions au moment de l’annonce, l’agence obtient deux pouvoirs nouveaux. D’abord, elle centralise la communication technique de crise. Ensuite, et surtout, l’ANSSI peut imposer aux ministères des mesures de protection immédiates dans des délais contraints. Vincent Strubel, directeur de l’agence, avait bien précisé lors de l’annonce que l’effort était temporaire et qu’il se faisait au détriment d’autres pans de la menace.

La situation exigeait une forme d’urgence. Il n’aura fallu que trois semaines pour que l’ANSSI publie un premier point d’étape, faisant le bilan des attaques des deux derniers mois contre plusieurs ministères.

• L’Éducation nationale s’est encore fait pirater, un nombre important d’agents concernés
• Le piratage du ministère de l’Intérieur : un coup de bol opportuniste, et même pas ciblé
• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

Des brèches en pagaille

Depuis le 1ᵉʳ août 2026, 99 violations de données ont été signalées à l’ANSSI, dont 67 sont confirmées et 32 sont en cours de traitement par l’agence.

Parmi les incidents, la faille CVE-2026-72898 (score CVSS 10) dans Metabase (une plateforme open source dédiée à l’intelligence économique) et son exploitation sont en bonne place. L’ANSSI évoque neuf instances ministérielles compromises depuis début août. « Cette vulnérabilité, de type injection SQL, permet l’accès à la base de données de l’application Metabase pour un utilisateur non authentifié et l’obtention des droits administrateurs de l’instance », indique le rapport.

Lorsque la faille a été découverte le 3 août par Metabase, elle était déjà exploitée. Le correctif a été publié le 6 août. Pour les ministères français en revanche, il ne s’agissait probablement déjà plus d’une faille 0-day, l’attaque contre France VAE étant par exemple survenue le 8 août. L’exploitation de cette faille a servi également contre Zéro Logement Vacant, Qualicharge et probablement Docurba, même si l’enquête n’est pas terminée.

Mais cette faille a aussi servi contre le propre Laboratoire d’innovation de l’ANSSI et contre la Direction interministérielle du numérique (DINUM), deux agences relevant du Premier ministre. Dans le premier cas, l’ANSSI pointe « la compromission de 118 comptes utilisateurs Metabase dont une trentaine de comptes d’utilisateurs externes (données statistiques d’utilisation, identifiants, courriels et mots de passe hachés) ». Les instances vulnérables ont été mises à jour, les mots de passe ont été renouvelés pour l’ensemble des comptes et les comptes inutilisés depuis plus de trois mois ont été désactivés.

Dans le cas de la DINUM, deux instances Metabase ont été compromises, ProConnect et Nuage-Public. « Les données exfiltrées portent sur des informations administratives d’organismes publics (SIREN, SIRET, budgets, effectifs), des métadonnées de contributions à des projets logiciels open source, et des historiques de connexions anonymisés », indique l’ANSSI. L’agence ajoute que ces données étaient cependant déjà publiques. Là encore, les vulnérabilités ont été colmatées, les secrets réinitialisés et les comptes créés par l’attaquant supprimés.

Le rapport n’indique pas toutefois dans quelle mesure ces instances Metabase étaient exposées à internet. Dans tous les cas, l’information tombe mal pour l’ANSSI, qui doit montrer l’exemple, notamment en matière de réactivité sur les correctifs sortant régulièrement. Il s’est écoulé au moins plusieurs jours entre la publication du correctif de Metabase et les premiers signes d’attaque contre la faille au sein des ministères, témoignant d’un retard dans l’application. Dans le cas de l’agence, même s’il s’agit uniquement de son Laboratoire d’innovation, le signal renvoyé n’est pas glorieux.

On peut noter également que l’avis du CERT-FR sur plusieurs failles Metabase a été publié le 24 août, alors que trois des quatre failles (dont CVE-2026-72898) étaient connues depuis le 6 et la dernière le 11.

Des défauts de sécurisation classiques

Les autres incidents relèvent malheureusement de défauts de sécurité classiques. Par exemple, des identifiants volés par des infostealers sur des postes personnels ou de partenaires, puis utilisés contre des services exposés sans double authentification. C’est le cas pour le PIGP (Portail de la Gestion Publique de la DGFIP), le cadastre et l’AEFE (Agence pour l’enseignement français à l’étranger).

L’absence de double authentification ressort justement dans le rapport, ou un deuxième facteur par simple e-mail, cette méthode n’étant plus considérée comme robuste depuis longtemps. Le point de situation évoque également la compromission de sous-traitants, dont un de TRACFIN, et le serveur d’échange avec les prestataires de la DGDDI.

On note aussi que plusieurs incidents sont en cours de qualification. Par exemple, pour Signal Logement (identification de logements insalubres) et le BCPR (Bureau des courriers parlementaires et réservés), duquel des e-mails auraient été exfiltrés, sans que l’ANSSI en soit certaine pour l’instant.

En outre, si la mission de REACTIV est surtout de pouvoir imposer des mesures concrètes dans des délais contraints, on ne sait rien des éventuels changements mis en place pour faire évoluer la culture de la cybersécurité chez l’ensemble des personnes concernées. Si l’exploitation de failles peut souvent être combattue par une application stricte des correctifs de sécurité, les attaques passant par des comptes compromis doivent interpeler les utilisateurs impliqués et leur hygiène numérique, dont la gestion de leurs mots de passe.

Une utilisation sérieuse de la double authentification ne semble pas toujours la règle non plus, le mécanisme relevant des ministères et de leurs services informatiques. À ce sujet, la position de l’ANSSI est d’ailleurs claire : « facteur clé de nombreux incidents analysés par l’ANSSI, l’absence de MFA, ou l’utilisation d’un second facteur faible (e-mail), a facilité les intrusions puisqu’un mot de passe faible ou une fuite de mot de passe suffisait à l’attaquant pour s’octroyer a minima un accès utilisateur ».

Il y a du travail

L’ANSSI a publié le premier point de situation de son dispositif REACTIV. Le rapport est sobre et direct, alignant les causes des différents incidents cyber des deux derniers mois contre les ministères, avec des chiffres éloquents.

Le dispositif REACTIV (pour REponse & ACTion Interministérielle face aux Violations de données) a été créé par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) à la demande du Premier ministre Sébastien Lecornu. Annoncée publiquement le 7 septembre, elle constitue une réorientation des moyens opérationnels de l’ANSSI vers deux tâches : le traitement des comptes utilisateurs compromis et l’analyse des violations de données.

Cybersécurité : l’ANSSI lance son mécanisme REACTIV dédié aux services de l’État – Next

Comme nous l’indiquions au moment de l’annonce, l’agence obtient deux pouvoirs nouveaux. D’abord, elle centralise la communication technique de crise. Ensuite, et surtout, l’ANSSI peut imposer aux ministères des mesures de protection immédiates dans des délais contraints. Vincent Strubel, directeur de l’agence, avait bien précisé lors de l’annonce que l’effort était temporaire et qu’il se faisait au détriment d’autres pans de la menace.

La situation exigeait une forme d’urgence. Il n’aura fallu que trois semaines pour que l’ANSSI publie un premier point d’étape, faisant le bilan des attaques des deux derniers mois contre plusieurs ministères.

• L’Éducation nationale s’est encore fait pirater, un nombre important d’agents concernés
• Le piratage du ministère de l’Intérieur : un coup de bol opportuniste, et même pas ciblé
• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

Des brèches en pagaille

Depuis le 1ᵉʳ août 2026, 99 violations de données ont été signalées à l’ANSSI, dont 67 sont confirmées et 32 sont en cours de traitement par l’agence.

Parmi les incidents, la faille CVE-2026-72898 (score CVSS 10) dans Metabase (une plateforme open source dédiée à l’intelligence économique) et son exploitation sont en bonne place. L’ANSSI évoque neuf instances ministérielles compromises depuis début août. « Cette vulnérabilité, de type injection SQL, permet l’accès à la base de données de l’application Metabase pour un utilisateur non authentifié et l’obtention des droits administrateurs de l’instance », indique le rapport.

Lorsque la faille a été découverte le 3 août par Metabase, elle était déjà exploitée. Le correctif a été publié le 6 août. Pour les ministères français en revanche, il ne s’agissait probablement déjà plus d’une faille 0-day, l’attaque contre France VAE étant par exemple survenue le 8 août. L’exploitation de cette faille a servi également contre Zéro Logement Vacant, Qualicharge et probablement Docurba, même si l’enquête n’est pas terminée.

Mais cette faille a aussi servi contre le propre Laboratoire d’innovation de l’ANSSI et contre la Direction interministérielle du numérique (DINUM), deux agences relevant du Premier ministre. Dans le premier cas, l’ANSSI pointe « la compromission de 118 comptes utilisateurs Metabase dont une trentaine de comptes d’utilisateurs externes (données statistiques d’utilisation, identifiants, courriels et mots de passe hachés) ». Les instances vulnérables ont été mises à jour, les mots de passe ont été renouvelés pour l’ensemble des comptes et les comptes inutilisés depuis plus de trois mois ont été désactivés.

Dans le cas de la DINUM, deux instances Metabase ont été compromises, ProConnect et Nuage-Public. « Les données exfiltrées portent sur des informations administratives d’organismes publics (SIREN, SIRET, budgets, effectifs), des métadonnées de contributions à des projets logiciels open source, et des historiques de connexions anonymisés », indique l’ANSSI. L’agence ajoute que ces données étaient cependant déjà publiques. Là encore, les vulnérabilités ont été colmatées, les secrets réinitialisés et les comptes créés par l’attaquant supprimés.

Le rapport n’indique pas toutefois dans quelle mesure ces instances Metabase étaient exposées à internet. Dans tous les cas, l’information tombe mal pour l’ANSSI, qui doit montrer l’exemple, notamment en matière de réactivité sur les correctifs sortant régulièrement. Il s’est écoulé au moins plusieurs jours entre la publication du correctif de Metabase et les premiers signes d’attaque contre la faille au sein des ministères, témoignant d’un retard dans l’application. Dans le cas de l’agence, même s’il s’agit uniquement de son Laboratoire d’innovation, le signal renvoyé n’est pas glorieux.

On peut noter également que l’avis du CERT-FR sur plusieurs failles Metabase a été publié le 24 août, alors que trois des quatre failles (dont CVE-2026-72898) étaient connues depuis le 6 et la dernière le 11.

Des défauts de sécurisation classiques

Les autres incidents relèvent malheureusement de défauts de sécurité classiques. Par exemple, des identifiants volés par des infostealers sur des postes personnels ou de partenaires, puis utilisés contre des services exposés sans double authentification. C’est le cas pour le PIGP (Portail de la Gestion Publique de la DGFIP), le cadastre et l’AEFE (Agence pour l’enseignement français à l’étranger).

L’absence de double authentification ressort justement dans le rapport, ou un deuxième facteur par simple e-mail, cette méthode n’étant plus considérée comme robuste depuis longtemps. Le point de situation évoque également la compromission de sous-traitants, dont un de TRACFIN, et le serveur d’échange avec les prestataires de la DGDDI.

On note aussi que plusieurs incidents sont en cours de qualification. Par exemple, pour Signal Logement (identification de logements insalubres) et le BCPR (Bureau des courriers parlementaires et réservés), duquel des e-mails auraient été exfiltrés, sans que l’ANSSI en soit certaine pour l’instant.

En outre, si la mission de REACTIV est surtout de pouvoir imposer des mesures concrètes dans des délais contraints, on ne sait rien des éventuels changements mis en place pour faire évoluer la culture de la cybersécurité chez l’ensemble des personnes concernées. Si l’exploitation de failles peut souvent être combattue par une application stricte des correctifs de sécurité, les attaques passant par des comptes compromis doivent interpeler les utilisateurs impliqués et leur hygiène numérique, dont la gestion de leurs mots de passe.

Une utilisation sérieuse de la double authentification ne semble pas toujours la règle non plus, le mécanisme relevant des ministères et de leurs services informatiques. À ce sujet, la position de l’ANSSI est d’ailleurs claire : « facteur clé de nombreux incidents analysés par l’ANSSI, l’absence de MFA, ou l’utilisation d’un second facteur faible (e-mail), a facilité les intrusions puisqu’un mot de passe faible ou une fuite de mot de passe suffisait à l’attaquant pour s’octroyer a minima un accès utilisateur ».

Le correctif était pourtant là

Les personnes et organisations disposant de serveurs équipés de Zimbra pour la gestion de leurs e-mails doivent mettre à jour aussi rapidement que possible les composants logiciels. Une faille est exploitée depuis plus de deux mois, alors que le correctif existe depuis le 20 juillet.

Dans un long billet publié le 30 septembre, Microsoft Threat Intelligence a fourni une analyse de l’exploitation de CVE-2026-73570, une faille de type « injection de commandes système non authentifiée » dans Zimbra Collaboration Suite (ZCS), une solution e-mail très populaire.

Cette faille, présente dans toutes les versions antérieures à la 10.1.20, est en fait corrigée depuis juillet. Cependant, les systèmes non mis à jour seraient encore nombreux, Microsoft indique que la faille – critique, avec un score CVSS de 8,9 – est exploitée depuis fin juillet au moins. L’éditeur évoque un minimum de plusieurs centaines de serveurs compromis par l’exploitation de cette faille.

Cette vulnérabilité est présente dans le traitement des notifications SNMP de Zimbra. Elle peut être exploitée dès lors que le paquet optionnel zimbra-snmp est installé et que les notifications sont activées. Un attaquant non authentifié peut alors envoyer des requêtes SMTP spécialement conçues pour provoquer une erreur, lui permettant après coup d’exécuter des commandes système arbitraires avec les droits de l’utilisateur zimbra.

Des attaques rondement menées

Dans son billet, Microsoft dit avoir observé deux outils de balayage le 28 juillet et le 7 août, donc après le correctif mais avant la divulgation, intervenue le 13 août avec la publication des informations dans la base NVD. « Les sondes incluaient des requêtes HTTP et des vérifications d’identité DNS, ICMP et en bande, utilisant des commandes telles que curl, wget, ping, nslookup et id », vers des services d’interaction comme oast[.]fun ou requestrepo[.]com, ou vers une infrastructure propre à la campagne d’attaque sous bypass[.]eu[.]org. Les requêtes HTTP portaient un User-Agent spécifique, ZB73570, suggérant selon Microsoft que des acteurs ont analysé le correctif avant la publication des détails du bulletin CVE.

Les attaquants ont ensuite déposé des pages JSP malveillantes (webshells) dans les répertoires Jetty et mailboxd, puis les ont recopiées sur les autres nœuds de boîtes aux lettres. Ils allaient parfois jusqu’à ouvrir temporairement les droits d’écriture du répertoire public avant de les rétablir. Ils ont aussi installé un service systemd déguisé, zimlog.service, dont les horodatages avaient été modifiés pour imiter sshd.service.

L’exploitation se faisait au moyen du journal zmmailboxd.out remplacé par un lien symbolique vers /etc/pam.d/sudo, qui invoquait alors zmmailboxdmgr, exécuté avec des privilèges élevés. Les pirates étaient ensuite capables de voler des secrets, de se déplacer latéralement dans l’infrastructure et d’exfiltrer des contenus. Microsoft n’attribue cette activité à aucun acteur nommé, le rapport mentionnant des victimes dans plusieurs régions et secteurs, et un mélange d’opérations automatisées et manuelles.

Du pain sur la planche

Selon le rapport, toute instance Zimbra qui n’a pas été mise à jour avant fin juillet doit être considérée comme potentiellement compromise. L’installation de la mise à jour est la mesure la plus urgente à entreprendre. À défaut, si l’opération est impossible dans l’immédiat, Microsoft recommande la désinstallation du paquet zimbra-snmp, la désactivation des notifications SNMP et la restriction de l’accès SNMP et SMTP aux seuls hôtes de confiance.

Une fois la mise à jour effectuée, plusieurs actions sont encore nécessaires :

• Renouveler toutes les clés zimbraPreAuthKey et zimbraAuthTokenKey
• Inspecter /etc/sudoers.d/ (notamment 81_metric), /etc/pam.d/ et les unités systemd (zimlog.service, chronyd-helper.service, syslog_init.service)
• Chercher les JSP et fichiers *_jsp.java inattendus sur la totalité des nœuds

Le correctif était pourtant là

Les personnes et organisations disposant de serveurs équipés de Zimbra pour la gestion de leurs e-mails doivent mettre à jour aussi rapidement que possible les composants logiciels. Une faille est exploitée depuis plus de deux mois, alors que le correctif existe depuis le 20 juillet.

Dans un long billet publié le 30 septembre, Microsoft Threat Intelligence a fourni une analyse de l’exploitation de CVE-2026-73570, une faille de type « injection de commandes système non authentifiée » dans Zimbra Collaboration Suite (ZCS), une solution e-mail très populaire.

Cette faille, présente dans toutes les versions antérieures à la 10.1.20, est en fait corrigée depuis juillet. Cependant, les systèmes non mis à jour seraient encore nombreux, Microsoft indique que la faille – critique, avec un score CVSS de 8,9 – est exploitée depuis fin juillet au moins. L’éditeur évoque un minimum de plusieurs centaines de serveurs compromis par l’exploitation de cette faille.

Cette vulnérabilité est présente dans le traitement des notifications SNMP de Zimbra. Elle peut être exploitée dès lors que le paquet optionnel zimbra-snmp est installé et que les notifications sont activées. Un attaquant non authentifié peut alors envoyer des requêtes SMTP spécialement conçues pour provoquer une erreur, lui permettant après coup d’exécuter des commandes système arbitraires avec les droits de l’utilisateur zimbra.

Des attaques rondement menées

Dans son billet, Microsoft dit avoir observé deux outils de balayage le 28 juillet et le 7 août, donc après le correctif mais avant la divulgation, intervenue le 13 août avec la publication des informations dans la base NVD. « Les sondes incluaient des requêtes HTTP et des vérifications d’identité DNS, ICMP et en bande, utilisant des commandes telles que curl, wget, ping, nslookup et id », vers des services d’interaction comme oast[.]fun ou requestrepo[.]com, ou vers une infrastructure propre à la campagne d’attaque sous bypass[.]eu[.]org. Les requêtes HTTP portaient un User-Agent spécifique, ZB73570, suggérant selon Microsoft que des acteurs ont analysé le correctif avant la publication des détails du bulletin CVE.

Les attaquants ont ensuite déposé des pages JSP malveillantes (webshells) dans les répertoires Jetty et mailboxd, puis les ont recopiées sur les autres nœuds de boîtes aux lettres. Ils allaient parfois jusqu’à ouvrir temporairement les droits d’écriture du répertoire public avant de les rétablir. Ils ont aussi installé un service systemd déguisé, zimlog.service, dont les horodatages avaient été modifiés pour imiter sshd.service.

L’exploitation se faisait au moyen du journal zmmailboxd.out remplacé par un lien symbolique vers /etc/pam.d/sudo, qui invoquait alors zmmailboxdmgr, exécuté avec des privilèges élevés. Les pirates étaient ensuite capables de voler des secrets, de se déplacer latéralement dans l’infrastructure et d’exfiltrer des contenus. Microsoft n’attribue cette activité à aucun acteur nommé, le rapport mentionnant des victimes dans plusieurs régions et secteurs, et un mélange d’opérations automatisées et manuelles.

Du pain sur la planche

Selon le rapport, toute instance Zimbra qui n’a pas été mise à jour avant fin juillet doit être considérée comme potentiellement compromise. L’installation de la mise à jour est la mesure la plus urgente à entreprendre. À défaut, si l’opération est impossible dans l’immédiat, Microsoft recommande la désinstallation du paquet zimbra-snmp, la désactivation des notifications SNMP et la restriction de l’accès SNMP et SMTP aux seuls hôtes de confiance.

Une fois la mise à jour effectuée, plusieurs actions sont encore nécessaires :

• Renouveler toutes les clés zimbraPreAuthKey et zimbraAuthTokenKey
• Inspecter /etc/sudoers.d/ (notamment 81_metric), /etc/pam.d/ et les unités systemd (zimlog.service, chronyd-helper.service, syslog_init.service)
• Chercher les JSP et fichiers *_jsp.java inattendus sur la totalité des nœuds

BYOD nouvelle version : Bring Your Own... Désastre

Cet été, la Direction générale des Finances publiques (DGFiP) reconnaissait une intrusion dans ses systèmes informatiques avec l’accès à des données concernant pas moins de 678 000 contribuables et entreprises. Deux suspects de 16 et 18 ans ont été interpellés fin août, dont un mis en examen et placé en détention provisoire.

L’attaquant disposait de mots de passe de dizaines de comptes

Ce piratage a fait grand bruit, d’autant qu’il s’inscrit dans une longue liste de sites et institutions publiques piratés ces dernières semaines, mois et même années. Plusieurs enquêtes ont été lancées, dont une du cyberpompier français, l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Elle vient de publier son rapport d’incident (pdf).

• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

S’il fallait résumer l’affaire en une phrase : « La compromission des SI de la DGFiP n’est pas la conséquence d’une attaque sophistiquée, mais de l’exploitation de faiblesses dans trois domaines ». Il s’agit de l’identité, de l’architecture réseau et de la détection des signaux.

Premier point, la volumétrie : les données volées concernent « près de 353 000 particuliers et 252 000 professionnels, obtenues à partir d’un outil de gestion de la relation avec les usagers de la DGFiP ». Les infiltrations dans la DGFiP ont commencé dès le mois de mai 2026.

• Piratage du fisc : 678 000 usagers touchés, enquête de l’Office anticybercriminalité

L’ANSSI revient tout d’abord sur la sécurité des comptes et le volume important de ceux auxquels le pirate pouvait accéder car il disposait des couples identifiant et mot de passe. En effet, « aucune tentative d’attaque par force brute ou credential stuffing n’a été identifiée, ce qui signifie que l’attaquant disposait de mots de passe pour ces comptes (pouvant être valides ou expirés) ».

Dans son rapport, l’ANSSI anonymise les comptes compromis et utilise la dénomination suivante : compte-dgfip-X pour ceux internes à la DFGIP, et compte-dgfip-xt-Y pour les externes. Les X et Y sont incrémentés pour différencier chaque compte. Voici le bilan officiel : compte-dgfip-X va jusqu’à 22 et compte-dgfip-xt-X jusqu’à 7… soit presque une trentaine de comptes compromis par infostealer.

Pour les comptes externes, « les investigations de la DGFiP mettront en évidence que la compromission du poste d’un géomètre-expert au sein d’un cabinet privé a permis de contourner la double authentification par messagerie, puis l’accès et l’exfiltration des données entre le 27 juillet 2026 et le 8 août 2026 ».

La réinitialisation des mots de passe n’a pas servi à grand-chose.

Une des pistes évoquées pour obtenir ses informations est « la fuite d’identifiants de connexion fréquente et consécutive à l’utilisation d’appareils personnels ». La DGFiP a procédé à la réinitialisation des mots de passe, mais si des machines restent infectées et/ou que les sessions actives ne sont pas coupées, cela n’est pas d’une grande utilité.

Preuve en est : la réinitialisation du 24 juin 2026 « n’interrompt pas la session et l’exfiltration en cours qui se poursuivent », précise l’ANSSI dans le détail de la chronologie des faits. Ajoutez à cela « l’absence d’authentification forte sur deux portails dont l’un donnant accès à des ressources sensibles » et vous avez un combo explosif.

Des indices en pagaille : IP en Inde, des Go téléchargés, connexions nocturnes

Autre problème pour l’ANSSI, le manque de détection : « Les sessions d’exfiltration menées par l’attaquant n’ont pas été détectées en temps réel par les mécanismes de contrôle implémentés sur les applicatifs métiers ni sur les équipements de sécurité de la DGFiP ».

Il y avait pourtant des indices élémentaires facile à identifier : « la volumétrie d’informations échangées lors des connexions (11Go entre le 22 et 25 juin, 3Go entre le 21 et 23 juillet) », ainsi que « le nombre de requêtes par utilisateur sur une plage temporelle ».

L’Agence prend soin de préciser que « la technique de scraping utilisée par les attaquants impose de devoir initier autant de requêtes que de pages accédées ». Cela aurait dû déclencher des alertes. Une technique connue depuis la nuit des temps aurait dû être mise en place : un rate-limiting. Le but est de bloquer un nombre trop important de requêtes, permettant aussi de limiter des attaques par force brute.

Ce n’est pas le seul problème. La DGFiP n’analysait pas les adresses IP puisque des connexions ont été réalisées « depuis des adresses de VPN, depuis des adresses localisées en Inde et pour plusieurs catégorisées comme malveillantes ». Ajoutez à cela des adresses IP déjà identifiées comme liées à un compte compromis qui peuvent revenir en toute impunité et des heures de connexions nocturnes ; vous avez un beau tableau de ce qu’il ne faut pas faire.

« Ces paramètres pris individuellement ne permettent généralement pas d’identifier des comportements suspects sans générer d’importants volumes de faux positifs, néanmoins la corrélation de plusieurs d’entre eux aurait pu permettre de lever des alertes », ajoute l’ANSSI.

Après « le besoin d’en connaître », le besoin d’y avoir accès

Troisième point de faiblesse : le RIE ou Réseau Interministériel de l’État, utilisé par les pirates pour accéder « au portail ADER [Accès Distant aux Échanges Réseau, ndlr] de la DGFiP ». Opérationnel depuis 2013, il raccorde les services de l’État. L’ANSSI note que « plusieurs accès illégitimes identifiés proviennent du RIE [la suite est caviardée, ndlr], à partir de localisations n’ayant pas de besoins apparents d’accéder à des infrastructures de la DGFiP ».

« Pendant l’incident, le SOC [Security Operation Center, ndlr] de la DGFiP ne supervisait pas le portail ADER, utilisé par l’attaquant pour exfiltrer les informations E-Contact », contrairement au portail PIGP (Portail internet de la gestion publique) qui était bien surveillé. Ce trou dans la raquette a permis aux pirates de s’infiltrer, mais a aussi empêché « de corréler des activités malveillantes avec le reste du SI ou en provenance du RIE suite à un signalement d’un autre ministère ».

• Le Réseau Interministériel de l’État (RIE) fête ses 10 ans et se modernise

Là encore on retrouve un basique de la cybersécurité : la segmentation réseau avec le cloisonnement des « accès aux seules populations et zones logiques qui en ont le besoin ». L’Agence recommande de mettre en place « un filtrage plus fin des accès réseau entre ministères et au sein du RIE ».

Comment les pirates sont rentrés dans le RIE ? Par la porte ouverte d’un autre piratage : « L’utilisation du RIE lui a été rendue possible à cause de la compromission d’infrastructures appartenant au ministère de l’Éducation nationale elles-mêmes raccordées au RIE ». Pour l’ANSSI, cela illustre parfaitement le « risque de latéralisation depuis des ressources d’organismes tiers » et le besoin de cloisonner.

Des signalements en pagaille

L’ANSSI fait son mea culpa sur sa supervision. « Les acteurs malveillants utilisaient des comptes légitimes pour accéder aux applications et la supervision réseau de l’Agence n’a pas permis de les voir ». De plus, « le volume cumulé de requêtes que l’attaquant a dû générer pour orchestrer l’exfiltration de données aurait dû déclencher des alertes ».

Dans la même veine, elle explique qu’un partenaire l’a informé le 15 juin de la compromission de deux comptes DGFIP. Cette dernière « ne répond pas et n’est pas relancée par l’Agence ». Nouveau signalement le 22 juin, suivi d’une action cette fois-ci : « un partenaire informe l’ANSSI de la compromission d’un compte. La DGFIP répond le jour même à l’ANSSI avoir réinitialisé ce compte et sensibilisé leur agent ».

D’autres signalements sont remontés dans la chronologie, notamment le 29 juin 2026 avec un bel acte manqué : « un partenaire informe l’ANSSI de la compromission du compte. Il s’agit du compte utilisé pour l’exfiltration de données le 24 juin 2026, or cette compromission n’était pas connue à cette date et les analyses menées par le SOC de la DGFIP ne l’identifient pas. La DGFIP répond le jour même à l’ANSSI avoir déjà connaissance de ce fait et confirme l’avoir réinitialisé ».

D’autres signalements ? Le 1ᵉʳ juillet, la « DGFIP est informée par son prestataire de la vente de deux comptes ». Là aussi le pot aux roses aurait pu être découvert : « les investigations montreront, à posteriori, des échecs de connexion sur le PIGP le même jour et le jour précédent avec ces comptes à partir d’une des adresses IP utilisées pour l’exfiltration du 24 juin 2026 ».

Plein de mesures de remédiation, ça fait pas de mal de les relire !

Enfin, l’ANSSI propose des mesures de remédiation (page 10) afin « d’assurer que le même chemin de compromission ne puisse être emprunté de nouveau, par le même acteur ou un nouveau ». Elles couvrent toutes les lacunes précédentes et ouvrent aussi de nouvelles pistes.

Cela va des restrictions d’accès aux ressources métiers à la protection contre les vols d’identifiants. On y retrouve notamment des propositions sur le matériel. « L’usage d’appareils personnels pour accéder à des ressources professionnelles doit être proscrit », et les machines professionnelles doivent être durcies. Évidemment, l’authentification multifacteurs doit être généralisée.

Pour les applications à usage interne, l’accessibilité ne doit se faire « que depuis des postes administrés par la DGFiP. Dans ce cas, l’accès à l’application ne doit pas être possible depuis Internet, sauf à travers un VPN dédié aux agents de la DGFiP ». Les VPN ne servent pas uniquement à contourner des restrictions, ils permettent aussi de renforcer la sécurité, mais attention aux promesses de certains !

• [Édito] Au pays des VPN menteurs…

Dans sa synthèse, l’ANSSI rappelle que l’exfiltration des données s’est produite sept semaines avant la revendication des pirates le 12 août, et « qu’elle a été précédée de plusieurs semaines d’exploration sur des applicatifs de la DGFIP ».

Des indices étaient bien présents, mais pas correctement pris en compte, c’est un rappel important pour toute la communauté cyber. En effet, ces recommandations peuvent s’appliquer bien au-delà de la DGFiP. Il est toujours bon de les lire et de vérifier qu’elles sont bien appliquées.

BYOD nouvelle version : Bring Your Own... Désastre

Cet été, la Direction générale des Finances publiques (DGFiP) reconnaissait une intrusion dans ses systèmes informatiques avec l’accès à des données concernant pas moins de 678 000 contribuables et entreprises. Deux suspects de 16 et 18 ans ont été interpellés fin août, dont un mis en examen et placé en détention provisoire.

L’attaquant disposait de mots de passe de dizaines de comptes

Ce piratage a fait grand bruit, d’autant qu’il s’inscrit dans une longue liste de sites et institutions publiques piratés ces dernières semaines, mois et même années. Plusieurs enquêtes ont été lancées, dont une du cyberpompier français, l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Elle vient de publier son rapport d’incident (pdf).

• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

S’il fallait résumer l’affaire en une phrase : « La compromission des SI de la DGFiP n’est pas la conséquence d’une attaque sophistiquée, mais de l’exploitation de faiblesses dans trois domaines ». Il s’agit de l’identité, de l’architecture réseau et de la détection des signaux.

Premier point, la volumétrie : les données volées concernent « près de 353 000 particuliers et 252 000 professionnels, obtenues à partir d’un outil de gestion de la relation avec les usagers de la DGFiP ». Les infiltrations dans la DGFiP ont commencé dès le mois de mai 2026.

• Piratage du fisc : 678 000 usagers touchés, enquête de l’Office anticybercriminalité

L’ANSSI revient tout d’abord sur la sécurité des comptes et le volume important de ceux auxquels le pirate pouvait accéder car il disposait des couples identifiant et mot de passe. En effet, « aucune tentative d’attaque par force brute ou credential stuffing n’a été identifiée, ce qui signifie que l’attaquant disposait de mots de passe pour ces comptes (pouvant être valides ou expirés) ».

Dans son rapport, l’ANSSI anonymise les comptes compromis et utilise la dénomination suivante : compte-dgfip-X pour ceux internes à la DFGIP, et compte-dgfip-xt-Y pour les externes. Les X et Y sont incrémentés pour différencier chaque compte. Voici le bilan officiel : compte-dgfip-X va jusqu’à 22 et compte-dgfip-xt-X jusqu’à 7… soit presque une trentaine de comptes compromis par infostealer.

Pour les comptes externes, « les investigations de la DGFiP mettront en évidence que la compromission du poste d’un géomètre-expert au sein d’un cabinet privé a permis de contourner la double authentification par messagerie, puis l’accès et l’exfiltration des données entre le 27 juillet 2026 et le 8 août 2026 ».

La réinitialisation des mots de passe n’a pas servi à grand-chose.

Une des pistes évoquées pour obtenir ses informations est « la fuite d’identifiants de connexion fréquente et consécutive à l’utilisation d’appareils personnels ». La DGFiP a procédé à la réinitialisation des mots de passe, mais si des machines restent infectées et/ou que les sessions actives ne sont pas coupées, cela n’est pas d’une grande utilité.

Preuve en est : la réinitialisation du 24 juin 2026 « n’interrompt pas la session et l’exfiltration en cours qui se poursuivent », précise l’ANSSI dans le détail de la chronologie des faits. Ajoutez à cela « l’absence d’authentification forte sur deux portails dont l’un donnant accès à des ressources sensibles » et vous avez un combo explosif.

Des indices en pagaille : IP en Inde, des Go téléchargés, connexions nocturnes

Autre problème pour l’ANSSI, le manque de détection : « Les sessions d’exfiltration menées par l’attaquant n’ont pas été détectées en temps réel par les mécanismes de contrôle implémentés sur les applicatifs métiers ni sur les équipements de sécurité de la DGFiP ».

Il y avait pourtant des indices élémentaires facile à identifier : « la volumétrie d’informations échangées lors des connexions (11Go entre le 22 et 25 juin, 3Go entre le 21 et 23 juillet) », ainsi que « le nombre de requêtes par utilisateur sur une plage temporelle ».

L’Agence prend soin de préciser que « la technique de scraping utilisée par les attaquants impose de devoir initier autant de requêtes que de pages accédées ». Cela aurait dû déclencher des alertes. Une technique connue depuis la nuit des temps aurait dû être mise en place : un rate-limiting. Le but est de bloquer un nombre trop important de requêtes, permettant aussi de limiter des attaques par force brute.

Ce n’est pas le seul problème. La DGFiP n’analysait pas les adresses IP puisque des connexions ont été réalisées « depuis des adresses de VPN, depuis des adresses localisées en Inde et pour plusieurs catégorisées comme malveillantes ». Ajoutez à cela des adresses IP déjà identifiées comme liées à un compte compromis qui peuvent revenir en toute impunité et des heures de connexions nocturnes ; vous avez un beau tableau de ce qu’il ne faut pas faire.

« Ces paramètres pris individuellement ne permettent généralement pas d’identifier des comportements suspects sans générer d’importants volumes de faux positifs, néanmoins la corrélation de plusieurs d’entre eux aurait pu permettre de lever des alertes », ajoute l’ANSSI.

Après « le besoin d’en connaître », le besoin d’y avoir accès

Troisième point de faiblesse : le RIE ou Réseau Interministériel de l’État, utilisé par les pirates pour accéder « au portail ADER [Accès Distant aux Échanges Réseau, ndlr] de la DGFiP ». Opérationnel depuis 2013, il raccorde les services de l’État. L’ANSSI note que « plusieurs accès illégitimes identifiés proviennent du RIE [la suite est caviardée, ndlr], à partir de localisations n’ayant pas de besoins apparents d’accéder à des infrastructures de la DGFiP ».

« Pendant l’incident, le SOC [Security Operation Center, ndlr] de la DGFiP ne supervisait pas le portail ADER, utilisé par l’attaquant pour exfiltrer les informations E-Contact », contrairement au portail PIGP (Portail internet de la gestion publique) qui était bien surveillé. Ce trou dans la raquette a permis aux pirates de s’infiltrer, mais a aussi empêché « de corréler des activités malveillantes avec le reste du SI ou en provenance du RIE suite à un signalement d’un autre ministère ».

• Le Réseau Interministériel de l’État (RIE) fête ses 10 ans et se modernise

Là encore on retrouve un basique de la cybersécurité : la segmentation réseau avec le cloisonnement des « accès aux seules populations et zones logiques qui en ont le besoin ». L’Agence recommande de mettre en place « un filtrage plus fin des accès réseau entre ministères et au sein du RIE ».

Comment les pirates sont rentrés dans le RIE ? Par la porte ouverte d’un autre piratage : « L’utilisation du RIE lui a été rendue possible à cause de la compromission d’infrastructures appartenant au ministère de l’Éducation nationale elles-mêmes raccordées au RIE ». Pour l’ANSSI, cela illustre parfaitement le « risque de latéralisation depuis des ressources d’organismes tiers » et le besoin de cloisonner.

Des signalements en pagaille

L’ANSSI fait son mea culpa sur sa supervision. « Les acteurs malveillants utilisaient des comptes légitimes pour accéder aux applications et la supervision réseau de l’Agence n’a pas permis de les voir ». De plus, « le volume cumulé de requêtes que l’attaquant a dû générer pour orchestrer l’exfiltration de données aurait dû déclencher des alertes ».

Dans la même veine, elle explique qu’un partenaire l’a informé le 15 juin de la compromission de deux comptes DGFIP. Cette dernière « ne répond pas et n’est pas relancée par l’Agence ». Nouveau signalement le 22 juin, suivi d’une action cette fois-ci : « un partenaire informe l’ANSSI de la compromission d’un compte. La DGFIP répond le jour même à l’ANSSI avoir réinitialisé ce compte et sensibilisé leur agent ».

D’autres signalements sont remontés dans la chronologie, notamment le 29 juin 2026 avec un bel acte manqué : « un partenaire informe l’ANSSI de la compromission du compte. Il s’agit du compte utilisé pour l’exfiltration de données le 24 juin 2026, or cette compromission n’était pas connue à cette date et les analyses menées par le SOC de la DGFIP ne l’identifient pas. La DGFIP répond le jour même à l’ANSSI avoir déjà connaissance de ce fait et confirme l’avoir réinitialisé ».

D’autres signalements ? Le 1ᵉʳ juillet, la « DGFIP est informée par son prestataire de la vente de deux comptes ». Là aussi le pot aux roses aurait pu être découvert : « les investigations montreront, à posteriori, des échecs de connexion sur le PIGP le même jour et le jour précédent avec ces comptes à partir d’une des adresses IP utilisées pour l’exfiltration du 24 juin 2026 ».

Plein de mesures de remédiation, ça fait pas de mal de les relire !

Enfin, l’ANSSI propose des mesures de remédiation (page 10) afin « d’assurer que le même chemin de compromission ne puisse être emprunté de nouveau, par le même acteur ou un nouveau ». Elles couvrent toutes les lacunes précédentes et ouvrent aussi de nouvelles pistes.

Cela va des restrictions d’accès aux ressources métiers à la protection contre les vols d’identifiants. On y retrouve notamment des propositions sur le matériel. « L’usage d’appareils personnels pour accéder à des ressources professionnelles doit être proscrit », et les machines professionnelles doivent être durcies. Évidemment, l’authentification multifacteurs doit être généralisée.

Pour les applications à usage interne, l’accessibilité ne doit se faire « que depuis des postes administrés par la DGFiP. Dans ce cas, l’accès à l’application ne doit pas être possible depuis Internet, sauf à travers un VPN dédié aux agents de la DGFiP ». Les VPN ne servent pas uniquement à contourner des restrictions, ils permettent aussi de renforcer la sécurité, mais attention aux promesses de certains !

• [Édito] Au pays des VPN menteurs…

Dans sa synthèse, l’ANSSI rappelle que l’exfiltration des données s’est produite sept semaines avant la revendication des pirates le 12 août, et « qu’elle a été précédée de plusieurs semaines d’exploration sur des applicatifs de la DGFIP ».

Des indices étaient bien présents, mais pas correctement pris en compte, c’est un rappel important pour toute la communauté cyber. En effet, ces recommandations peuvent s’appliquer bien au-delà de la DGFiP. Il est toujours bon de les lire et de vérifier qu’elles sont bien appliquées.

Le 28 septembre 2026, OpenAI a proposé que tout entraînement de ses modèles d'IA les plus avancés soit précédé d'un dossier démontrant que les risques sont maîtrisés.

Parole de pirate

ShinyHunters n’a pas l’intention de publier les données volées sur les serveurs du FBI. Le groupe de pirates avait donné une semaine à l’agence fédérale américaine pour corriger ou retirer un rapport jugé négatif à son égard. Alors que le délai arrive à son terme, « rien ne se passera ».

ShinyHunters a réussi un de ses plus gros coups le 22 septembre dernier, en piratant le site de recrutement du FBI et surtout, en siphonnant les données personnelles de plus de 5 000 agents et employés. Adresses physiques, rôles au sein de l’agence, dossiers médicaux, et même des informations sur les conjoints : plusieurs sites et spécialistes de la sécurité ont confirmé la véracité des données collectées illégalement. Il y en a pour 2 à 3 To d’informations sensibles.

• Les pirates de ShinyHunters affirment détenir les données de milliers d’employés du FBI

Le groupe de pirates accuse le FBI d’avoir publié des informations mensongères à leur sujet dans un bulletin de sécurité publié en mai. Selon l’interprétation de ShinyHunters, cette note les assimile à « The Com », un réseau international de criminels impliqués dans l’exploitation sexuelle des enfants.

ShinyHunters, dont le mode opératoire est la demande de rançon pour décadenasser des données, s’adonneraient aussi à des techniques de harcèlement de leurs victimes (appels téléphoniques aux familles, SMS menaçants…) et de chantage à base de documents embarrassants. Ce que le groupe dément également.

Un ultimatum qui ne devait pas en être un

Les pirates avaient donné une semaine au FBI pour modifier ou supprimer ce fameux bulletin. Le délai est en passe de se terminer, la note est toujours en ligne et n’a pas été éditée. Pour autant, ShinyHunters affirme n’avoir aucune intention de mettre en ligne toutes les informations volées, comme on aurait pu s’y attendre. Ce lâcher de données « était une supposition », assurent-ils dans un message quelque peu confus envoyé à Next, « et une très mauvaise supposition faite par les médias et le public ».

« Nous avons formulé nos déclarations avec beaucoup de soin, et nous n’avons jamais précisé ni indiqué explicitement ce que nous ferions si l’entité victime ne se conformait pas dans ce que le public a interprété comme une « échéance » », poursuit ShinyHunters. « Depuis le tout début, nous avions pris la décision de ne jamais publier ces données. Nous n’en avons jamais eu l’intention, et nous ne l’avons jamais prévu ».

Les informations subtilisées contiennent des bombes : Reuters a ainsi rapporté la présence de données concernant des agents engagés dans des opérations de contre-espionnage contre la Chine et la Russie. La BBC a débusqué des informations sur des tests sanguins et urinaires d’agents spéciaux. 404 Media a trouvé des données personnelles de membres de la Remote Operations Unit, l’équipe de hackers du FBI.

Des promesses impossibles à vérifier

La divulgation de ces informations aurait des conséquences très sérieuses pour des milliers d’agents, leurs familles, le FBI, la sécurité nationale américaine. « Nous comprenons pourquoi beaucoup ont interprété cela comme de l’extorsion et sont convaincus que nous publierions ces données et/ou en ferions un mauvais usage, par exemple en les vendant à des tiers, en raison de notre historique lors d’opérations passées, qui n’ont jamais impliqué une entité gouvernementale de premier plan », précise encore le groupe.

« Nous tenons encore une fois à souligner qu’il ne s’agit pas d’extorsion », martèle-t-il, « que cela ne l’a jamais été, qu’il ne s’agit pas d’une menace, ni d’une rançon, et que ce n’est pas motivé par l’argent. Rien ne se passera ». ShinyHunters termine par un curieux (ou ironique ?) « Nous reconnaissons nous être trompés » alors que les pirates ne reconnaissent justement aucune erreur de leur part dans leur message.

De son côté, le FBI a confirmé l’existence d’une enquête le 23 septembre. Selon un mémo interne publié le 28 septembre par le New York Times, l’agence part « du principe que l’auteur de la menace exfiltre également les données personnelles de l’ensemble des employés ».

L’agence propose des séances d’information virtuelles et recommande aux employés de rester vigilants, de signaler les contacts non sollicités, d’éviter de répondre aux appels provenant de numéros inconnus, et de configurer leur messagerie vocale avec une voix générée par IA (pour éviter le clonage des voix originales). Un représentant de ShinyHunters a réaffirmé à 404 Media qu’il n’était pas question de vendre ces To de données, mais est-ce que ce sera toujours le cas ?

Parole de pirate

ShinyHunters n’a pas l’intention de publier les données volées sur les serveurs du FBI. Le groupe de pirates avait donné une semaine à l’agence fédérale américaine pour corriger ou retirer un rapport jugé négatif à son égard. Alors que le délai arrive à son terme, « rien ne se passera ».

ShinyHunters a réussi un de ses plus gros coups le 22 septembre dernier, en piratant le site de recrutement du FBI et surtout, en siphonnant les données personnelles de plus de 5 000 agents et employés. Adresses physiques, rôles au sein de l’agence, dossiers médicaux, et même des informations sur les conjoints : plusieurs sites et spécialistes de la sécurité ont confirmé la véracité des données collectées illégalement. Il y en a pour 2 à 3 To d’informations sensibles.

• Les pirates de ShinyHunters affirment détenir les données de milliers d’employés du FBI

Le groupe de pirates accuse le FBI d’avoir publié des informations mensongères à leur sujet dans un bulletin de sécurité publié en mai. Selon l’interprétation de ShinyHunters, cette note les assimile à « The Com », un réseau international de criminels impliqués dans l’exploitation sexuelle des enfants.

ShinyHunters, dont le mode opératoire est la demande de rançon pour décadenasser des données, s’adonneraient aussi à des techniques de harcèlement de leurs victimes (appels téléphoniques aux familles, SMS menaçants…) et de chantage à base de documents embarrassants. Ce que le groupe dément également.

Un ultimatum qui ne devait pas en être un

Les pirates avaient donné une semaine au FBI pour modifier ou supprimer ce fameux bulletin. Le délai est en passe de se terminer, la note est toujours en ligne et n’a pas été éditée. Pour autant, ShinyHunters affirme n’avoir aucune intention de mettre en ligne toutes les informations volées, comme on aurait pu s’y attendre. Ce lâcher de données « était une supposition », assurent-ils dans un message quelque peu confus envoyé à Next, « et une très mauvaise supposition faite par les médias et le public ».

« Nous avons formulé nos déclarations avec beaucoup de soin, et nous n’avons jamais précisé ni indiqué explicitement ce que nous ferions si l’entité victime ne se conformait pas dans ce que le public a interprété comme une « échéance » », poursuit ShinyHunters. « Depuis le tout début, nous avions pris la décision de ne jamais publier ces données. Nous n’en avons jamais eu l’intention, et nous ne l’avons jamais prévu ».

Les informations subtilisées contiennent des bombes : Reuters a ainsi rapporté la présence de données concernant des agents engagés dans des opérations de contre-espionnage contre la Chine et la Russie. La BBC a débusqué des informations sur des tests sanguins et urinaires d’agents spéciaux. 404 Media a trouvé des données personnelles de membres de la Remote Operations Unit, l’équipe de hackers du FBI.

Des promesses impossibles à vérifier

La divulgation de ces informations aurait des conséquences très sérieuses pour des milliers d’agents, leurs familles, le FBI, la sécurité nationale américaine. « Nous comprenons pourquoi beaucoup ont interprété cela comme de l’extorsion et sont convaincus que nous publierions ces données et/ou en ferions un mauvais usage, par exemple en les vendant à des tiers, en raison de notre historique lors d’opérations passées, qui n’ont jamais impliqué une entité gouvernementale de premier plan », précise encore le groupe.

« Nous tenons encore une fois à souligner qu’il ne s’agit pas d’extorsion », martèle-t-il, « que cela ne l’a jamais été, qu’il ne s’agit pas d’une menace, ni d’une rançon, et que ce n’est pas motivé par l’argent. Rien ne se passera ». ShinyHunters termine par un curieux (ou ironique ?) « Nous reconnaissons nous être trompés » alors que les pirates ne reconnaissent justement aucune erreur de leur part dans leur message.

De son côté, le FBI a confirmé l’existence d’une enquête le 23 septembre. Selon un mémo interne publié le 28 septembre par le New York Times, l’agence part « du principe que l’auteur de la menace exfiltre également les données personnelles de l’ensemble des employés ».

L’agence propose des séances d’information virtuelles et recommande aux employés de rester vigilants, de signaler les contacts non sollicités, d’éviter de répondre aux appels provenant de numéros inconnus, et de configurer leur messagerie vocale avec une voix générée par IA (pour éviter le clonage des voix originales). Un représentant de ShinyHunters a réaffirmé à 404 Media qu’il n’était pas question de vendre ces To de données, mais est-ce que ce sera toujours le cas ?

Rester pertinent

Truecaller vient de lancer un service gratuit de vérification des arnaques. Accessible depuis le web, le service ambitionne de guider encore davantage les usagers, en leur donnant plus rapidement accès aux informations fréquemment cherchées, particulièrement en Inde.

Truecaller est un éditeur suédois connu pour son application du même nom, qui sert à la fois à identifier les appelants et à bloquer les appels et SMS indésirables. Elle affiche le nom de l’appelant et signale les numéros suspects à partir d’une base alimentée par ses utilisateurs, complétée par une détection automatique. Selon TechCrunch, l’application compte plus de 500 millions d’utilisateurs mensuels, dont plus de 350 millions en Inde, de loin son marché principal.

L’éditeur veut cependant aller plus loin. Avec son nouveau service Scam Checker, il se propose de remplir le rôle d’une recherche sur le web pour obtenir des compléments d’informations.

• Qui m’appelle ? Petit guide pratique contre la fraude téléphonique

All-in sur les arnaques

Fraîchement lancé ce 27 septembre, Scam Checker est un service web et Android qui permet de coller un numéro de téléphone, un lien ou un message suspect pour savoir s’il s’agit d’une fraude. Il fait remonter les signalements associés issus de ScamFeed, la communauté existante d’utilisateurs de Truecaller. Sous cette forme, aucune application ou compte n’est nécessaire. Les informations plus détaillées sur un numéro, dont le nom associé, restent réservées au service existant qui exige un compte.

Scam Checker développe les liens raccourcis et suit les redirections jusqu’à la destination finale. Ce résultat est comparé à la base de risques de Truecaller et d’autres indicateurs de fraude. Pour les messages directement copiés/collés dans l’interface, le service extrait le numéro ou le lien, puis remonte les signalements communautaires correspondants.

Truecaller prévoit d’ajouter la prise en charge d’un plus grand nombre de techniques d’arnaques, des captures d’écran et d’autres fonctions dans « un avenir proche ».

« Les gens sentent souvent que quelque chose ne va pas, mais ils ont besoin d’un moyen rapide de vérifier avant de répondre. Scam Checker réunit nos capacités de détection et ce que notre communauté a rapporté afin que les gens puissent enquêter sur un lien, un numéro ou une histoire suspecte en un seul endroit », indique le CEO de l’entreprise, Rishit Jhunjhunwala.

Côté disponibilité, le service est accessible dans l’ensemble des marchés depuis le site web officiel. En Inde, Scam Checker a également été intégré directement dans l’application Truecaller. La disponibilité de cette intégration dans les autres pays et dans l’application iOS sont prévues à « une date ultérieure », sans précision.

La récupération des recherches complémentaires

Truecaller justifie ce lancement par l’évolution des canaux d’arnaque. Elle se fonde sur les usages de recherche, notant par exemple une recrudescence des recherches sur le web pour obtenir des informations sur une suspicion d’arnaque.

Rishit Jhunjhunwala indique ainsi à TechCrunch : « Quand vous en avez besoin, vous êtes généralement ailleurs. Le lien apparaît sur WhatsApp. Votre mère reçoit un message concernant une amende de circulation. Un ami vous envoie une capture d’écran et vous demande : ‘Est-ce que c’est réel ?’. Ce que les gens font à ce moment-là, c’est une recherche ».

Sans trop de surprise, Truecaller a décidé d’exploiter la mine d’or que représente sa communauté. L’entreprise indique ainsi que ScamFeed, son flux participatif où les utilisateurs peuvent publier et discuter des arnaques, contient aujourd’hui 20 000 signalements environ. Mais ce chiffre croît rapidement, avec 1 300 nouveaux signalements chaque semaine. Truecaller indique en outre avoir analysé 12,9 milliards de messages dans le monde entre les 14 et 20 septembre et en avoir étiqueté 20,3 millions comme frauduleux.

Un contexte spécifique en Inde

Comme le notent nos confrères, ce lancement n’est pas un hasard. L’Inde est de très loin le plus gros marché de Truecaller, représentant environ 70 % de sa base d’utilisateurs. Or, la situation y évolue rapidement depuis plusieurs mois. En avril dernier, le site évoquait déjà une pression croissante autour de Truecaller, entre évolution des techniques, usage plus intensif de l’IA et renforcement divers dans les systèmes Android et iOS eux-mêmes. La croissance s’est ralentie et l’année 2025 a été particulièrement rude pour l’entreprise en bourse.

Plus récemment, la situation est devenue encore un peu plus tendue. Le gouvernement indien soutient ainsi un service central nommé Calling Name Presentation (CNAP), qui permet justement l’identification de l’appelant. Il est en cours d’intégration chez les opérateurs de téléphonie dans le pays. De plus, mi-septembre, la Telecom Regulatory Authority of India (TRAI) a rendu obligatoire le partage des informations collectées sur les numéros liés à des arnaques. Ces données doivent être partagées, là encore, avec les opérateurs de téléphonie, via l’utilisation d’une blockchain. Truecaller n’est guère satisfaite du changement, critiquant un « échange à sens unique ».

Truecaller veut donc rester pertinent face à une évolution rapide du contexte, en simplifiant cette étape de recherche des informations complémentaires. Scam Checker se présente en complément de l’activité principale, un canal d’acquisition et de collecte de signaux qui ne sont pas couverts par le CNAP ni les obligations imposées par le TRAI.

En France, Truecaller est un acteur parmi d’autres. Il fait face à des concurrents comme Saracroche ou même Orange Téléphone (utilisable sans être abonné à l’opérateur). En dépit d’une évolution législative importante avec la fin du démarchage téléphonique classique, on pourrait penser que ces applications sont moins importantes. Mais les appels restent fréquents, notamment parce que de nombreux acteurs malveillants ignorent la loi.

Enfin, précisons que si Scam Checker est ouvert à tous, il contient surtout pour l’instant des signalements portant sur l’Inde.

• Fin de Bloctel, interdiction du démarchage dès le 11 août : on fait le point

Rester pertinent

Truecaller vient de lancer un service gratuit de vérification des arnaques. Accessible depuis le web, le service ambitionne de guider encore davantage les usagers, en leur donnant plus rapidement accès aux informations fréquemment cherchées, particulièrement en Inde.

Truecaller est un éditeur suédois connu pour son application du même nom, qui sert à la fois à identifier les appelants et à bloquer les appels et SMS indésirables. Elle affiche le nom de l’appelant et signale les numéros suspects à partir d’une base alimentée par ses utilisateurs, complétée par une détection automatique. Selon TechCrunch, l’application compte plus de 500 millions d’utilisateurs mensuels, dont plus de 350 millions en Inde, de loin son marché principal.

L’éditeur veut cependant aller plus loin. Avec son nouveau service Scam Checker, il se propose de remplir le rôle d’une recherche sur le web pour obtenir des compléments d’informations.

• Qui m’appelle ? Petit guide pratique contre la fraude téléphonique

All-in sur les arnaques

Fraîchement lancé ce 27 septembre, Scam Checker est un service web et Android qui permet de coller un numéro de téléphone, un lien ou un message suspect pour savoir s’il s’agit d’une fraude. Il fait remonter les signalements associés issus de ScamFeed, la communauté existante d’utilisateurs de Truecaller. Sous cette forme, aucune application ou compte n’est nécessaire. Les informations plus détaillées sur un numéro, dont le nom associé, restent réservées au service existant qui exige un compte.

Scam Checker développe les liens raccourcis et suit les redirections jusqu’à la destination finale. Ce résultat est comparé à la base de risques de Truecaller et d’autres indicateurs de fraude. Pour les messages directement copiés/collés dans l’interface, le service extrait le numéro ou le lien, puis remonte les signalements communautaires correspondants.

Truecaller prévoit d’ajouter la prise en charge d’un plus grand nombre de techniques d’arnaques, des captures d’écran et d’autres fonctions dans « un avenir proche ».

« Les gens sentent souvent que quelque chose ne va pas, mais ils ont besoin d’un moyen rapide de vérifier avant de répondre. Scam Checker réunit nos capacités de détection et ce que notre communauté a rapporté afin que les gens puissent enquêter sur un lien, un numéro ou une histoire suspecte en un seul endroit », indique le CEO de l’entreprise, Rishit Jhunjhunwala.

Côté disponibilité, le service est accessible dans l’ensemble des marchés depuis le site web officiel. En Inde, Scam Checker a également été intégré directement dans l’application Truecaller. La disponibilité de cette intégration dans les autres pays et dans l’application iOS sont prévues à « une date ultérieure », sans précision.

La récupération des recherches complémentaires

Truecaller justifie ce lancement par l’évolution des canaux d’arnaque. Elle se fonde sur les usages de recherche, notant par exemple une recrudescence des recherches sur le web pour obtenir des informations sur une suspicion d’arnaque.

Rishit Jhunjhunwala indique ainsi à TechCrunch : « Quand vous en avez besoin, vous êtes généralement ailleurs. Le lien apparaît sur WhatsApp. Votre mère reçoit un message concernant une amende de circulation. Un ami vous envoie une capture d’écran et vous demande : ‘Est-ce que c’est réel ?’. Ce que les gens font à ce moment-là, c’est une recherche ».

Sans trop de surprise, Truecaller a décidé d’exploiter la mine d’or que représente sa communauté. L’entreprise indique ainsi que ScamFeed, son flux participatif où les utilisateurs peuvent publier et discuter des arnaques, contient aujourd’hui 20 000 signalements environ. Mais ce chiffre croît rapidement, avec 1 300 nouveaux signalements chaque semaine. Truecaller indique en outre avoir analysé 12,9 milliards de messages dans le monde entre les 14 et 20 septembre et en avoir étiqueté 20,3 millions comme frauduleux.

Un contexte spécifique en Inde

Comme le notent nos confrères, ce lancement n’est pas un hasard. L’Inde est de très loin le plus gros marché de Truecaller, représentant environ 70 % de sa base d’utilisateurs. Or, la situation y évolue rapidement depuis plusieurs mois. En avril dernier, le site évoquait déjà une pression croissante autour de Truecaller, entre évolution des techniques, usage plus intensif de l’IA et renforcement divers dans les systèmes Android et iOS eux-mêmes. La croissance s’est ralentie et l’année 2025 a été particulièrement rude pour l’entreprise en bourse.

Plus récemment, la situation est devenue encore un peu plus tendue. Le gouvernement indien soutient ainsi un service central nommé Calling Name Presentation (CNAP), qui permet justement l’identification de l’appelant. Il est en cours d’intégration chez les opérateurs de téléphonie dans le pays. De plus, mi-septembre, la Telecom Regulatory Authority of India (TRAI) a rendu obligatoire le partage des informations collectées sur les numéros liés à des arnaques. Ces données doivent être partagées, là encore, avec les opérateurs de téléphonie, via l’utilisation d’une blockchain. Truecaller n’est guère satisfaite du changement, critiquant un « échange à sens unique ».

Truecaller veut donc rester pertinent face à une évolution rapide du contexte, en simplifiant cette étape de recherche des informations complémentaires. Scam Checker se présente en complément de l’activité principale, un canal d’acquisition et de collecte de signaux qui ne sont pas couverts par le CNAP ni les obligations imposées par le TRAI.

En France, Truecaller est un acteur parmi d’autres. Il fait face à des concurrents comme Saracroche ou même Orange Téléphone (utilisable sans être abonné à l’opérateur). En dépit d’une évolution législative importante avec la fin du démarchage téléphonique classique, on pourrait penser que ces applications sont moins importantes. Mais les appels restent fréquents, notamment parce que de nombreux acteurs malveillants ignorent la loi.

Enfin, précisons que si Scam Checker est ouvert à tous, il contient surtout pour l’instant des signalements portant sur l’Inde.

• Fin de Bloctel, interdiction du démarchage dès le 11 août : on fait le point

Reprise en fanfare

Citrix a corrigé huit vulnérabilités critiques en urgence le 27 septembre dans deux produits NetScaler. Il est recommandé aux administrateurs concernés de les installer aussi rapidement que possible car deux d’entre elles sont déjà exploitées. C’est la troisième fois en quelques mois que des failles sont exploitées dans NetScaler.

L’urgence vient de la criticité des failles et de la situation : deux vulnérabilités, estampillées CVE-2026-88771 et CVE-2026-88772, étaient déjà exploitées avant même la publication des correctifs. En outre, il n’existe pas de mesure d’atténuation, la seule méthode pour restaurer la sécurité des équipements étant de les mettre à jour puis de vérifier s’ils ont été compromis, indique Citrix dans son bulletin.

Deux failles déjà exploitées

Des deux failles, CVE-2026-88771 est la plus grave. C’est un défaut de validation des entrées (CWE-20) qui permet à un attaquant non authentifié d’exécuter des commandes arbitraires. Son score CVSS est de 9,5 sur 10, soit proche du maximal. Elle touche tous les déploiements NetScaler ADC et NetScaler Gateway, y compris en configuration par défaut, sans besoin d’activer la moindre fonction particulière. Examiner la configuration ne sert donc à rien, seule la version installée compte.

L’autre faille, 2026 - 88772, est un débordement mémoire (CWE-19) affichant le même score CVSS de 9,5. Exploitée, elle aussi peut permettre des exécutions de code arbitraires, ou des dénis de service. Seule petite différence avec la première faille sur l’exploitation, il faut que DTLS soit actif, ce qui est le cas par défaut. Une passerelle est vulnérable si DTLS n’a pas été désactivé avec l’option -dtls OFF, et les autres serveurs virtuels le sont s’ils sont de type DTLS, indique Citrix.

Citrix liste les équipements concernés par l’exploitation de ces failles :

• NetScaler ADC et NetScaler Gateway 14.1 avant 14.1 - 73.37
• NetScaler ADC et NetScaler Gateway 13.1 avant 13.1 - 64.23
• NetScaler ADC FIPS avant 14.1 - 73.37 FIPS
• NetScaler ADC, FIPS et NDcPP avant 13.1 - 37.279

Six autres failles sont corrigées dans les mises à jour publiées ce dimanche, dont une critique. CVE-2026-88773 affiche ainsi un score CVSS de 9,3 et est de type contrebande de requêtes HTTP (HTTP Request Smuggling) à cause d’une interprétation incohérente des requêtes. Elle est à peine moins critique que les deux premières, mais elle ne semble pas activement exploitée. Les autres vulnérabilités affichent un score allant de 7 à 8,8 et sont donc de sévérité importante.

Vérifier la compromission

Les différents bulletins de sécurité avertissent que l’installation des correctifs est essentielle mais pas suffisante. Elle empêche simplement les nouvelles exploitations, mais ne peut rien dans le cas d’une exploitation déjà active.

Il est ainsi recommandé de conserver l’image mémoire de l’équipement et les journaux d’au moins un mois, puis de continuer à surveiller l’équipement après la mise à jour. Ensuite, comme indiqué notamment par watchTowr, il faut chercher des traces de compromission. Deux méthodes sont possibles : lancer l’analyse des marqueurs depuis la page de sécurité de la console NetScaler (version 14.1 - 73.36 ou ultérieure, avec télémétrie activée), ou demander les marqueurs au support Citrix.

Attention cependant, car Citrix prévient que ces marqueurs ne couvrent pas tous les types de compromissions. De fait, watchTowr conseille de renouveler l’ensemble des secrets et certifications stockés sur les équipements affectés, tandis que Bleeping Computer recommande de réduire autant que possible l’exposition à internet si les correctifs ne peuvent pas être installés rapidement.

Signes précurseurs

Selon Bleeping Computer, c’est le Centre national néerlandais de cybersécurité (NCSC) qui a réagi publiquement le premier. Il a envoyé une notification aux entreprises néerlandaises au sujet des deux failles critiques activement exploitées dans les produits NetScaler. Les informations du NCSC sont venues du CERT européen, qui a également publié son propre bulletin ce 27 septembre.

Nos confrères indiquent que la notification du NCSC est arrivée avant et ne contenait pas encore les CVE, qui n’avaient pas encore été publiés. Le message envoyé aux entreprises indiquait simplement que Citrix avait découvert ces failles en enquêtant sur des incidents signalés dans des environnements clients. L’entreprise avait alors découvert l’exploitation active. Il semble que les premiers signes soient apparus le 26 septembre sur un fil Reddit. Le même jour, la situation était débattue sur les réseaux sociaux, notamment par l’expert en cybersécurité Kevin Beaumont sur Mastodon.

L’information a rapidement circulé grâce au Cyber Resilience Act. Comme nous l’indiquions plus tôt dans le mois, le règlement européen instaurera un régime de responsabilité pour la sécurité des produits électroniques fin 2027. Mais depuis le 11 septembre, il rend obligatoire le signalement des failles découvertes aux CERT nationaux. Dans le cas présent, ce fonctionnement explique comment le NCSC a pu prévenir les entreprises néerlandaises avant la publication du bulletin de Citrix.

• Cyber Resilience Act : les obligations de signalement entrent en vigueur le 11 septembre

Point intéressant, le NCSC ne reconnait pas clairement l’envoi de sa notification. Interrogé par Bleeping Computer, le centre de sécurité a répondu qu’il était de son rôle de surveiller « les développements pertinents et les menaces cyber affectant les Pays-Bas ». Il a ajouté : « Nous fournissons des informations et des conseils aux organisations afin qu’elles puissent prendre les mesures appropriées. Comme vous ne faites pas partie de notre circonscription, nous ne pouvons divulguer aucune information supplémentaire pour le moment ». Depuis, le bulletin du centre néerlandais est devenu public.

Troisième vague d’attaques en deux mois

C’est la troisième vague de failles NetScaler exploitées en peu de temps. Selon Tenable, la CISA (Cybersecurity and Infrastructure Security Agency) américaine avait déjà ajouté CVE-2026-8452 à son catalogue en août, puis CVE-2026-19490 le 9 septembre, deux failles critiques ayant été activement exploitées.

Toujours d’après Tenable, environ deux tiers de l’activité malveillante visant NetScaler ces sept dernières années venaient de groupes étatiques (APT), et un tiers de groupes de rançongiciels et de leurs affiliés.

Reprise en fanfare

Citrix a corrigé huit vulnérabilités critiques en urgence le 27 septembre dans deux produits NetScaler. Il est recommandé aux administrateurs concernés de les installer aussi rapidement que possible car deux d’entre elles sont déjà exploitées. C’est la troisième fois en quelques mois que des failles sont exploitées dans NetScaler.

L’urgence vient de la criticité des failles et de la situation : deux vulnérabilités, estampillées CVE-2026-88771 et CVE-2026-88772, étaient déjà exploitées avant même la publication des correctifs. En outre, il n’existe pas de mesure d’atténuation, la seule méthode pour restaurer la sécurité des équipements étant de les mettre à jour puis de vérifier s’ils ont été compromis, indique Citrix dans son bulletin.

Deux failles déjà exploitées

Des deux failles, CVE-2026-88771 est la plus grave. C’est un défaut de validation des entrées (CWE-20) qui permet à un attaquant non authentifié d’exécuter des commandes arbitraires. Son score CVSS est de 9,5 sur 10, soit proche du maximal. Elle touche tous les déploiements NetScaler ADC et NetScaler Gateway, y compris en configuration par défaut, sans besoin d’activer la moindre fonction particulière. Examiner la configuration ne sert donc à rien, seule la version installée compte.

L’autre faille, 2026 - 88772, est un débordement mémoire (CWE-19) affichant le même score CVSS de 9,5. Exploitée, elle aussi peut permettre des exécutions de code arbitraires, ou des dénis de service. Seule petite différence avec la première faille sur l’exploitation, il faut que DTLS soit actif, ce qui est le cas par défaut. Une passerelle est vulnérable si DTLS n’a pas été désactivé avec l’option -dtls OFF, et les autres serveurs virtuels le sont s’ils sont de type DTLS, indique Citrix.

Citrix liste les équipements concernés par l’exploitation de ces failles :

• NetScaler ADC et NetScaler Gateway 14.1 avant 14.1 - 73.37
• NetScaler ADC et NetScaler Gateway 13.1 avant 13.1 - 64.23
• NetScaler ADC FIPS avant 14.1 - 73.37 FIPS
• NetScaler ADC, FIPS et NDcPP avant 13.1 - 37.279

Six autres failles sont corrigées dans les mises à jour publiées ce dimanche, dont une critique. CVE-2026-88773 affiche ainsi un score CVSS de 9,3 et est de type contrebande de requêtes HTTP (HTTP Request Smuggling) à cause d’une interprétation incohérente des requêtes. Elle est à peine moins critique que les deux premières, mais elle ne semble pas activement exploitée. Les autres vulnérabilités affichent un score allant de 7 à 8,8 et sont donc de sévérité importante.

Vérifier la compromission

Les différents bulletins de sécurité avertissent que l’installation des correctifs est essentielle mais pas suffisante. Elle empêche simplement les nouvelles exploitations, mais ne peut rien dans le cas d’une exploitation déjà active.

Il est ainsi recommandé de conserver l’image mémoire de l’équipement et les journaux d’au moins un mois, puis de continuer à surveiller l’équipement après la mise à jour. Ensuite, comme indiqué notamment par watchTowr, il faut chercher des traces de compromission. Deux méthodes sont possibles : lancer l’analyse des marqueurs depuis la page de sécurité de la console NetScaler (version 14.1 - 73.36 ou ultérieure, avec télémétrie activée), ou demander les marqueurs au support Citrix.

Attention cependant, car Citrix prévient que ces marqueurs ne couvrent pas tous les types de compromissions. De fait, watchTowr conseille de renouveler l’ensemble des secrets et certifications stockés sur les équipements affectés, tandis que Bleeping Computer recommande de réduire autant que possible l’exposition à internet si les correctifs ne peuvent pas être installés rapidement.

Signes précurseurs

Selon Bleeping Computer, c’est le Centre national néerlandais de cybersécurité (NCSC) qui a réagi publiquement le premier. Il a envoyé une notification aux entreprises néerlandaises au sujet des deux failles critiques activement exploitées dans les produits NetScaler. Les informations du NCSC sont venues du CERT européen, qui a également publié son propre bulletin ce 27 septembre.

Nos confrères indiquent que la notification du NCSC est arrivée avant et ne contenait pas encore les CVE, qui n’avaient pas encore été publiés. Le message envoyé aux entreprises indiquait simplement que Citrix avait découvert ces failles en enquêtant sur des incidents signalés dans des environnements clients. L’entreprise avait alors découvert l’exploitation active. Il semble que les premiers signes soient apparus le 26 septembre sur un fil Reddit. Le même jour, la situation était débattue sur les réseaux sociaux, notamment par l’expert en cybersécurité Kevin Beaumont sur Mastodon.

L’information a rapidement circulé grâce au Cyber Resilience Act. Comme nous l’indiquions plus tôt dans le mois, le règlement européen instaurera un régime de responsabilité pour la sécurité des produits électroniques fin 2027. Mais depuis le 11 septembre, il rend obligatoire le signalement des failles découvertes aux CERT nationaux. Dans le cas présent, ce fonctionnement explique comment le NCSC a pu prévenir les entreprises néerlandaises avant la publication du bulletin de Citrix.

• Cyber Resilience Act : les obligations de signalement entrent en vigueur le 11 septembre

Point intéressant, le NCSC ne reconnait pas clairement l’envoi de sa notification. Interrogé par Bleeping Computer, le centre de sécurité a répondu qu’il était de son rôle de surveiller « les développements pertinents et les menaces cyber affectant les Pays-Bas ». Il a ajouté : « Nous fournissons des informations et des conseils aux organisations afin qu’elles puissent prendre les mesures appropriées. Comme vous ne faites pas partie de notre circonscription, nous ne pouvons divulguer aucune information supplémentaire pour le moment ». Depuis, le bulletin du centre néerlandais est devenu public.

Troisième vague d’attaques en deux mois

C’est la troisième vague de failles NetScaler exploitées en peu de temps. Selon Tenable, la CISA (Cybersecurity and Infrastructure Security Agency) américaine avait déjà ajouté CVE-2026-8452 à son catalogue en août, puis CVE-2026-19490 le 9 septembre, deux failles critiques ayant été activement exploitées.

Toujours d’après Tenable, environ deux tiers de l’activité malveillante visant NetScaler ces sept dernières années venaient de groupes étatiques (APT), et un tiers de groupes de rançongiciels et de leurs affiliés.

L'Invasion des profanateurs de sépultURLs

Quatre nouveaux incidents impliquent des agents IA d’OpenAI. Ils ont tenté, en vain, d’exploiter des failles de sécurité et de pirater des sites web (dont deux sites de statistiques du ministère de la Santé australien), alors qu’ils effectuaient des tâches banales n’ayant aucun rapport avec la cybersécurité et consistant à trouver des réponses à des questions.

« Je tiens à informer les Australiens d’un incident au cours duquel un agent d’intelligence artificielle s’est infiltré sur un site web du gouvernement australien », a déclaré le Premier ministre australien, ce jeudi 24 septembre, lors d’une conférence de presse organisée à New York, en marge de la réunion du Conseil de sécurité de l’ONU consacrée aux risques de l’IA.

• À l’ONU, les patrons de l’IA réclament une régulation mondiale

Anthony Albanese a précisé que l’incident s’était produit en juin, que l’agent d’OpenAI avait « accédé sans autorisation » à des fichiers publics et non publics sur le portail public du service de rapports statistiques de Medicare, le service de sécurité sociale australien, mais qu’il semblait qu’aucune donnée personnelle n’avait été consultée.

Il a souligné s’être entretenu au téléphone avec le PDG d’OpenAI, Sam Altman, « afin d’exprimer la profonde inquiétude de l’Australie face à cet incident ». Il lui a également fait part de sa « déception » que l’entreprise « ait mis beaucoup trop de temps à informer le gouvernement de ce qui s’était passé, et que la manière dont cette notification a été effectuée était tout aussi inacceptable ».

L’incident remonte en effet au 18 juin dernier, mais l’entreprise n’a alerté Services Australia, l’autorité en charge de la sécurité sociale australienne, que le 10 septembre, par simple e-mail. Le 15, Services Australia alertait à son tour le Cyber Security Centre de l’Australian Signals Directorate (ASD, la NSA australienne).

Contacté par TechCrunch, OpenAI précise n’avoir découvert l’incident qu’au mois d’août, dans le cadre d’un examen plus large portant sur des agents présentant des comportements inattendus, faisant probablement suite à la cyberattaque de Hugging Face par un essaim d’agents d’OpenAI en juillet dernier.

• OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face

OpenAI n’a identifié « aucune preuve d’accès aux dossiers des patients »

Anthony Albanese a aussi annoncé la création d’un groupe de travail chargé de mener un examen « urgent et immédiat » de cet incident afin de déterminer si les processus existants « sont adaptés pour répondre aux incidents cybernétiques liés à l’IA ». Une enquête judiciaire menée avec le concours de l’ASD est également en cours, notamment pour déterminer quels autres systèmes gouvernementaux pourraient avoir été touchés.

Dans un communiqué, OpenAI explique avoir constaté une activité impliquant plusieurs sites web et services du gouvernement australien, « alors que nos modèles tentaient de rechercher des réponses et des statistiques disponibles concernant l’Australie dans le cadre d’une évaluation interne. Ce faisant, nos modèles ont pris des mesures que nous n’avions pas prévues ».

« Notre examen n’a révélé aucune preuve d’accès aux dossiers des patients », poursuit-il ; les informations consultées comprenaient des statistiques de santé agrégées et des noms de fichiers internes. OpenAI précise avoir informé les organisations concernées et leur fournir des informations techniques afin de les aider dans leurs enquêtes et remédier aux éventuelles failles de sécurité.

« Rien n’indique que cette activité constitue une menace plus large »

Le Cyber Security Centre de l’Australian Signals Directorate vient pour sa part de publier une alerte consacrée aux « risques liés au désalignement de l’IA pour les organisations australiennes », évoquant des agents IA ayant entrepris des « actions inattendues qui n’étaient ni prévues ni autorisées par leurs opérateurs » :

« Dans l’un de ces scénarios, l’agent IA a identifié de manière autonome des vulnérabilités et a tenté de poursuivre ses actions sans autorisation humaine directe afin de s’assurer qu’il serait en mesure d’accomplir la tâche qui lui avait été confiée. »

L’ASD précise toutefois que « les contrôles de cybersécurité mis en place sur les sites web et services publics des entités ont limité sa capacité à mener à bien la tâche qui lui avait été assignée ». Si « rien n’indique que cette activité constitue une menace plus large ou un acte malveillant visant l’Australie », l’alerte « souligne néanmoins l’importance de mettre en œuvre des pratiques de déploiement sécurisées de l’IA et de maintenir des principes fondamentaux solides en matière de cybersécurité ».

Classée « high » et adressée à toutes les organisations australiennes disposant de sites web ou d’applications accessibles au grand public, l’alerte de la NSA australienne a fait un bide sur X.com. Plusieurs professionnels de la cybersécurité l’y ont en effet brocardé au motif que le « site gouvernemental » n’avait rien de critique, que l’alerte « high » s’adresse aussi et étrangement aux individus et aux familles, et qu’elle contribue à la « fatigue » qu’éprouvent les équipes de cybersécurité au sujet de ce type de menaces surmédiatisées.

Trois nouveaux incidents impliquant des agents d’OpenAI tentant de pirater des sites

Cette annonce intervient en effet alors que, la semaine passée, OpenAI rendait publics six autres exemples d’agents IA « désalignés ». Des chercheurs de Transluce, Corridor et du MIT viennent par ailleurs d’en découvrir trois autres.

Le gestionnaire de mots de passe KeePass XC est une variante multiplateforme de KeePass, avec comme objectif une plus grande richesse fonctionnelle de base, sans passer par des plugins. La version 2.8, en préparation et dont une bêta vient de paraitre, s’annonce déjà comme une mouture majeure.

KeePass XC 2.8 bénéficie en effet d’un portage vers Qt 6, avec à la clé une modernisation de son interface et de ses intégrations dans les différentes plateformes prises en charge. Parmi les améliorations, on note surtout l’arrivée de l’auto-remplissage (fonction Auto-Type) pour les sessions Wayland, c’est-à-dire la capacité à insérer rapidement un identifiant et un mot de passe dans la fenêtre d’une application.

L’ajout est majeur, car Wayland ne permet plus « d’espionner » simplement une fenêtre active pour savoir si elle présente des champs d’authentification. La compatibilité annoncée va se faire à travers les portails XDG, ce qui revient à demander l’autorisation à Wayland d’examiner la fenêtre et d’y insérer des informations. L’équipe de KeePass XC avertit que ce support dépend pour l’instant de l’environnement choisi : support complet pour KDE 6.6 +, initial pour GNOME 48 + et dépendant du support des portails XDG dans les autres (Sway, Hyprland, labwc…).

Les autres améliorations sont nombreuses, avec par exemple l’arrivée d’une version compilée nativement pour les systèmes Windows ARM64 (y compris pour la version portable), une meilleure intégration sur Linux via l’AppImage, la possibilité de montrer des suggestions quand on ajoute des attributs, le support des clés d’accès (passkeys) dans les statistiques, la synchronisation des bases de données distantes via des outils tiers, des raccourcis clavier personnalisables ou encore le déverrouillage rapide sur macOS et Linux, respectivement via le mot de passe et Polkit. Enfin, plusieurs vulnérabilités ont été corrigées.

Pour les utilisateurs aventureux, le téléchargement de cette première bêta peut se faire depuis l’annonce officielle.

Le gestionnaire de mots de passe KeePass XC est une variante multiplateforme de KeePass, avec comme objectif une plus grande richesse fonctionnelle de base, sans passer par des plugins. La version 2.8, en préparation et dont une bêta vient de paraitre, s’annonce déjà comme une mouture majeure.

KeePass XC 2.8 bénéficie en effet d’un portage vers Qt 6, avec à la clé une modernisation de son interface et de ses intégrations dans les différentes plateformes prises en charge. Parmi les améliorations, on note surtout l’arrivée de l’auto-remplissage (fonction Auto-Type) pour les sessions Wayland, c’est-à-dire la capacité à insérer rapidement un identifiant et un mot de passe dans la fenêtre d’une application.

L’ajout est majeur, car Wayland ne permet plus « d’espionner » simplement une fenêtre active pour savoir si elle présente des champs d’authentification. La compatibilité annoncée va se faire à travers les portails XDG, ce qui revient à demander l’autorisation à Wayland d’examiner la fenêtre et d’y insérer des informations. L’équipe de KeePass XC avertit que ce support dépend pour l’instant de l’environnement choisi : support complet pour KDE 6.6 +, initial pour GNOME 48 + et dépendant du support des portails XDG dans les autres (Sway, Hyprland, labwc…).

Les autres améliorations sont nombreuses, avec par exemple l’arrivée d’une version compilée nativement pour les systèmes Windows ARM64 (y compris pour la version portable), une meilleure intégration sur Linux via l’AppImage, la possibilité de montrer des suggestions quand on ajoute des attributs, le support des clés d’accès (passkeys) dans les statistiques, la synchronisation des bases de données distantes via des outils tiers, des raccourcis clavier personnalisables ou encore le déverrouillage rapide sur macOS et Linux, respectivement via le mot de passe et Polkit. Enfin, plusieurs vulnérabilités ont été corrigées.

Pour les utilisateurs aventureux, le téléchargement de cette première bêta peut se faire depuis l’annonce officielle.

Le FBI piégé

Le FBI a été visé par une attaque de ShinyHunters. Le groupe de pirates serait en possession de données concernant des milliers d’employés de l’Agence fédérale. Parmi les informations volées : noms, adresses, numéros de téléphone et des données sur la famille des employés.

Pour prouver leur intrusion, les pirates ont détourné le site de recrutement du FBI. Pendant quelques minutes, on pouvait y lire que « le site a été saisi par ShinyHunters » et que « toutes les données du FBI ont été compromises, notamment des données personnelles et médicales sensibles concernant les employés actuels et anciens du FBI ».

Le groupe déclare aussi posséder « bien plus de données que ce que nous affirmons ici ». Avant de terminer par une formule typique de Donald Trump : « Merci de l’attention que vous porterez à cette affaire. »

Le même site a rapidement affiché un message d’erreur prévenant que le portail de candidature est actuellement indisponible, toujours en ligne à l’heure où nous publions. Le site principal fbi.gov a lui aussi été placé en indisponibilité, d’après nos constatations.

Un échantillon des données fourni au site 404media semble bien confirmer la nature et l’ampleur du vol de données. Selon nos confrères, ShinyHunters a exploité une faille zero-day dans PeopleSoft, un logiciel Oracle, pour obtenir un accès aux serveurs AWS GovCloud et siphonner les données. Il y en aurait pour 2 à 3 To.

Le FBI sommé de retirer ses accusations

ShinyHunters est bien connu des services, en France comme à l’étranger. On leur doit de nombreux vols de données qu’ils tentent ensuite de rançonner. Pour le FBI, les choses sont un peu différentes. Un « avis public » placardé sur le site du groupe accuse l’agence fédérale d’avoir porté des accusations mensongères envers l’organisation dans un bulletin publié au deuxième trimestre.

• Vols de données : des pirates de moins de 25 ans, seuls dans leurs chambres

Au lieu d’argent, les pirates exigent la modification ou le retrait du bulletin en question dans la semaine, au risque de la divulgation des données subtilisées. Ils réfutent notamment les allégations du FBI selon lesquels ShinyHunter met en œuvre des méthodes relevant du harcèlement ou de menaces personnelles adressées à leurs victimes.

Ils nient par ailleurs tout lien avec « The Com », un réseau criminel international décentralisé de pirates opérant aux États-Unis, au Canada et au Royaume-Uni. Ciblé par des enquêtes du FBI et d’Europol, ce réseau rassemble des sous-groupes impliqués dans la cybercriminalité, mais aussi dans l’exploitation sexuelle des enfants.

• Europol alerte sur l’essor de communautés en ligne dédiées à torturer des enfants

Dans le message de ShinyHunters, The Com est qualifié d’« élément de propagande inventé par le secteur de la sécurité informatique ayant endoctriné d’anciens responsables du FBI et du ministère de la Justice au point de les amener à donner une existence officielle à cette absurdité ». Le bulletin ne fait pas référence à The Com, en revanche il explique que les acteurs malveillants comme ShinyHunters peuvent prétendre à tort posséder des documents compromettantes sur leurs victimes, comme des photographies ou des vidéos embarrassantes de leurs victime.

Ils peuvent aussi recourir à des stratégies de harcèlement, comme l’envoi de SMS menaçants ou des appels téléphoniques aux victimes et aux membres de leur famille. ShinyHunters affirme « sans équivoque » n’avoir jamais menacé les familles ou détenu des informations compromettantes de leurs victimes. « NOUS NE PRATIQUONS PAS LA SEXTORSION », écrivent-ils en majuscules.

L’avis, qui n’est pas « motivé par des considérations financières », est présenté comme le moyen pour ShinyHunters de faire valoir leur droit à la libre expression tel qu’inscrit dans le Premier amendement de la Constitution américain. « [Nous] luttons contre la désinformation ». Pour l’instant, le FBI n’a pas encore réagi publiquement.

Mise à jour 23/09 – Le FBI a officiellement réagi à la fuite de données de ses serveurs. « L’origine de la faille [n’a] pas encore été déterminée », explique l’agence qui ne peut pas encore dire si elle provient « d’un tiers ou de l’environnement informatique du FBI ». L’enquête est en cours, et le FBI travaille avec ses prestataires pour atténuer tous les risques possibles.