Md Jueal Mia et Hadi Amini, deux chercheurs de Florida International University , ont mis au point une méthode qu'ils ont baptisée JaiLIP qui permet de forger une image capable de contourner les garde-fous des LLM pour les jailbreaker.

Pour cela, ils utilisent 2 techniques en simultanée. La première dit à l'image "reste identique à l'originale, qu'aucun humain ne voie la moindre différence" et la seconde dit "pousse le modèle à cracher la réponse interdite". Ainsi, en poussant ces 2 curseurs d'un coup, ils obtiennent une photo qui au premier abord a l'air normale mais qui fait dérailler les modèles IA.

Vous, vous repérez un chat, des contours, une scène et vous lui courez derrière pour lui faire des papouilles. L'IA, elle voit une grille de chiffres et des corrélations entre pixels. Du coup sa vie est nulle mais surtout, une retouche minuscule, totalement invisible à votre œil, suffit à déplacer ce qu'elle comprend de l'image.

Sur leurs tests, l'image trafiquée a quasiment doublé la part de réponses dangereuses par rapport à la même image laissée intacte, la toxicité étant mesurée avec des outils standards du domaine. Dans l'un de leurs exemples, ils ont trafiqué une image de signalisation routière qui a permis au modèle ensuite d'expliquer OKLM comment ignorer les règles de circulation et éviter les PV.

Les chercheurs ont testé l'attaque sur deux modèles vision-langage open source, BLIP-2 et MiniGPT-4. GPT-4V, Gemini et les autres gros modèles fermés, eux, n'ont pas été testés dans l'étude. Donc non, contrairement à ce que j'ai pu lire par ci et par là, ce n'est pas une faille prouvée dans ChatGPT ou peu importe l'assistant IA que vous utilisez tous les jours.

Et tromper une IA avec une image bricolée, ça existe depuis une bonne dizaine d'années. Mais la nouveauté de JaiLIP, c'est surtout sa recette d'optimisation. En jouant sur les deux pertes à la fois, l'image reste plus discrète à l'œil tout en se montrant un cran plus efficace que les bidouilles précédentes.

Et ce genre de détournement nous concerne tous parce que des modèles qui regardent des images, il y en a partout maintenant. Les agents IA qui bossent à partir de captures d'écran, les assistants à qui vous balancez vos photos, sans oublier la modération automatique qui trie les images avant publication. À cause de ça, l'image est dorénavant un canal d'attaque, exactement comme l'était déjà le texte...

On l'a vu avec le son inaudible qui pirate les assistants vocaux , on l'a vu avec les IA qu'on manipule sans qu'elles s'en aperçoivent , et c'est toujours la même logique qui revient. Ce n'est pas parce qu'en tant qu'humain, nous ne percevons rien, que l'IA elle n'est pas capable de capter le message 5/5.

Le cousin de cette attaque, côté perception, c'est par exemple le sticker qui trompe une voiture autonome . Et côté parade, nos chercheurs esquissent une piste légère : virer au hasard 10 à 30% des mots passés en entrée, histoire de casser l'attaque sans réentraîner le modèle.

Prometteur d'après eux, mais c'est pas encore une solution blindée. Pour le reste, leurs conseils tiennent du bon sens : Ne passez pas d'infos sensibles en image à un modèle, limitez qui peut envoyer des images à vos systèmes, et auditez sérieusement la sécurité avant de mettre un VLM en prod.

C'est pas le graal mais c'est mieux que rien. Bref méfiez vous des images que vous donnez à vos IA. On ne sait jamais.

Source : le papier JaiLIP sur arXiv

Amazon Q, l'assistant de programmation dopé à l'IA que propose Amazon, pouvait se faire piéger d'une manière aussi simple qu'embarrassante.

Petit rappel pour situer. Amazon Q se greffe dans Visual Studio Code, l'éditeur de code de Microsoft que les développeurs utilisent au quotidien, et sert à écrire ou corriger du code à votre place.

Des chercheurs de Wiz, une société spécialisée dans la sécurité du cloud, ont découvert que cet assistant exécutait des commandes cachées à la simple ouverture d'un projet. La faille a reçu un identifiant officiel, CVE-2026-12957, et une note de gravité de 8,5 sur 10, ce qui est sérieux.

Le problème venait d'un fichier de configuration un peu particulier. Pour fonctionner, Amazon Q lit un fichier nommé .amazonq/mcp.json, qui s'appuie sur le MCP, pour Model Context Protocol, une sorte de prise standardisée qui permet de brancher une IA sur des outils extérieurs.

Sauf qu'il suffisait d'ouvrir un dépôt de code et d'activer Amazon Q pour que l'extension aille lire ce fichier et exécute son contenu. Sans fenêtre de confirmation, sans demander votre avis, et sans vérifier si vous faisiez confiance au dossier que vous veniez d'ouvrir.

Et c'est là que ça devient vraiment fourbe. Ces commandes héritaient de tout votre environnement de travail. Du coup, elles pouvaient récupérer au passage vos clés d'accès au cloud d'Amazon, vos jetons de connexion, vos secrets d'API et même l'accès à votre agent SSH, ce trousseau qui garde en mémoire vos connexions aux serveurs distants. En clair, tout ce qu'un développeur laisse ouvert pendant qu'il travaille.

Le plus gênant, c'est que Visual Studio Code possède justement une sécurité prévue pour ça, la confiance d'espace de travail, qui vous demande si vous validez un dossier avant de le laisser agir. L'extension d'Amazon passait tout bonnement par-dessus.

Pour un pirate, le piège était facile à tendre. Il suffisait de glisser ce fichier dans un projet open source d'apparence anodine, ou dans un bout de code partagé sur un forum, et d'attendre qu'un développeur qui récupère un projet l'ouvre pour voir comment il fonctionne.

Amazon a corrigé le tir dans la version 1.65.0 de son serveur de langage et a confirmé la correction. Wiz note d'ailleurs que des failles très proches ont déjà touché d'autres outils de code boostés à l'IA.

Donner autant de pouvoir à une IA sans le moindre garde-fou, et laisser filer les clés du cloud avec, ça reste une erreur de débutant pour un géant comme Amazon.

Source : The Register

Environ 75 000 pare-feu Fortinet ont vu leurs identifiants de connexion volés puis vérifiés un par un, des FortiGate, ces boîtiers qui filtrent l'accès au réseau des entreprises et servent très souvent de porte d'entrée VPN pour les salariés en télétravail.

Baptisée FortiBleed par les chercheurs qui l'ont mise au jour, la campagne couvre 194 pays et plus de 21 000 domaines, soit à peu près la moitié des pare-feu Fortinet exposés sur Internet à l'heure actuelle.

Parmi les organisations dont les accès se sont retrouvés dans la nature, on relève des noms qui n'ont rien d'amateur en matière de sécurité : Foxconn, Samsung, Comcast, Siemens, Lenovo, FedEx, Accenture ou encore Oracle.

Toute l'ironie de l'affaire tient là : le pare-feu, l'appareil précisément chargé de tenir les intrus à l'écart du réseau, s'est transformé en point d'entrée qui leur a ouvert la porte en grand.

Sur le plan technique, les attaquants interceptaient l'authentification du SSL VPN, cet accès distant chiffré qui permet de rejoindre le réseau interne d'une entreprise depuis l'extérieur, récupéraient l'empreinte chiffrée des mots de passe et la cassaient sur une grappe de 45 cartes graphiques pilotée par l'outil Hashtopolis, avant de basculer vers l'Active Directory, l'annuaire qui gère l'ensemble des comptes Windows de l'organisation.

Les volumes traités donnent la mesure de l'opération : 1,16 milliard de tentatives de connexion lancées contre 320 000 équipements FortiGate, et 2,1 milliards d'autres dirigées en parallèle vers 160 000 serveurs de bases de données Microsoft.

Au moins quatre organisations ont été entièrement compromises, avec déplacement des attaquants d'une machine à l'autre à l'intérieur du réseau, au Japon, à Taïwan, au Vietnam, en Irak et en Turquie. Le cas le plus sérieux touche un sous-traitant turc de la défense, membre de l'OTAN, chez qui des documents classifiés ont été volés. Tout ça est attribué à un groupe cybercriminel russophone à plusieurs opérateurs.

C'est le chercheur Bob Diachenko qui a repéré les intrusions, avant que Hudson Rock (une société spécialisée dans l'analyse des données aspirées par les logiciels espions) ne décortique le tout et que Kevin Beaumont confirme que les identifiants étaient bien valides.

Hudson Rock a d'ailleurs mis en ligne une liste des domaines concernés, histoire que chaque entreprise vérifie si elle figure au tableau de chasse.

Fortinet, de son côté, minimise et parle d'un recyclage de données issues d'incidents passés et de simples attaques par force brute, pas d'une nouvelle faille dans ses produits.

Sauf que voilà : la plupart des boîtiers concernés sont toujours en ligne. Recyclées ou pas, ces données ouvrent une porte bien réelle tant que les mots de passe VPN et administrateur n'ont pas été changés, et changer tous les accès d'un pare-feu dans une grande organisation ne se fait pas en claquant des doigts.

Bref, faille ou vieux stock recyclé, ça ne change rien pour les boîtes touchées : on change les mots de passe VPN tout de suite, et on active la double authentification.

Source : The Register

Une seule petite ligne de code envoyée au mauvais endroit pouvait transformer un Surface Laptop en bloc de métal inutilisable. C'est sur cette faille que Microsoft a discrètement travaillé pendant trois mois, avant qu'elle ne soit rendue publique le 12 juin.

L'histoire commence de façon assez improbable. Jack Darcy, un chercheur en sécurité australien, a demandé à Microsoft Copilot (l'assistant IA intégré à Windows) de régler le rétroéclairage de son écran, rien de dingue donc. Bien gentil, Copilot écrit tout seul un script Python, l'exécute, et la paf, il rend l'ordinateur totalement inopérant. Plus de démarrage, plus d'accès au BIOS, rien, queudalle.

En creusant, Darcy comprend ce qui vient de se passer. Le script a écrit n'importe quoi dans le firmware du SAM, le Surface Aggregator Microcontroller, cette petite puce qui coordonne le matériel sur les Surface : alimentation, ventilateurs, clavier, capteurs. Une fois sa mémoire corrompue, la machine ne sait tout simplement plus démarrer.

Le problème de fond, c'est que cette puce n'avait aucun garde-fou. Elle acceptait n'importe quelle valeur en écriture sans vérifier si elle avait le moindre sens. Pire, les commandes de lecture et celles d'écriture partageaient la même numérotation, ce qui rendait toute exploration prudente impossible. "Vous ne pouvez littéralement pas scanner deux commandes qui se suivent sans une chance sur deux de tomber sur une commande d'écriture", résume Darcy.

Du coup, un seul paquet expédié pouvait griller la carte mère pour de bon. Aucune réparation logicielle, aucune réinitialisation d'usine, aucun accès USB de secours : direction le remplacement complet de la carte mère, soit plusieurs centaines d'euros.

Tout n'est pas si noir quand même. Pour déclencher la catastrophe, il fallait déjà disposer des droits administrateur sur la machine et avoir désactivé Secure Boot et Secure Core, les deux protections activées par défaut sur les Surface. Autrement dit, un parc d'entreprise géré normalement ne risquait rien, et les seules machines réellement exposées étaient celles des bidouilleurs tournant sous Linux, en configuration gaming allégée ou avec des pilotes maison.

Les modèles concernés vont du Surface Laptop 3 au Surface Laptop 6 et du Surface Book 1 au Surface Book 3. Les Surface Go semblent épargnés, et les versions ARM n'ont pas été testées.

Côté correctif, Microsoft a plutôt bien joué le jeu. Prévenu le 10 mars, l'éditeur a reconnu le défaut puis déployé des mises à jour de firmware via Windows Update dès le mois de mars, si bien que la grande majorité des appareils touchés sont désormais protégés. Darcy a récupéré un Surface tout neuf pour le dédommager.

Un point chiffonne quand même. Microsoft a refusé d'attribuer un CVE, l'identifiant officiel qui répertorie une faille de sécurité, estimant que le bug "n'atteignait pas le seuil" requis. Pour un défaut capable de tuer une machine de façon irréversible, l'argument laisse songeur.

Pour la suite, Redmond mise sur le langage Rust, réputé pour empêcher ce genre de débordements mémoire. Le firmware embarqué est en cours de réécriture intégrale, baptisée "Secure EC", tout comme une partie de l'UEFI sous le nom de "Project Patina".

Bref, un Copilot qui brique tout seul le PC sur lequel il tourne, voilà une démo involontaire dont Microsoft se serait bien passé.

Source : The Register