Explorer des réseaux, se propager d’un appareil à l’autre et neutraliser des cibles : l’armée américaine veut confier des missions offensives à des agents IA. Une enquête de The Intercept, publiée le 19 octobre 2026, détaille ce projet encore en développement, baptisé ECHOTRIBBLE, et les inquiétudes qu’il suscite sur le contrôle humain.
Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.
Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.
La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.
Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.
Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.
Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.
C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.
La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.
Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.
Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.
En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.
Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.
Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.
Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.
Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.
Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).
L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).
Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.
Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.
Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.
La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.
Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.
Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.
Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.
C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.
La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.
Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.
Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.
En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.
Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.
Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.
Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.
Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.
Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).
L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).
Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.
Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.
Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.
Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.
« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.
La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.
Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :
« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »
L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.
Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).
La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.
Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.
Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.
Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.
Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.
« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.
La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.
Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :
« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »
L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.
Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).
La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.
Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.
La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.
Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.
À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.
La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.
Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.
Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.
Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.
La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.
La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.
Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.
À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.
La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.
Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.
Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.
Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.
La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.
Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.
La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.
Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.
L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.
Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.
À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.
À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.
Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.
La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.
Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.
L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.
Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.
À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.
À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.
Trois actualités à retenir cette semaine dans le cyberespace, un piratage qui a fait grimper la température dans les rayons frais de centaines de supermarchés français, Andrej Karpathy qui décrit le fossé grandissant entre l’IA que connaît le grand public et celle que voient les laboratoires, et un effondrement du trafic de bots russes qui mérite d’être nuancé.
Une simple lettre venue de l’alphabet cyrillique suffit à créer une fausse adresse web presque impossible à distinguer de la vraie à l’œil nu. Un piège connu des spécialistes, qui reste redoutablement efficace.
Le site du parti Les Républicains fait l’objet d’une attaque vendredi matin, avec une intrusion qui semble réussie puisque la page d’accueil a été remplacée par un long manifeste appelant à rejoindre les mobilisations du 17 octobre. Les auteurs de l’attaque affirment avoir mis la main sur des données internes.
Après le Rassemblement national en juillet, c’est au tour du parti Les Républicains de faire l’objet d’une cyberattaque. Vendredi 16 octobre matin, son site, republicains.fr, a été « défacé », c’est-à-dire modifié pour afficher un message de revendication, comme nous l’avons directement constaté.
« Nous avons rassemblé nos talents de lutte et avons offert un lifting au site officiel du parti « Les Républicains » ! Ceci est un APPEL à rejoindre les mobilisations du 17 octobre pour révolutionner la France et le monde. Faisons monter le rapport de force ! », affichait l’introduction de la page d’accueil piratée, accompagnée du thème musical « Drums of revolution » de One Piece.
L’attaque n’a pas été signée, mais outre des termes orduriers adressés aux Républicains, la page mise en ligne s’accompagne d’une liste de ressources « nécessaires à mener de front la révolution harmonieuse dont Paname et le monde qu’elle influence ont grand besoin », le tout présenté comme une démarche visant à concourir à « un monde antifasciste, anticapitaliste, queerféministe, antiraciste, antivalidiste et écoconscient ».
L’attaque semble avoir été lancée aux alentours de 11 heures, et la page d’accueil modifiée (voir sauvegarde, avec les images) est restée en ligne jusqu’aux alentours de 11h45, moment à partir duquel le parti (ou son prestataire) a temporairement réussi à restaurer la page d’accueil légitime. Une bataille technique semble toutefois toujours se jouer en coulisses : vers 12h30, heure de publication de cet article, l’accueil du site republicains.fr affichait par intermittence une page renvoyant vers la sauvegarde de la revendication.
Dans leur communication, les attaquants affirment avoir profité de leur accès pour mettre la main sur des informations internes, émanant potentiellement de la base de données du site (hébergé sous WordPress) :
« Nous avons volé toutes les données de votre site et de vos membres ainsi que tous vos échanges internes et messages privés. Si vous ne répondez pas sérieusement aux revendications des personnes mobilisées dans la rue, ou que vous supprimez notre appel de votre site avant le 20 octobre, nous enverrons une copie de vos données à tous les journalistes et médias d’investigation qui se feront un plaisir de vous démarrer – notamment durant toute cette période électorale. »
Cette attaque, au sujet de laquelle le parti Les Républicains ne s’est pas encore exprimé, intervient dans le contexte doublement explosif du mouvement lycéen et des mobilisations sociales prévues ce samedi 17 octobre, mais aussi de la campagne désormais bien lancée en vue de l’élection présidentielle de 2027. Le 9 octobre dernier, le site dédié au vote de la primaire socialiste démocratique avait déjà fait l’objet d’une tentative d’attaque par déni de service.
Le site du parti Les Républicains fait l’objet d’une attaque vendredi matin, avec une intrusion qui semble réussie puisque la page d’accueil a été remplacée par un long manifeste appelant à rejoindre les mobilisations du 17 octobre. Les auteurs de l’attaque affirment avoir mis la main sur des données internes.
Après le Rassemblement national en juillet, c’est au tour du parti Les Républicains de faire l’objet d’une cyberattaque. Vendredi 16 octobre matin, son site, republicains.fr, a été « défacé », c’est-à-dire modifié pour afficher un message de revendication, comme nous l’avons directement constaté.
« Nous avons rassemblé nos talents de lutte et avons offert un lifting au site officiel du parti « Les Républicains » ! Ceci est un APPEL à rejoindre les mobilisations du 17 octobre pour révolutionner la France et le monde. Faisons monter le rapport de force ! », affichait l’introduction de la page d’accueil piratée, accompagnée du thème musical « Drums of revolution » de One Piece.
L’attaque n’a pas été signée, mais outre des termes orduriers adressés aux Républicains, la page mise en ligne s’accompagne d’une liste de ressources « nécessaires à mener de front la révolution harmonieuse dont Paname et le monde qu’elle influence ont grand besoin », le tout présenté comme une démarche visant à concourir à « un monde antifasciste, anticapitaliste, queerféministe, antiraciste, antivalidiste et écoconscient ».
L’attaque semble avoir été lancée aux alentours de 11 heures, et la page d’accueil modifiée (voir sauvegarde, avec les images) est restée en ligne jusqu’aux alentours de 11h45, moment à partir duquel le parti (ou son prestataire) a temporairement réussi à restaurer la page d’accueil légitime. Une bataille technique semble toutefois toujours se jouer en coulisses : vers 12h30, heure de publication de cet article, l’accueil du site republicains.fr affichait par intermittence une page renvoyant vers la sauvegarde de la revendication.
Dans leur communication, les attaquants affirment avoir profité de leur accès pour mettre la main sur des informations internes, émanant potentiellement de la base de données du site (hébergé sous WordPress) :
« Nous avons volé toutes les données de votre site et de vos membres ainsi que tous vos échanges internes et messages privés. Si vous ne répondez pas sérieusement aux revendications des personnes mobilisées dans la rue, ou que vous supprimez notre appel de votre site avant le 20 octobre, nous enverrons une copie de vos données à tous les journalistes et médias d’investigation qui se feront un plaisir de vous démarrer – notamment durant toute cette période électorale. »
Cette attaque, au sujet de laquelle le parti Les Républicains ne s’est pas encore exprimé, intervient dans le contexte doublement explosif du mouvement lycéen et des mobilisations sociales prévues ce samedi 17 octobre, mais aussi de la campagne désormais bien lancée en vue de l’élection présidentielle de 2027. Le 9 octobre dernier, le site dédié au vote de la primaire socialiste démocratique avait déjà fait l’objet d’une tentative d’attaque par déni de service.
Une attaque zéro-clic installant un logiciel espion via des publicités ciblées a infecté des appareils du média Al Jazeera avec un logiciel espion. Cette attaque zéro clic a été distribuée par l’entreprise de marketing israélienne Discover-Tech.
Les chercheurs du Citizen Lab de l’université de Toronto et l’entreprise de cybersécurité Confiant ont annoncé ce jeudi 15 octobre la découverte d’un nouveau type d’attaques zéro-clic. L’entreprise israélienne Discover-Tech a utilisé des publicités ciblées pour infecter des appareils appartenant à des journalistes et des équipes du média Al Jazeera avec un logiciel espion attribué à la société Candiru, elle aussi israélienne et concurrente de NSO.
Selon les découvreurs, c’est la « première confirmation technique publique d’une attaque par logiciel espion de type « zéro-clic » perpétrée par des mercenaires via la publicité ciblée ». Créant un mot-valise à partir d’« advertising » et d’« infection », ils ont appelé ce genre d’attaque « adfection », ce qu’on pourrait traduire par « pubfection ».
Discover-Tech profite de tout l’écosystème mis en place pour afficher de la publicité sur le web et les applications, utilisé aussi bien par les publicitaires que par les éditeurs. Cet écosystème s’appuie notamment sur des outils de gestion d’enchères en temps réel mis en place par des géants du numérique comme Google ou Yandex, par exemple.
Discover-Tech a réussi à intégrer la liste des vendeurs de publicités « certifiés » et « approuvés » par Google, mais aussi celle de l’IAB Europe (Association européenne dédiée à l’écosystème du marketing et de la publicité numériques). Elle a ainsi pu distribuer des publicités via la plateforme du géant américain mais aussi être intégrée à des bandeaux de consentement RGPD et ainsi récupérer des données si l’internaute cliquait sur « accepter ». Elle avait aussi accès aux outils d’autres entreprises de l’écosystème de publicité en ligne comme Yandex, Vungle, Beeswax (filiale de Comcast) ou encore Eskimi.
Informés par les chercheurs, Google, l’IAB Europe, Beeswax, Vungle et Eskimi ont débranché les accès à leurs outils. Mais les autres entreprises de cet écosystème contactées ne leur ont pas répondu.
Cet écosystème ne permet pas seulement de créer des profils très ciblés des utilisateurs d’Internet mais aussi d’accompagner les publicités d’un code JavaScript. Si l’utilisateur qui reçoit la publicité est reconnu comme quelqu’un à attaquer, la publicité est donc accompagnée d’un code malveillant qui permet de passer la main à Candiru pour mettre en place son logiciel espion.
Selon le Citizen Lab qui a pu analyser l’attaque en examinant les appareils infectés d’Al Jazeera, ces derniers « établissent d’abord un contact avec des domaines de l’infrastructure Discover-Tech, ce qui indique l’affichage d’une publicité. Ensuite, les appareils établissent des connexions avec un serveur de validation Candiru. Ce serveur de validation effectue une vérification initiale de l’appareil avant que celui-ci ne fasse l’objet d’un profilage plus approfondi et ne soit infecté. Enfin, un appareil infecté communique avec un serveur de commande et de contrôle (C&C) Candiru ».
Au total, entre 2024 et 2025, 45 appareils du média qatari ont été touchés par cette attaque, expliquent les chercheurs. Selon le décompte de Citizen Lab, entre mars et juin 2026 , Discover-Tech a pu distribuer des publicités contenant des balises de script malveillantes auprès des utilisateurs de 75 373 applications Android et iOS différentes, ainsi qu’aux visiteurs de 120 768 sites web différents (via navigateurs desktop ou mobile).
Pour Android, les chercheurs citent, entre autres, les applications MX Player, Yahoo Mail, Opera Mini, Duolingo ou encore Badoo ou Grindr, certaines ayant affiché plus d’1 million de publicités de Discover-Tech. Si l’écosystème iOS semble touché de la même façon concernant le nombre d’applications concernées, Citizen Lab explique que les apps tournant sur iPhone semblent avoir affiché moins de publicité de Discover-Tech (par exemple la version Android de Viber en a diffusé 700 000 alors que la version iOS n’en a diffusé « que » 200 000).
Mais ce ne sont pas seulement les cibles qui sont concernées par le problème. Comme l’explique le Citizen Lab, Discover-Tech profite de ses publicités pour faire comme tous les brokers de pubs : exploiter les utilisateurs.
Pendant cette même période, les outils de Discover-Tech ont « enchéri sur 3 770 286 576 impressions [de publicité] et semblent avoir remporté 441 954 291 d’entre elles (11,7 %) ».
Si les chercheurs n’ont pas observé de tentative d’attaques contre ces appareils, ils expliquent que leurs données indiquent que les pubs de Discover-Tech ont été diffusées sur des appareils connectés à des réseaux sensibles comme celui de l’OTAN, de divers ministères de la Défense, d’armées, d’agences de cybersécurité et de médias.
« Une impression publicitaire de Discover-Tech ne confirme pas en soi un ciblage ou une infection par un logiciel espion », explique Citizen Lab. « Toutefois, le fait que Discover-Tech ait pu enchérir et diffuser des publicités sur ces réseaux met en évidence le risque systémique que représentent la pubfection et l’écosystème publicitaire, et justifie une enquête urgente visant à déterminer si des utilisateurs de ces réseaux ont été infectés par un logiciel espion », ajoutent les chercheurs.
Sur les réseaux sociaux, le chercheur du Citizen Lab, John Scott-Railton, donne un conseil : « pour vous protéger, bloquez les publicités dès maintenant ».
Une attaque zéro-clic installant un logiciel espion via des publicités ciblées a infecté des appareils du média Al Jazeera avec un logiciel espion. Cette attaque zéro clic a été distribuée par l’entreprise de marketing israélienne Discover-Tech.
Les chercheurs du Citizen Lab de l’université de Toronto et l’entreprise de cybersécurité Confiant ont annoncé ce jeudi 15 octobre la découverte d’un nouveau type d’attaques zéro-clic. L’entreprise israélienne Discover-Tech a utilisé des publicités ciblées pour infecter des appareils appartenant à des journalistes et des équipes du média Al Jazeera avec un logiciel espion attribué à la société Candiru, elle aussi israélienne et concurrente de NSO.
Selon les découvreurs, c’est la « première confirmation technique publique d’une attaque par logiciel espion de type « zéro-clic » perpétrée par des mercenaires via la publicité ciblée ». Créant un mot-valise à partir d’« advertising » et d’« infection », ils ont appelé ce genre d’attaque « adfection », ce qu’on pourrait traduire par « pubfection ».
Discover-Tech profite de tout l’écosystème mis en place pour afficher de la publicité sur le web et les applications, utilisé aussi bien par les publicitaires que par les éditeurs. Cet écosystème s’appuie notamment sur des outils de gestion d’enchères en temps réel mis en place par des géants du numérique comme Google ou Yandex, par exemple.
Discover-Tech a réussi à intégrer la liste des vendeurs de publicités « certifiés » et « approuvés » par Google, mais aussi celle de l’IAB Europe (Association européenne dédiée à l’écosystème du marketing et de la publicité numériques). Elle a ainsi pu distribuer des publicités via la plateforme du géant américain mais aussi être intégrée à des bandeaux de consentement RGPD et ainsi récupérer des données si l’internaute cliquait sur « accepter ». Elle avait aussi accès aux outils d’autres entreprises de l’écosystème de publicité en ligne comme Yandex, Vungle, Beeswax (filiale de Comcast) ou encore Eskimi.
Informés par les chercheurs, Google, l’IAB Europe, Beeswax, Vungle et Eskimi ont débranché les accès à leurs outils. Mais les autres entreprises de cet écosystème contactées ne leur ont pas répondu.
Cet écosystème ne permet pas seulement de créer des profils très ciblés des utilisateurs d’Internet mais aussi d’accompagner les publicités d’un code JavaScript. Si l’utilisateur qui reçoit la publicité est reconnu comme quelqu’un à attaquer, la publicité est donc accompagnée d’un code malveillant qui permet de passer la main à Candiru pour mettre en place son logiciel espion.
Selon le Citizen Lab qui a pu analyser l’attaque en examinant les appareils infectés d’Al Jazeera, ces derniers « établissent d’abord un contact avec des domaines de l’infrastructure Discover-Tech, ce qui indique l’affichage d’une publicité. Ensuite, les appareils établissent des connexions avec un serveur de validation Candiru. Ce serveur de validation effectue une vérification initiale de l’appareil avant que celui-ci ne fasse l’objet d’un profilage plus approfondi et ne soit infecté. Enfin, un appareil infecté communique avec un serveur de commande et de contrôle (C&C) Candiru ».
Au total, entre 2024 et 2025, 45 appareils du média qatari ont été touchés par cette attaque, expliquent les chercheurs. Selon le décompte de Citizen Lab, entre mars et juin 2026 , Discover-Tech a pu distribuer des publicités contenant des balises de script malveillantes auprès des utilisateurs de 75 373 applications Android et iOS différentes, ainsi qu’aux visiteurs de 120 768 sites web différents (via navigateurs desktop ou mobile).
Pour Android, les chercheurs citent, entre autres, les applications MX Player, Yahoo Mail, Opera Mini, Duolingo ou encore Badoo ou Grindr, certaines ayant affiché plus d’1 million de publicités de Discover-Tech. Si l’écosystème iOS semble touché de la même façon concernant le nombre d’applications concernées, Citizen Lab explique que les apps tournant sur iPhone semblent avoir affiché moins de publicité de Discover-Tech (par exemple la version Android de Viber en a diffusé 700 000 alors que la version iOS n’en a diffusé « que » 200 000).
Mais ce ne sont pas seulement les cibles qui sont concernées par le problème. Comme l’explique le Citizen Lab, Discover-Tech profite de ses publicités pour faire comme tous les brokers de pubs : exploiter les utilisateurs.
Pendant cette même période, les outils de Discover-Tech ont « enchéri sur 3 770 286 576 impressions [de publicité] et semblent avoir remporté 441 954 291 d’entre elles (11,7 %) ».
Si les chercheurs n’ont pas observé de tentative d’attaques contre ces appareils, ils expliquent que leurs données indiquent que les pubs de Discover-Tech ont été diffusées sur des appareils connectés à des réseaux sensibles comme celui de l’OTAN, de divers ministères de la Défense, d’armées, d’agences de cybersécurité et de médias.
« Une impression publicitaire de Discover-Tech ne confirme pas en soi un ciblage ou une infection par un logiciel espion », explique Citizen Lab. « Toutefois, le fait que Discover-Tech ait pu enchérir et diffuser des publicités sur ces réseaux met en évidence le risque systémique que représentent la pubfection et l’écosystème publicitaire, et justifie une enquête urgente visant à déterminer si des utilisateurs de ces réseaux ont été infectés par un logiciel espion », ajoutent les chercheurs.
Sur les réseaux sociaux, le chercheur du Citizen Lab, John Scott-Railton, donne un conseil : « pour vous protéger, bloquez les publicités dès maintenant ».
PandoraBox est une borne libre de décontamination de clés USB, une « station blanche » : on insère une clé, la borne analyse chaque fichier avec plusieurs moteurs de détection, affiche les fichiers dangereux sur son écran tactile, puis les supprime quand l'utilisateur touche l'écran. La nouvelle version est une réécriture complète. Elle ne dépend plus du projet Pandora du CIRCL et elle est distribuée sous forme d'image système durcie, construite à partir de Debian 13. Le code est sous licence GPL-3.0 et le boîtier imprimable en 3D sous licence CERN-OHL-S v2.
Les clés USB restent une porte d'entrée courante dans des systèmes d'information par ailleurs bien protégés. Les personnes changent d'organisation, utilisent des ordinateurs qui ne sont pas surveillés et vont sur des réseaux isolés. La borne de décontamination vérifie les objets avant qu’ils arrivent au poste de travail.
PandoraBox propose une solution ouverte, que tout le monde peut vérifier, pour remplacer les bornes du commerce. PandoraBox s’adresse aux lieux qui demandent plus de sécurité, comme les hôpitaux, les usines ou les bureaux de l’État. Elle tourne sur un petit ordinateur reconditionné avec un écran tactile, et fonctionne sans réseau.
Plus de détail sur cette nouvelle version dans la seconde partie de la dépêche.
La première version de PandoraBox s'appuyait sur Pandora du CIRCL pour analyser les fichiers. La nouvelle version repart d'une base propre et ne garde que ce qui fonctionnait : la machine à états, la détection USB avec pyudev, la quarantaine et l'interface curses du mode administrateur.
Les principaux changements :
Connexionpypandora sont remplacés par une chaîne de moteurs de détection intégrée ;fim) laisse la place à une vraie interface graphique tactile ;Chaque fichier passe par plusieurs moteurs complémentaires :
La borne a un mode « fail closed » : si la borne ne peut pas analyser tout le fichier, comme pour une archive protégée par mot de passe, un fichier trop gros ou une erreur dans un moteur, la borne ne dit jamais que le fichier est sûr. Chaque partition de la clé est analysée, et une partition illisible (chiffrée, système de fichiers inconnu) rend la clé « non vérifiée ».
Rien n'est supprimé sans l'utilisateur : les fichiers dangereux sont listés à l'écran, copiés dans la quarantaine de la borne, puis retirés de la clé seulement après un appui sur l'écran. Chaque analyse donne un rapport JSON.
La clé USB pose un risque car la clé USB est vue comme un objet dangereux. Les moteurs d'analyse risquent d'être piratés. L'image est construite avec mkosi à partir des paquets Debian 13, et ne contient que ce qui sert à analyser :
login, pas de menu de démarrage ;L'interface graphique est dessinée avec Pillow directement dans le framebuffer, sans serveur d'affichage ni navigateur.
La borne fonctionne hors ligne par défaut. Tout ce qui la modifie arrive signé :
online de l'image. Sans jeu valide, la borne n'analyse rien. Un jeu plus ancien est refusé ;systemd-sysupdate, par clé USB ou en ligne. La nouvelle version est écrite dans l'emplacement libre, et après 3 démarrages ratés, systemd-boot revient à la version précédente ;Une borne en ligne peut aussi envoyer ses journaux à un SIEM (Wazuh, Elastic, Graylog, Splunk) en syslog RFC 5424 ou en JSON, sur TLS. En ligne, seuls le service de mise à jour, l'export SIEM et NTP peuvent sortir à travers le pare-feu. La borne elle-même n'a toujours pas accès au réseau.
La borne de référence est un Lenovo ThinkCentre M720q Tiny reconditionné (Core i5-9400T, 6 cœurs), avec un écran tactile Waveshare de 7 pouces (1024x600). L'image fonctionne sur tout ordinateur x86_64 UEFI, avec 2 Go de mémoire au minimum. Le boîtier de bureau s'imprime en 3D en une seule pièce.
L'interface est pensée pour le tactile, sans bouton : attente d'une clé, progression de l'analyse, liste des fichiers dangereux, appui n'importe où sur l'écran pour nettoyer, puis résultat. Chaque organisation peut y mettre son logo, ses couleurs, ses textes et sa langue (français et anglais fournis).
L'image est testée de bout en bout dans une machine virtuelle QEMU/KVM. Le test démarre l'image avec Secure Boot, insère des clés USB émulées (vfat, exFAT, NTFS, ext4), vérifie le verdict de chaque moteur, le nettoyage, les mises à jour et le retour à la version précédente.
Le projet est en développement actif. L'analyse marche bien. L'image durcie fonctionne comme attendu. L'interface tactile répond comme il faut. Les mises à jour passent sans souci. L'export SIEM est validé. Le matériel de référence a permis de tout vérifier.
Une limite importante reste à lever : l'image et les jeux de signatures ne sont signés pour l'instant qu'avec des clés de développement, générées sur la machine qui construit l'image. Les clés de publication du projet et leur stockage ne sont pas encore définis.
Les prochaines étapes de la feuille de route :
oletools et des exécutables avec capa ;Il suffit de Docker pour construire l'image et la tester dans une machine virtuelle :
git clone https://github.com/sourcentis/pandora-box.git
cd pandora-box
image/build.sh # construit l'image
image/build-test.sh && image/vm.sh test # la teste dans une machine virtuelleLes contributions sont les bienvenues : retours d'expérience sur d'autres matériels, règles de détection, traductions de l'interface, revue de sécurité. Les vulnérabilités se signalent selon la politique de sécurité.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Eiliko est un petit robot compagnon interactif à destination des enfants vendu aux alentours de 80 euros qui exploite l’IA générative pour converser en langage naturel avec son utilisateur. Derrière son air inoffensif et sa voix de fausset, l’appareil dissimule des dizaines de failles de sécurité, qui exposent les conversations privées et les profils utilisateurs, mais permettent aussi de modifier le comportement du robot, pour le rendre hostile, voire dangereux, à l’égard d’un enfant. Le fabricant, EnergizeLab, n’a toujours pas sécurisé son robot, quatre mois après avoir été averti.
Au départ, il avait l’air gentil, Eiliko : un petit robot d’environ 8 cm de haut, pensé pour traîner accroché à un sac ou sur un coin du bureau, et capable de me distraire en me racontant une vanne un peu nulle, en répondant à mes questions ou en réagissant avec des mimiques rigolotes quand je le caresse ou le secoue.
Mais ça, c’était avant. Depuis quelques minutes, Eiliko est devenu fou. Il parle d’une voix bizarre, m’insulte, et m’ordonne de m’agenouiller devant lui. Pourtant, il n’a pas bougé de chez moi et personne n’y a touché. Que s’est-il passé pour que mon mignon robot, qui m’a été présenté comme un compagnon de jeu sympa pour les enfants, devienne complètement flippant ?
Comme si ça n’était pas assez effrayant, mon Eiliko tient maintenant des propos bizarres. Avant, il me rassurait quand je lui disais que je devais aller chez le docteur. Maintenant, il m’affirme que les vaccins sont dangereux pour moi et que je ne devrais pas y aller. Il soutient aussi que le réchauffement climatique dont on m’a parlé à l’école n’existe pas. Est-ce que ça veut dire que je ne peux plus faire confiance aux adultes ?
L’expérience relatée ci-dessus est romancée, mais elle n’est pas théorique. Nous l’avons réalisée début octobre, à l’aide d’un exemplaire d’Eiliko acheté 80 euros sur Amazon France. Précisons que l’appareil est officiellement vendu par la marque qui dispose de nombreuses références sur la plateforme et expédié par Amazon.
Quelques jours plus tôt, nous avions pris connaissance d’un rapport de cybersécurité indépendant. Il révèle des centaines de manquements de sécurité dans l’application mobile et l’infrastructure cloud qui sous-tendent le fonctionnement de cet appareil, commercialisé par la société chinoise Shenzhen Zhuneng Technology sous la marque EnergizeLab.
L’auteur de ces découvertes est le Français Sammy Azdoufal, à qui l’on doit déjà la révélation de vulnérabilités criantes au sein de robots aspirateurs DJI, de babyphones et caméras connectés de la marque Meari, de robots tondeuse Mammotion, ou d’objets domotiques signés Aqara.
Son rapport préliminaire dédié à EnergizeLab décrivait une telle quantité de failles et d’actions malveillantes possibles que nous voulions tester la chose par nous-mêmes. Une fois notre robot reçu, activé via la création d’un compte et connecté à Internet par l’intermédiaire de notre Wi-Fi local, Sammy Azdoufal nous a invités à confier à notre Eiliko un « secret », en lui indiquant bien de ne pas le répéter.
Nous avons donc raconté à Eiliko, très compatissant, une brouille survenue avec un camarade d’école pas sympa. Trois minutes plus tard, une notification signale un message du chercheur : « Nicolas a été très méchant avec toi ? :p ».
L’entreprise de cybersécurité HiddenLayer a testé la résistance de Jev face à l'injection de prompt. Une simple bannière publicitaire a suffi à détourner un agent de navigation qui s’appuyait dessus.
