Le gouvernement veut-il sacrifier les VPN sur l'autel de la vérification de l'âge ? Face aux menaces sur le télétravail et la sécurité, le député Philippe Latombe somme la ministre de clarifier sa position.
Après un incendie à Montreuil, un second Volkswagen ID. Buzz a pris feu dans une station de recharge TotalEnergies à Toulouse le 12 mai 2026. Cet incident met en lumière un enjeu crucial : le respect strict des procédures de rappel constructeur.
Deming est un outil Open Source (GPL 3.0) de gestion de Système de Management de la Sécurité de l'Information (SMSI). Conçu par un responsable de la sécurité des systèmes d'information (RSSI) pour des RSSI, il couvre la gestion des contrôles, le registre des risques, la gestion des exceptions et des plans d'action. Largement adopté par la communauté, il se distingue par sa simplicité d'utilisation et de mise en œuvre.
C'est l'une des forces de Deming : il ne présuppose aucun cadre normatif particulier. Il est livré avec une dizaine de référentiels prêts à l'emploi — ISO 27001 (2013, 2022, 2023 en allemand), ISO 22301, DORA, NIS2 (FR/EN/DE), HDS, PCI-DSS v4, NIST SP 800-53 Rev.5, MPA Best Practices — et permet d'en importer de nouveaux via un simple fichier Excel, sans développement.
Deming propose une gestion centralisée des contrôles avec planification, assignation de responsables et rappels, un registre des risques avec scoring configurable (ISO 27005, BSI 200-3 et autres formules), un module de gestion des exceptions avec workflow d'approbation, ainsi que des tableaux de bord et des rapports de pilotage pour les revues de direction.
L'application est développée en PHP/Laravel, avec MariaDB/MySQL comme base de données principale (PostgreSQL et SQLite également supportés). Le déploiement se fait en quelques commandes via Docker Compose, ou manuellement sur Debian/Ubuntu grâce aux guides fournis dans le dépôt.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Le virus s'appelle Andes. C'est l'unique souche d'hantavirus connue capable de se transmettre d'humain à humain, une exception dans cette famille de virus habituellement confinée aux rongeurs. Mortalité brute : 30 à 40 %. Pas de traitement spécifique, pas de vaccin homologué, juste des soins de support. L'incubation peut atteindre 6 semaines, ce qui transforme chaque contact en bombe à retardement épidémiologique.
Le MV Hondius a quitté l'Argentine début avril pour une croisière ornithologique. Depuis, le virus a fait son chemin : un premier mort à bord, des passagers débarqués dispersés dans plusieurs pays, une quarantaine de jours d'errance avant qu'un port européen accepte de recevoir le navire. Dimanche 10 mai : arrivée à Tenerife. Ambulances, combinaisons, masques FFP2, transferts par petits groupes. Les 5 Français sont rapatriés à l'hôpital Bichat. Et l'un d'eux s’avère symptomatique dans l'avion. Sébastien Lecornu prend un décret d'isolement en urgence. 45 jours de quarantaine à domicile pour chacun.
Toute cette mobilisation pour quelques personnes alors qu’il existait une façon de ne pas en arriver là.
Ces informations enregistrées, maintenant, essayez d’envisager une technologie capable d'inactiver n'importe quel pathogène aéroporté (virus, bactérie, spore) en une fraction de seconde, sans distinction d'espèce, de résistance aux antibiotiques ou de capacité à échapper aux vaccins. Une technologie qui serait potentiellement capable de fonctionner contre l'hantavirus, comme elle le fait avec la grippe, le COVID, la tuberculose, ou le prochain virus que nous n'avons pas encore nommé.
Cette technologie existe, elle s'appelle le far-UVC.
Article réservé à nos abonnés.
L’article Cette technologie ignorée qui pourrait tuer l’hantavirus avant qu’il ne vous tue est apparu en premier sur Les Électrons Libres.
Un « avant-goût de ce qui nous attend » : c’est ainsi que John Hultquist, chef analyste du Google Threat Intelligence Group (GTIG), a qualifié la découverte du labo. Les chercheurs en sécurité de l’entreprise ont identifié un acteur malveillant utilisant un exploit « zero-day » vraisemblablement développé avec l’aide de l’IA.
Le ou les cybercriminels prévoyaient d’exploiter cette vulnérabilité « dans le cadre d’une campagne d’exploitation massive ». Cette « découverte proactive » a permis d’éviter le pire, même si Google ne peut pas exclure que la vulnérabilité — implémenté sous la forme d’un script Python — a pu être exploitée à plus petite échelle (le labo n’a cependant pas vu de campagne active). Le GTIG se veut discret : il ne révèle pas le nom des criminels, mais précise que des acteurs en Corée du Nord et en Chine s’intéressent à l’utilisation de l’IA pour débusquer des failles de sécurité.
Google n’indique pas non plus le logiciel affecté par cette faille, si ce n’est qu’il s’agit d’un outil d’administration open-source très utilisé. La vulnérabilité permettait de contourner la double authentification (2FA), mais les pirates devaient au préalable connaître les identifiants et mots de passe de leurs victimes. Le GTIG a prévenu de manière responsable l’éditeur concerné, dont le nom n’a pas été révélé, pour corriger la faille.
Le groupe de chercheurs constate que les acteurs malveillants utilisent de plus en plus les outils d’IA des assistants « niveau expert » pour la recherche de vulnérabilités et le développement d’exploits, y compris pour des failles zero-day. Le verre à moitié plein, c’est que ces mêmes outils sont aussi aux mains des défenseurs. Ce serait la raison pour laquelle OpenAI et Anthropic réservent leurs modèles de cybersécurité à des organisations et des entreprises triées sur le volet.
De la même manière, le GTIG ne dévoile pas le modèle IA utilisé pour cette faille. « Nous ne pensons pas que Gemini a été utilisé », avance-t-il prudemment. Mais la structure et le contenu de l’exploit donne au labo de fortes raisons de croire que l’acteur a eu recours à un modèle AI « pour faciliter la découverte et l’exploitation de cette vulnérabilité ».
Les grands modèles de langage actuels ont encore du mal à appréhender les logiques complexes d’autorisation en entreprise, détaillent les chercheurs. Par contre, « ils sont de plus en plus capables d’effectuer un raisonnement contextuel en interprétant l’intention du développeur ». Dans le cas qui nous intéresse, la faille ne provient pas d’un bug technique classique, mais d’un passe-droit intégré directement dans le code qui permettait dans certains cas de contourner la 2FA.
Les chercheurs estiment que les LLM sont particulièrement efficaces pour identifier ces erreurs logiques de haut niveau, qui sont souvent invisibles pour les outils de détection traditionnels. Cette découverte est qualifiée de première par Google et par des spécialistes en cybersécurité indépendants.
« Nous pensons que ce n’est que la partie émergée de l’iceberg », s’alarme John Hultquist auprès du New York Times. « Le problème est probablement bien plus vaste ; c’est simplement la première preuve tangible que nous pouvons observer. » Il est évidemment difficile d’assurer à 100 % que du code a été écrit par un humain ou une IA. Mais dans ce cas précis, les indices relevés par le GTIG (trop de texte explicatif, un style de code très propre et scolaire, une mise en forme jugée caractéristique des données d’entraînement des LLM) font pencher nettement la balance vers l’hypothèse IA.
Ce premier cas possible de faille zero-day développée avec l’IA devrait en tout cas renforcer les appels à un encadrement plus strict des modèles IA les plus avancés. L’administration Trump voudrait ainsi avoir un droit de regard sur les LLM avant leur diffusion, pour s’assurer de leur innocuité.
Le 11 mai 2026, Google a publié un rapport consacré à l’usage de l’intelligence artificielle dans les menaces cyber. L’entreprise y décrit un cas inédit : des cybercriminels auraient utilisé un modèle d’IA pour développer un exploit zero-day capable de contourner une authentification à deux facteurs (2FA).
Plus besoin de connaissances en HTML ou en JavaScript pour développer des web apps : il suffit de la décrire à une des plateformes de vibe coding qui se partagent un marché florissant. Mais la sécurité est le parent pauvre de cette pratique.
Les apps générées par IA publiées sur internet sont souvent peu sécurisées. Red Access, une entreprise spécialisée dans la sécurité dans le nuage, et son cofondateur Dor Zvi ont analysé des milliers de web apps créées avec des outils comme Lovable, Replit, Base44 et Netlify. Le résultat fait froid dans le dos : plus de 5 000 d’entre elles ne présentent aucune authentification ni véritable sécurité.
Il suffit de trouver l’URL du site web pour accéder aux données de ces applications. D’autres n’opposaient comme résistance que des barrières faciles à franchir, comme l’obligation de se connecter avec une adresse email. Environ 40 % de ces web apps exposent des données sensibles, des documents confidentiels ou des historiques de conversation entre clients et chatbots. Dor Zvi tire la sonnette d’alarme chez Wired :
« Des organisations se retrouvent à divulguer des données privées via des applications créées avec le vibe coding. C’est l’un des plus grands cas de fuite où des personnes exposent des informations d’entreprise ou d’autres données sensibles à n’importe qui dans le monde. »
Parmi les trouvailles de l’équipe de Red Access : des plannings d’hôpitaux avec des informations personnelles sur des médecins, les achats publicitaires d’une entreprise, une présentation de lancement commercial, les registres de cargaisons d’une société de transport… Dans certains cas, Dor Zvi aurait pu obtenir les privilèges admin de certaines de ces apps en ligne — et même supprimer des comptes administrateurs.
Les plateformes de vibe coding permettent aux utilisateurs d’héberger leurs web apps directement sur leurs propres domaines. Pour mettre la main dessus, les chercheurs ont simplement utilisé Google ou Bing. Ils ont également trouvé plusieurs sites d’hameçonnage reproduisant ceux de grandes entreprises, créés et hébergés chez Lovable.
« Certains utilisateurs ont publié sur le web des applications qui auraient dû rester privées », explique Amjad Masad, le directeur général de Replit. « Qu’une application publique soit accessible sur internet est donc un comportement attendu. Les paramètres de confidentialité peuvent être modifiés à tout moment en un clic. » Rappelant l’existence d’outils de sécurité sur sa plateforme, le dirigeant s’engage à basculer les applications en mode privé et à informer les utilisateurs, si Red Access décide de lui transmettre une liste de ces derniers.
Masad reproche au passage le délai très court donné par la société de cybersécurité : « moins de 24 heures » avant de rendre l’affaire publique, ce qui n’a guère laissé de temps à Replit pour s’organiser. Le 6 mai, Replit annonçait que tous les utilisateurs du service, gratuit comme payant, peuvent publier leurs apps en mode privé. Une fonction qui était réservée auparavant aux clients Pro et Enterprise.
Chez Lovable, on indique également que les utilisateurs ont des outils de sécurité à leur disposition, « mais la manière dont une application est configurée relève au final de la responsabilité de son créateur ». Même discours du côté de Base44 : « Désactiver ces contrôles [de sécurité] est une action volontaire et simple, que n’importe quel utilisateur peut effectuer ». Une web app rendue publique est « un choix de configuration de l’utilisateur, et pas une faille de la plateforme ».
Base44 rappelle aussi qu’il est très simple de générer des données ressemblant à des vraies. Malgré tout, le risque d’exposer des informations confidentielles via des web apps vibe-codées reste réel. Ces outils sont utilisés par des utilisateurs n’ayant pas nécessairement le bagage technique suffisant pour sécuriser leurs données en ligne.
« N’importe qui dans une entreprise peut générer une application à tout moment, sans passer par un cycle de développement standard ni par le moindre contrôle de sécurité », prévient Dor Zvi. Les plateformes ont une responsabilité ici, celle de mettre en place des garde-fous pour éviter un tsunami potentiel de fuites de données.
Plus besoin de connaissances en HTML ou en JavaScript pour développer des web apps : il suffit de la décrire à une des plateformes de vibe coding qui se partagent un marché florissant. Mais la sécurité est le parent pauvre de cette pratique.
Les apps générées par IA publiées sur internet sont souvent peu sécurisées. Red Access, une entreprise spécialisée dans la sécurité dans le nuage, et son cofondateur Dor Zvi ont analysé des milliers de web apps créées avec des outils comme Lovable, Replit, Base44 et Netlify. Le résultat fait froid dans le dos : plus de 5 000 d’entre elles ne présentent aucune authentification ni véritable sécurité.
Il suffit de trouver l’URL du site web pour accéder aux données de ces applications. D’autres n’opposaient comme résistance que des barrières faciles à franchir, comme l’obligation de se connecter avec une adresse email. Environ 40 % de ces web apps exposent des données sensibles, des documents confidentiels ou des historiques de conversation entre clients et chatbots. Dor Zvi tire la sonnette d’alarme chez Wired :
« Des organisations se retrouvent à divulguer des données privées via des applications créées avec le vibe coding. C’est l’un des plus grands cas de fuite où des personnes exposent des informations d’entreprise ou d’autres données sensibles à n’importe qui dans le monde. »
Parmi les trouvailles de l’équipe de Red Access : des plannings d’hôpitaux avec des informations personnelles sur des médecins, les achats publicitaires d’une entreprise, une présentation de lancement commercial, les registres de cargaisons d’une société de transport… Dans certains cas, Dor Zvi aurait pu obtenir les privilèges admin de certaines de ces apps en ligne — et même supprimer des comptes administrateurs.
Les plateformes de vibe coding permettent aux utilisateurs d’héberger leurs web apps directement sur leurs propres domaines. Pour mettre la main dessus, les chercheurs ont simplement utilisé Google ou Bing. Ils ont également trouvé plusieurs sites d’hameçonnage reproduisant ceux de grandes entreprises, créés et hébergés chez Lovable.
« Certains utilisateurs ont publié sur le web des applications qui auraient dû rester privées », explique Amjad Masad, le directeur général de Replit. « Qu’une application publique soit accessible sur internet est donc un comportement attendu. Les paramètres de confidentialité peuvent être modifiés à tout moment en un clic. » Rappelant l’existence d’outils de sécurité sur sa plateforme, le dirigeant s’engage à basculer les applications en mode privé et à informer les utilisateurs, si Red Access décide de lui transmettre une liste de ces derniers.
Masad reproche au passage le délai très court donné par la société de cybersécurité : « moins de 24 heures » avant de rendre l’affaire publique, ce qui n’a guère laissé de temps à Replit pour s’organiser. Le 6 mai, Replit annonçait que tous les utilisateurs du service, gratuit comme payant, peuvent publier leurs apps en mode privé. Une fonction qui était réservée auparavant aux clients Pro et Enterprise.
Chez Lovable, on indique également que les utilisateurs ont des outils de sécurité à leur disposition, « mais la manière dont une application est configurée relève au final de la responsabilité de son créateur ». Même discours du côté de Base44 : « Désactiver ces contrôles [de sécurité] est une action volontaire et simple, que n’importe quel utilisateur peut effectuer ». Une web app rendue publique est « un choix de configuration de l’utilisateur, et pas une faille de la plateforme ».
Base44 rappelle aussi qu’il est très simple de générer des données ressemblant à des vraies. Malgré tout, le risque d’exposer des informations confidentielles via des web apps vibe-codées reste réel. Ces outils sont utilisés par des utilisateurs n’ayant pas nécessairement le bagage technique suffisant pour sécuriser leurs données en ligne.
« N’importe qui dans une entreprise peut générer une application à tout moment, sans passer par un cycle de développement standard ni par le moindre contrôle de sécurité », prévient Dor Zvi. Les plateformes ont une responsabilité ici, celle de mettre en place des garde-fous pour éviter un tsunami potentiel de fuites de données.
La France Insoumise (LFI) a informé certains de ses adhérents ou sympathisants d’un vol de données personnelles survenu au niveau de ses outils internes. Elle y indique avoir été victime d’une attaque cybercriminelle susceptible d’avoir conduit à l’exposition d’informations telles que le nom et prénom, l’adresse email, l’adresse postale, les « informations de profil » et la « participation à certains groupes ou événements ».
Le parti politique ne précise pas le canal par lequel a été réalisée l’attaque, mais les informations personnelles évoquées, notamment l’allusion aux groupes ou événements, suggèrent qu’il pourrait s’agir du site actionpopulaire.fr, la plateforme via laquelle LFI propose à ses sympathisants d’organiser leurs actions de terrain.
Cette allusion aux groupes semble également cohérente avec les revendications publiées par un internaute le 7 mai dernier sur un forum spécialisé. Celui-ci affirmait avoir réalisé un dump (une copie) du site actionpopulaire.fr, qui lui donnerait accès à 120 000 emails uniques, 20 000 numéros de téléphone, un nombre non précisé d’adresses physiques, ainsi qu’aux messages et échanges réalisés par l’intermédiaire de la plateforme.
Outre les messages individuels adressés aux victimes potentielles, LFI a communiqué de façon plus large auprès de ses sympathisants. Signé par Manuel Bompard et diffusé, notamment, sur les canaux Discord du parti, le message admet une fuite, mais ne corrobore pas les allégations du pirate supposé :
« Nous sommes encore en train d’investiguer pour préciser les conséquences de ces attaques. Il semble qu’en effet des données liées à certaines personnes ont pu être compromises. En revanche, contrairement à ce qui a été indiqué sur les réseaux sociaux, il ne s’agit ni du fichier de tou·tes les utilisateur·rices d’Action populaire, ni des signataires sur le site de soutien de la campagne présidentielle. »
Le coordinateur du parti confirme par ailleurs qu’une plainte va être déposée, outre l’alerte transmise à la CNIL et à l’ANSSI. « De manière générale, dans le contexte de généralisation de piratages de données ayant par exemple visé des institutions publiques, nous invitons tou·tes les camarades à faire preuve de la plus grande vigilance dans les messages qu’elles et ils pourraient recevoir sur leurs coordonnées personnelles », écrit encore le parti, avant d’appeler aux habituels conseils de vigilance.
La divulgation de cette attaque intervient alors que le leader du parti, Jean-Luc Mélenchon, a annoncé dimanche 3 mai, au 20 heures de TF1, sa candidature à l’élection présidentielle de 2027. Le dépôt GitHub dédié au code d’actionpopulaire.fr témoigne quant à lui d’une forte accélération du volume de commits depuis le 23 avril dernier.
Rappelons que d’un point de vue réglementaire, les informations qui révèlent l’orientation politique relèvent de ce que le RGPD qualifie, dans son article 9, de « données sensibles ».
La France Insoumise (LFI) a informé certains de ses adhérents ou sympathisants d’un vol de données personnelles survenu au niveau de ses outils internes. Elle y indique avoir été victime d’une attaque cybercriminelle susceptible d’avoir conduit à l’exposition d’informations telles que le nom et prénom, l’adresse email, l’adresse postale, les « informations de profil » et la « participation à certains groupes ou événements ».
Le parti politique ne précise pas le canal par lequel a été réalisée l’attaque, mais les informations personnelles évoquées, notamment l’allusion aux groupes ou événements, suggèrent qu’il pourrait s’agir du site actionpopulaire.fr, la plateforme via laquelle LFI propose à ses sympathisants d’organiser leurs actions de terrain.
Cette allusion aux groupes semble également cohérente avec les revendications publiées par un internaute le 7 mai dernier sur un forum spécialisé. Celui-ci affirmait avoir réalisé un dump (une copie) du site actionpopulaire.fr, qui lui donnerait accès à 120 000 emails uniques, 20 000 numéros de téléphone, un nombre non précisé d’adresses physiques, ainsi qu’aux messages et échanges réalisés par l’intermédiaire de la plateforme.
Outre les messages individuels adressés aux victimes potentielles, LFI a communiqué de façon plus large auprès de ses sympathisants. Signé par Manuel Bompard et diffusé, notamment, sur les canaux Discord du parti, le message admet une fuite, mais ne corrobore pas les allégations du pirate supposé :
« Nous sommes encore en train d’investiguer pour préciser les conséquences de ces attaques. Il semble qu’en effet des données liées à certaines personnes ont pu être compromises. En revanche, contrairement à ce qui a été indiqué sur les réseaux sociaux, il ne s’agit ni du fichier de tou·tes les utilisateur·rices d’Action populaire, ni des signataires sur le site de soutien de la campagne présidentielle. »
Le coordinateur du parti confirme par ailleurs qu’une plainte va être déposée, outre l’alerte transmise à la CNIL et à l’ANSSI. « De manière générale, dans le contexte de généralisation de piratages de données ayant par exemple visé des institutions publiques, nous invitons tou·tes les camarades à faire preuve de la plus grande vigilance dans les messages qu’elles et ils pourraient recevoir sur leurs coordonnées personnelles », écrit encore le parti, avant d’appeler aux habituels conseils de vigilance.
La divulgation de cette attaque intervient alors que le leader du parti, Jean-Luc Mélenchon, a annoncé dimanche 3 mai, au 20 heures de TF1, sa candidature à l’élection présidentielle de 2027. Le dépôt GitHub dédié au code d’actionpopulaire.fr témoigne quant à lui d’une forte accélération du volume de commits depuis le 23 avril dernier.
Rappelons que d’un point de vue réglementaire, les informations qui révèlent l’orientation politique relèvent de ce que le RGPD qualifie, dans son article 9, de « données sensibles ».
Ce 7 mai, une nouvelle faille dans le noyau Linux permettant d’obtenir les droits superutilisateur a été divulguée. Mais l’embargo sur sa découverte a été cassé par des tiers. Même si un moyen de l’endiguer a été disponible rapidement, les responsables de distributions Linux courent depuis pour proposer à leurs utilisateurs un noyau incluant un patch.
Ce week-end du 8 mai a été bien actif pour les administrateurs systèmes : un peu plus d’une semaine après la révélation de la faille Copy fail dans le noyau Linux, une autre vulnérabilité a été rendue publique le 7 mai dernier. Elle est maintenant décrite sous le nom de Dirty Frag.
Comme pour Copy fail, en l’exploitant, la faille permet une escalade des privilèges, c’est-à-dire qu’un utilisateur lambda d’une machine peut très facilement accéder aux droits d’accès superutilisateur et faire ce que bon lui semble. Encore faut-il avoir un compte sur la machine.
Cette faille a été détectée par le chercheur indépendant Hyunwoo Kim. Mais celui-ci n’avait pas prévu de diffuser l’information si tôt. Comme il l’a expliqué vendredi sur la liste de discussion oss-security, d’autres personnes ont outrepassé l’embargo fixé sur la divulgation de cette faille qui concerne la plupart des distributions Linux.
Ainsi, vendredi, au moment où il a posté le message, aucun patch n’existait et aucun numéro de vulnérabilité ne lui avait été affecté. Le seul moyen qu’il proposait pour endiguer son exploitation était de bloquer les modules dans lesquels le problème se trouvait via la commande :
Connexionsh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"Depuis, la communauté s’est affairée à mettre tout en place pour bloquer la faille. Ainsi, Hyunwoo Kim a créé un dépôt GitHub officiel sur le sujet pour décrire et c’est en fait deux CVE qui ont été créées : CVE-2026-43284 puis CVE-2026-43500. Le score de vulnérabilité de la seconde n’est pas encore fixé mais celui de CVE-2026-43284 est de 8,8. Comme pour Copy Fail, le vecteur d’attaque est local (AV:L) : il faut déjà avoir un accès local sur la machine et le score aurait été sans doute plus élevé si ça n’avait pas été le cas.
Les deux vulnérabilités se situaient aussi, comme avec Copy Fail, dans la possibilité de modifier le page cache (celui de xfrm-ESP depuis 2017 pour la CVE-2026-43284 et celui de RxRPC depuis 2023 pour la CVE-2026-43500). Corrigées respectivement depuis le 5 et 10 mai dans les deux projets, Hyunwoo Kim souligne qu’ « en d’autres termes, la durée de vie effective de ces vulnérabilités est d’environ 9 ans ».
La similarité avec Copy fail n’est pas étonnante puisque Hyunwoo Kim explique que c’est la première faille qui a inspiré sa recherche d’autres du même type
Le chercheur donne aussi un PoC. À Next, nous avons testé sur un serveur dédié virtuel chez OVHCloud sur lequel est installé Ubuntu 25.04. Nous avons pu reproduire le comportement, ainsi n’importe quelle personne qui a un compte sur la machine peut devenir root et y faire ce qu’elle veut.
Dans sa documentation, avant de pouvoir déployer le correctif de votre distribution, Hyunwoo Kim propose la même façon d’endiguer le problème que dans son message sur la liste oss-security.
Comme l’explique Ubuntu sur son blog, celle-ci peut poser des problèmes si on utilise le protocole de VPN IPSec comme le logiciel strongSwan. C’est aussi le cas si on se sert du système d’archivage distribué AFS (Andrew File System) « ou d’une autre application utilisant RxRPC ».
Petit à petit, les responsables des distributions Linux déploient un correctif. C’est le cas pour certaines versions de Debian, par exemple. Mais, à cause du non respect de l’embargo, le déploiement n’était pas prêt lorsque la faille a été rendue publique. Sur un dépôt GitHub titré « Copy Fail 2: Electric Boogaloo », d’autres personnes ont publié des informations sur la faille en marge du travail de Hyunwoo Kim tout en le créditant.
Celui-ci explique avoir contacté l’équipe de sécurité du noyau Linux le 30 avril avec un exploit montrant les possibilités d’utilisation de la faille et que le chercheur Kuan-Ting Chen a travaillé en parallèle sur le problème. Celui-ci a proposé un patch le 4 mai sur la liste netdev et il a été intégré à la branche netdev le 7 mai. Hyunwoo Kim a ensuite informé les responsables des distributions Linux sur la linux-distros et un embargo de cinq jours a été fixé. Mais celui-ci a donc été cassé par un tiers, ce qui a précipité la mise en place d’une solution. Comme avec Copy Fail, les administrateurs systèmes se sont donc retrouvés avec des informations partielles sur le problème au moment de la divulgation.
Ce 7 mai, une nouvelle faille dans le noyau Linux permettant d’obtenir les droits superutilisateur a été divulguée. Mais l’embargo sur sa découverte a été cassé par des tiers. Même si un moyen de l’endiguer a été disponible rapidement, les responsables de distributions Linux courent depuis pour proposer à leurs utilisateurs un noyau incluant un patch.
Ce week-end du 8 mai a été bien actif pour les administrateurs systèmes : un peu plus d’une semaine après la révélation de la faille Copy fail dans le noyau Linux, une autre vulnérabilité a été rendue publique le 7 mai dernier. Elle est maintenant décrite sous le nom de Dirty Frag.
Comme pour Copy fail, en l’exploitant, la faille permet une escalade des privilèges, c’est-à-dire qu’un utilisateur lambda d’une machine peut très facilement accéder aux droits d’accès superutilisateur et faire ce que bon lui semble. Encore faut-il avoir un compte sur la machine.
Cette faille a été détectée par le chercheur indépendant Hyunwoo Kim. Mais celui-ci n’avait pas prévu de diffuser l’information si tôt. Comme il l’a expliqué vendredi sur la liste de discussion oss-security, d’autres personnes ont outrepassé l’embargo fixé sur la divulgation de cette faille qui concerne la plupart des distributions Linux.
Ainsi, vendredi, au moment où il a posté le message, aucun patch n’existait et aucun numéro de vulnérabilité ne lui avait été affecté. Le seul moyen qu’il proposait pour endiguer son exploitation était de bloquer les modules dans lesquels le problème se trouvait via la commande :
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"Depuis, la communauté s’est affairée à mettre tout en place pour bloquer la faille. Ainsi, Hyunwoo Kim a créé un dépôt GitHub officiel sur le sujet pour décrire et c’est en fait deux CVE qui ont été créées : CVE-2026-43284 puis CVE-2026-43500. Le score de vulnérabilité de la seconde n’est pas encore fixé mais celui de CVE-2026-43284 est de 8,8. Comme pour Copy Fail, le vecteur d’attaque est local (AV:L) : il faut déjà avoir un accès local sur la machine et le score aurait été sans doute plus élevé si ça n’avait pas été le cas.
Les deux vulnérabilités se situaient aussi, comme avec Copy Fail, dans la possibilité de modifier le page cache (celui de xfrm-ESP depuis 2017 pour la CVE-2026-43284 et celui de RxRPC depuis 2023 pour la CVE-2026-43500). Corrigées respectivement depuis le 5 et 10 mai dans les deux projets, Hyunwoo Kim souligne qu’ « en d’autres termes, la durée de vie effective de ces vulnérabilités est d’environ 9 ans ».
La similarité avec Copy fail n’est pas étonnante puisque Hyunwoo Kim explique que c’est la première faille qui a inspiré sa recherche d’autres du même type
Le chercheur donne aussi un PoC. À Next, nous avons testé sur un serveur dédié virtuel chez OVHCloud sur lequel est installé Ubuntu 25.04. Nous avons pu reproduire le comportement, ainsi n’importe quelle personne qui a un compte sur la machine peut devenir root et y faire ce qu’elle veut.
Dans sa documentation, avant de pouvoir déployer le correctif de votre distribution, Hyunwoo Kim propose la même façon d’endiguer le problème que dans son message sur la liste oss-security.
Comme l’explique Ubuntu sur son blog, celle-ci peut poser des problèmes si on utilise le protocole de VPN IPSec comme le logiciel strongSwan. C’est aussi le cas si on se sert du système d’archivage distribué AFS (Andrew File System) « ou d’une autre application utilisant RxRPC ».
Petit à petit, les responsables des distributions Linux déploient un correctif. C’est le cas pour certaines versions de Debian, par exemple. Mais, à cause du non respect de l’embargo, le déploiement n’était pas prêt lorsque la faille a été rendue publique. Sur un dépôt GitHub titré « Copy Fail 2: Electric Boogaloo », d’autres personnes ont publié des informations sur la faille en marge du travail de Hyunwoo Kim tout en le créditant.
Celui-ci explique avoir contacté l’équipe de sécurité du noyau Linux le 30 avril avec un exploit montrant les possibilités d’utilisation de la faille et que le chercheur Kuan-Ting Chen a travaillé en parallèle sur le problème. Celui-ci a proposé un patch le 4 mai sur la liste netdev et il a été intégré à la branche netdev le 7 mai. Hyunwoo Kim a ensuite informé les responsables des distributions Linux sur la linux-distros et un embargo de cinq jours a été fixé. Mais celui-ci a donc été cassé par un tiers, ce qui a précipité la mise en place d’une solution. Comme avec Copy Fail, les administrateurs systèmes se sont donc retrouvés avec des informations partielles sur le problème au moment de la divulgation.
Firefox sert désormais de laboratoire grandeur nature pour éprouver de nouveaux outils de cybersécurité assistés par IA. En avril, Mozilla a corrigé la bagatelle de 423 vulnérabilités, la majorité ayant été débusquée par Mythos.
Mozilla ne tarit décidément pas d’éloges sur les capacités de Mythos à détecter des bugs et des failles de sécurité dans Firefox. En avril, des correctifs ont permis de corriger 423 vulnérabilités : les 271 bugs dans Firefox 150 déjà annoncés qui proviennent des analyses de Mythos, plus 41 bugs signalés par des chercheurs externes, et 111 découverts en interne avec d’autres méthodes. À comparer avec les 76 correctifs du mois de mars.
Une chose a changé dans l’utilisation des LLM par les développeurs de Firefox. Les tests réalisés ces dernières années avec GPT-4 ou Sonnet 3.5 s’avéraient certes prometteurs, mais au bout du compte « le taux élevé de faux positifs les rendait impraticables à grande échelle », écrivent Brian Grinstead, Christian Holler et Frederik Braun de Mozilla. Le mode opératoire était relativement classique : demander au modèle d’analyser du code jugé sensible pour repérer d’éventuelles vulnérabilités.
Les modèles agentiques ont changé la donne, soulignent-ils : « Ces systèmes peuvent trouver de véritables bugs et écarter les hypothèses impossibles à reproduire ». Claude Opus 4.6 a permis de mettre au point un « harnais agentique » qui interagit avec l’environnement de développement : il peut exécuter du code, vérifier si la faille existe réellement et générer des cas de test qu’il est possible de reproduire.
En substance, le LLM formule une hypothèse et tente lui-même de la valider. De quoi identifier « une quantité impressionnante de vulnérabilités jusque-là inconnues ». Les ingénieurs de Mozilla ont affiné et ajusté le comportement du modèle, et lorsque les résultats ont été jugés suffisamment bons, ils ont parallélisé les tâches sur plusieurs machines virtuelles éphémères.
Le LLM n’est qu’une partie de ce Meccano de sécurité. L’infrastructure au complet inclut aussi la gestion du cycle de vie des vulnérabilités : orchestration, validation, triage, intégration avec d’autres outils internes. Ce « harnais », qui reste très spécifique au projet, peut ensuite fonctionner avec d’autres LLM, comme l’aperçu de Mythos. « Le système devient simultanément meilleur pour repérer des bugs potentiels, créer des cas de test de preuve de concept pour les démontrer, et expliquer précisément leur mécanisme ainsi que leur impact », indique Mozilla.
Ce travail de fond pour créer un pipeline autour des modèles de langage et les capacités accrues de ces derniers ont permis d’accélérer la détection et le développement de correctifs. « Il y a encore quelques mois, les rapports de bugs de sécurité générés par IA envoyés aux projets open source étaient surtout connus pour être du bruit inutile », rappellent les ingénieurs. Trier le bon grain de l’ivraie était chronophage : « il est simple et peu coûteux de demander à un LLM de trouver un « problème » dans du code, mais il est long et coûteux de vérifier puis de répondre à ces signalements. »
Tout a changé avec les nouveaux LLM plus puissants, et l’amélioration des techniques permettant d’exploiter ces modèles. C’est un cas d’usage spécifique pour Firefox qui peut ne pas s’adapter à d’autres organisations.
Brian Grinstead apporte un éclairage intéressant chez TechCrunch. Si l’équipe de Firefox utilise les LLM pour repérer des failles, les correctifs sont toujours écrits par des humains malgré les progrès des outils de développement assistés par IA. « Pour les bugs dont nous parlons dans ce billet, chaque correctif a été écrit par un ingénieur puis relu par un autre », explique-t-il.
Les développeurs demandent tout de même à l’IA de proposer des correctifs pour chaque bug, mais le code qu’elle produit ne peut pas être déployé tel quel. Il sert surtout de base de travail, car « nous n’avons pas constaté que cela pouvait être automatisé ».
Mozilla est suffisamment confiant pour partager 12 bugs corrigés sans attendre les plusieurs mois habituels avant une divulgation publique, « compte tenu du niveau d’intérêt extraordinaire suscité par ce sujet et de l’urgence des mesures à prendre dans l’ensemble de l’écosystème logiciel ». Ces bugs, qui permettent des échappements de sandbox, doivent être combinés à d’autres exploits pour compromettre Firefox.
« Nous n’avons pas encore découvert tous les bugs latents présents dans Firefox, mais nous sommes très satisfaits de la trajectoire actuelle », conclut le billet. La prochaine étape pour Mozilla est d’intégrer le système directement dans la chaîne de développement du navigateur : chaque nouveau correctif envoyé par un développeur pourrait être automatiquement analysé par le pipeline IA, ce qui permettrait de détecter les bugs quasiment au moment où ils sont intégrés dans le code de Firefox.
Sur le sujet de l’impact de l’IA sur le monde de la cybersécurité, illustré notamment par le phénomène médiatique Mythos, voir notre récent dossier :
Firefox sert désormais de laboratoire grandeur nature pour éprouver de nouveaux outils de cybersécurité assistés par IA. En avril, Mozilla a corrigé la bagatelle de 423 vulnérabilités, la majorité ayant été débusquée par Mythos.
Mozilla ne tarit décidément pas d’éloges sur les capacités de Mythos à détecter des bugs et des failles de sécurité dans Firefox. En avril, des correctifs ont permis de corriger 423 vulnérabilités : les 271 bugs dans Firefox 150 déjà annoncés qui proviennent des analyses de Mythos, plus 41 bugs signalés par des chercheurs externes, et 111 découverts en interne avec d’autres méthodes. À comparer avec les 76 correctifs du mois de mars.
Une chose a changé dans l’utilisation des LLM par les développeurs de Firefox. Les tests réalisés ces dernières années avec GPT-4 ou Sonnet 3.5 s’avéraient certes prometteurs, mais au bout du compte « le taux élevé de faux positifs les rendait impraticables à grande échelle », écrivent Brian Grinstead, Christian Holler et Frederik Braun de Mozilla. Le mode opératoire était relativement classique : demander au modèle d’analyser du code jugé sensible pour repérer d’éventuelles vulnérabilités.
Les modèles agentiques ont changé la donne, soulignent-ils : « Ces systèmes peuvent trouver de véritables bugs et écarter les hypothèses impossibles à reproduire ». Claude Opus 4.6 a permis de mettre au point un « harnais agentique » qui interagit avec l’environnement de développement : il peut exécuter du code, vérifier si la faille existe réellement et générer des cas de test qu’il est possible de reproduire.
En substance, le LLM formule une hypothèse et tente lui-même de la valider. De quoi identifier « une quantité impressionnante de vulnérabilités jusque-là inconnues ». Les ingénieurs de Mozilla ont affiné et ajusté le comportement du modèle, et lorsque les résultats ont été jugés suffisamment bons, ils ont parallélisé les tâches sur plusieurs machines virtuelles éphémères.
Le LLM n’est qu’une partie de ce Meccano de sécurité. L’infrastructure au complet inclut aussi la gestion du cycle de vie des vulnérabilités : orchestration, validation, triage, intégration avec d’autres outils internes. Ce « harnais », qui reste très spécifique au projet, peut ensuite fonctionner avec d’autres LLM, comme l’aperçu de Mythos. « Le système devient simultanément meilleur pour repérer des bugs potentiels, créer des cas de test de preuve de concept pour les démontrer, et expliquer précisément leur mécanisme ainsi que leur impact », indique Mozilla.
Ce travail de fond pour créer un pipeline autour des modèles de langage et les capacités accrues de ces derniers ont permis d’accélérer la détection et le développement de correctifs. « Il y a encore quelques mois, les rapports de bugs de sécurité générés par IA envoyés aux projets open source étaient surtout connus pour être du bruit inutile », rappellent les ingénieurs. Trier le bon grain de l’ivraie était chronophage : « il est simple et peu coûteux de demander à un LLM de trouver un « problème » dans du code, mais il est long et coûteux de vérifier puis de répondre à ces signalements. »
Tout a changé avec les nouveaux LLM plus puissants, et l’amélioration des techniques permettant d’exploiter ces modèles. C’est un cas d’usage spécifique pour Firefox qui peut ne pas s’adapter à d’autres organisations.
Brian Grinstead apporte un éclairage intéressant chez TechCrunch. Si l’équipe de Firefox utilise les LLM pour repérer des failles, les correctifs sont toujours écrits par des humains malgré les progrès des outils de développement assistés par IA. « Pour les bugs dont nous parlons dans ce billet, chaque correctif a été écrit par un ingénieur puis relu par un autre », explique-t-il.
Les développeurs demandent tout de même à l’IA de proposer des correctifs pour chaque bug, mais le code qu’elle produit ne peut pas être déployé tel quel. Il sert surtout de base de travail, car « nous n’avons pas constaté que cela pouvait être automatisé ».
Mozilla est suffisamment confiant pour partager 12 bugs corrigés sans attendre les plusieurs mois habituels avant une divulgation publique, « compte tenu du niveau d’intérêt extraordinaire suscité par ce sujet et de l’urgence des mesures à prendre dans l’ensemble de l’écosystème logiciel ». Ces bugs, qui permettent des échappements de sandbox, doivent être combinés à d’autres exploits pour compromettre Firefox.
« Nous n’avons pas encore découvert tous les bugs latents présents dans Firefox, mais nous sommes très satisfaits de la trajectoire actuelle », conclut le billet. La prochaine étape pour Mozilla est d’intégrer le système directement dans la chaîne de développement du navigateur : chaque nouveau correctif envoyé par un développeur pourrait être automatiquement analysé par le pipeline IA, ce qui permettrait de détecter les bugs quasiment au moment où ils sont intégrés dans le code de Firefox.
Sur le sujet de l’impact de l’IA sur le monde de la cybersécurité, illustré notamment par le phénomène médiatique Mythos, voir notre récent dossier :
Victime d’un piratage, le site officiel de JDownloader a pendant 48 heures distribué un malware en lieu et place du fichier d’installation proposé pour Windows et Linux. L’équipe en charge du projet affirme que seuls les liens de téléchargement ont été modifiés : les binaires du logiciel et l’infrastructure sous-jacente n’auraient pas été touchés. Les internautes ayant téléchargé l’utilitaire entre le 6 et le 7 mai sont toutefois invités à la prudence.
Très populaire chez les adeptes du « direct download », du fait de sa capacité à lever les restrictions sur les téléchargements gratuits, l’utilitaire JDownloader a été victime d’un incident de sécurité les 6 et 7 mai dernier. C’est plus précisément le site officiel du logiciel qui a été affecté par une attaque de type supply chain (chaîne d’approvisionnement) : pendant 48 heures environ, certains des liens de téléchargement affichés sur le site ont pointé vers un malware et non vers les binaires légitimes du client.
L’équipe en charge du projet indique que deux liens ont été affectés : l’option « Download Alternative Installer » proposée pour Windows, et l’URL pointant vers l’installateur en ligne de commande pour Linux. « Nos packages d’installation originaux n’ont pas été modifiés ; seuls les liens de téléchargement publiés ici pointent vers des fichiers erronés. Les fichiers binaires de l’installateur restent hébergés sur des serveurs externes, comme d’habitude », promet JDownloader dans un billet dédié.
L’incident y est retracé de façon chronologique. D’après l’équipe, les assaillants auraient d’abord procédé à une première modification sur une page peu exposée du site, le 5 mai dans la soirée, avant d’insérer les deux liens piégés sur la page principale dédiée au téléchargement, le 6 mai aux alentours de deux heures du matin (heure de Paris).
Les auteurs du projet ont sonné le branle-bas de combat le 7 mai vers 19 heures, suite à l’alerte lancée par un internaute sur Reddit. « Des téléchargements suspects et des alertes ont été détectés ; le problème a été confirmé et une procédure de gestion d’incident a été lancée. Le serveur a été arrêté à 17h24 UTC [19h24 heure de Paris] », décrit-elle. Le site est ensuite resté hors ligne à des fins de nettoyage et de contrôle, jusqu’à sa remise en route dans la nuit du 8 au 9 mai.
C’est au niveau du CMS (gestionnaire de contenus, le « moteur » du site Web) que serait intervenue l’intrusion. Le code de JDownloader, et les mécaniques de mise à jour « in-app » n’ont de ce fait pas été affectées, assure l’équipe : « Chaque mise à jour installée via le système intégré de l’application est signée par RSA et vérifiée par cryptographie. Ce canal est indépendant des liens de téléchargement du site web qui ont été manipulés. »
Reste à accompagner les internautes exposés à un fichier compromis. Sous Windows, l’équipe invite à contrôler la signature du client téléchargé (clic droit, propriétés, signatures numériques). Si l’écran affiche AppWork GmbH, le fichier peut être considéré comme légitime. Elle propose également un tableau récapitulatif des différentes versions du client, avec leur taille exacte et le checksum associé.
En cas de fichier téléchargé, puis exécuté, JDownloader invite à la réinstallation complète du système d’exploitation, et à la modification préventive de tous les identifiants susceptibles d’avoir été stockés sur la machine.
D’après Thomas Klemenc de Malcat, le fichier distribué par les pirates contient bien l’installeur de JDownloader, associé à une charge malveillante de type RAT (Remote Access Trojan) écrite en Python. Bleeping Computer remarque un comportement similaire sous Linux, où la charge s’installe de façon persistante et dissimule son activité grâce à l’outil d’obfuscation Pyarmor.
Ce nouvel incident illustre la tendance qui consiste à attaquer non pas un logiciel, mais sa chaîne d’approvisionnement. Parfois, c’est le site Web qui sert de vecteur, comme ici ou dans le cas de la mésaventure survenue à l’éditeur de CPU-Z. Bon nombre d’attaques se concentrent également sur la distribution de composants open source populaires, comme l’illustre une alerte lancée le 5 mai dernier sur Daemon Tools, ainsi que les épisodes récents relatifs à Axios ou Trivy.
