En marge de la publication de Linux 7.1-rc4, Linus Torvalds, créateur du noyau Linux, s'est penché sur un sujet qui cristallise les craintes de la communauté open source face à l'essor de l'IA : l'inondation de signalements de bugs.
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.
