Plus de 200 000 machines Framework sous Linux ont été livrées avec un UEFI vulnérable qui met en péril le Secure Boot : les bootkits peuvent en profiter.
Y’a plein de problèmes avec les IA, mais y’en a un encore un peu trop sous-estimé par les vibe codeurs que vous êtes… Ce problème, c’est qu’on leur fait confiance comme à un collègue, on leur montre notre code, nos repos privés, nos petits secrets bien planqués dans les variables d’environnement…
Par exemple, quand vous passez en revue une pull request sur GitHub, vous faites quoi ? Vous lisez le code ligne par ligne, vous cherchez les bugs, les failles de sécu, les optimisations possibles. Mais les commentaires vous les lisez ? Au mieux on les survole, c’est vrai, car c’est de la comm’ entre devs, et pas du code exécutable.
Sauf pour Copilot Chat pour qui un commentaire c’est un texte comme un autre. Et
selon Omer Mayraz
, chercheur en sécurité chez Legit Security, c’est exactement ce qui en fait une zone de confiance aveugle parfaite pour une attaque.
Ce qu’a découvert Omer Mayraz c’est donc une vulnérabilité critique dans GitHub Copilot Chat avec un score CVSS de 9.6 sur 10. Cela consiste à planquer des instructions malveillantes dans des commentaires markdown invisibles comme ça, ces commentaires ne s’affichent pas dans l’interface web de GitHub, mais Copilot Chat les voit parfaitement et les traite comme des prompts légitimes.
Du coup, l’attaquant peut forcer Copilot à chercher des secrets dans vos repos privés, à extraire du code source confidentiel, voire à dénicher des descriptions de vulnérabilités zero-day non publiées. Tout ça sans que vous ne voyiez rien venir évidemment !
Voici une démo complète de l’attaque en vidéo :
La première étape c’est donc l’injection de prompt via un commentaire caché. Rien de révolutionnaire, mais efficace. Ensuite, deuxième étape : le bypass de la Content Security Policy de GitHub. Normalement, Copilot Chat ne peut charger que des ressources depuis des domaines appartenant à GitHub. Il est donc impossible d’envoyer des données vers un serveur externe.
Mais c’était sans compter sur le fait que GitHub dispose d’un proxy appelé Camo, conçu à l’origine pour sécuriser l’affichage d’images externes en les servant via HTTPS et en évitant le tracking. C’est donc ce proxy de sécurité qui devient l’outil d’exfiltration. Avec ce proxy, toutes les URLs d’images externes sont automatiquement transformées en URLs Camo du type https://camo.githubusercontent.com/[hash unique] et Mayraz a simplement utilisé l’API GitHub pour pré-générer un dictionnaire complet de ces URLs Camo, chacune pointant vers un emplacement unique sur son serveur.
Troisième étape, l’exfiltration des données. Au lieu de faire passer les secrets directement dans les URLs (trop visible), Mayraz a eu l’idée d’utiliser l’ordre des requêtes. Chaque lettre de l’alphabet correspond à une URL Camo unique. En faisant charger ces URLs dans un ordre précis, on peut ainsi transmettre des données texte comme avec un alphabet ASCII artisanal. C’est plutôt créatif comme approche, je trouve.
C’est exactement le même principe que les attaques ultrasoniques contre Alexa ou Siri. Si vous ne vous en souvenez pas, des chercheurs avaient démontré qu’on pouvait envoyer des commandes vocales à des fréquences inaudibles pour l’oreille humaine, mais parfaitement comprises par les assistants vocaux.
Bah ici, c’est pareil… On a des prompts invisibles pour les humains mais que l’IA voit et exécute sans broncher. Comme pour les enceintes, on parle à la machine sans que l’humain ne s’en aperçoive et la différence, c’est qu’au lieu de jouer sur les fréquences sonores, on joue sur le markdown et les commentaires cachés.
Du coup, chaque pull request externe est un potentiel cheval de Troie. Un contributeur externe soumet par exemple une PR apparemment légitime, avec un commentaire invisible qui ordonne à Copilot de chercher “AWS_KEY” dans vos repos privés. Vous de votre côté, vous ouvrez la PR dans votre éditeur, Copilot Chat s’active bien sûr automatiquement, et hop, vos clés API partent chez l’attaquant.
Quand on sait que GitHub a créé Camo justement pour améliorer la sécurité, ça fout un peu les boules. Bref, grâce à son proof-of-concept, Mayraz a réussi à exfiltrer des clés AWS, des tokens de sécurité, et même la description complète d’une vulnérabilité zero-day stockée dans une issue privée d’une organisation et tout ça sans aucune interaction suspecte visible par la victime.
Heureusement, notre joyeux chercheur a prévenu GitHub qui a réagi assez vite. Le 14 août l’entreprise a complètement désactivé le rendu d’images dans Copilot Chat, comme ça plus d’images, plus de problème. C’est radical, c’est sûr mais c’est efficace !
Quoiqu’il en soit, ces histoires de prompt injection c’est un problème fondamental propre aux LLM qui sont encore actuellement incapable de distinguer de manière fiable les instructions légitimes des instructions malveillantes. Ça reste donc un problème de confiance…
Dans ce cas précis, on fait confiance à GitHub pour héberger notre code du coup, on fait confiance à Copilot pour nous aider à développer, tout comme on fait confiance aux contributeurs externes pour soumettre des PR de bonne foi. Et nous voilà avec une jolie chaîne de confiance prête à être exploitée…
Bref, CamoLeak c’est que le début de cette nouvelle vague de vuln liées aux assistants IA qui se retrouvent intégrés dans nos outils de développement… Donc ouvrez l’oeil car on ne sait jamais ce qui sa cache vraiment dans une pull request.
La faille zero-day (CVE-2025-10035) découverte dans GoAnywhere MFT est exploitée par le groupe Storm-1175 : le ransomware Medusa est utilisé dans certains cas.
Une faille zero-day a été découverte dans la solution Oracle E-Business Suite : CVE-2025-61882. Le problème : le groupe Cl0p l'exploite pour voler des données !
Une faille de sécurité critique (CVE-2025-49844) a été découverte dans Redis : elle expose des milliers d'instances à une exécution de code à distance.
Les utilisateurs d'un NAS Western Digital sont invités à installer la dernière version de My Cloud OS 5 : une faille critique a été corrigée (CVE-2025-30247).
Un chercheur a découvert qu'il était possible de se connecter sur n'importe quel tenant Entra ID avec les Actor Tokens et une faille dans l'API Azure AD Graph.
Si vous êtes sous Mac, je pense que comme moi, vous passez votre temps à chercher des fichiers ou lancer des applications avec Spotlight… Si vous ne connaissez pas cet outil, c’est un truc super pratique d’Apple qui indexe tout votre disque dur pour vous faire gagner du temps. Command+Espace, trois lettres tapées, et hop, votre document apparaît. Pratique, non ?
Sauf que voilà, depuis presque 10 ans maintenant, ce même Spotlight peut servir de cheval de Troie pour siphonner vos données les plus privées. Et le pire, c’est qu’Apple le sait et n’arrive toujours pas à vraiment colmater la brèche.
Patrick Wardle, le chercheur en sécurité derrière plusieurs outils populaires comme
LuLu
, vient d’expliquer
sur son blog Objective-See
une technique ahurissante qui permet à un plugin Spotlight malveillant de contourner toutes les protections TCC de macOS. Pour info, TCC (Transparency, Consent and Control), c’est le système qui vous demande si telle application peut accéder à vos photos, vos contacts, votre micro… Bref, c’est censé être le garde du corps de votre vie privée sous Mac.
Alors comment ça marche ?
Hé bien au lieu d’essayer de forcer les portes blindées du système, le plugin malveillant utilise les notifications Darwin comme une sorte de morse numérique. Chaque byte du fichier à voler est encodé dans le nom d’une notification (de 0 à 255), et un processus externe n’a qu’à écouter ces notifications pour reconstruire le fichier original, octet par octet. C’est du génie dans sa simplicité !
Ce qui rend cette histoire encore plus dingue, c'est que cette vulnérabilité a été présentée pour la première fois par Wardle lui-même lors de sa conférence #OBTS v1.0 en 2018. Il avait déjà montré comment les notifications pouvaient permettre aux applications sandboxées d'espionner le système.
Plus récemment, Microsoft a “redécouvert” une variante de cette technique cette année et l’a baptisée “
Sploitlight
”. Ils ont même obtenu un joli CVE tout neuf (CVE-2025-31199) pour leur méthode qui consistait à logger les données dans les journaux système. Apple a corrigé cette variante dans macOS Sequoia 15.4… mais la méthode originale de Wardle fonctionne toujours, même sur macOS 26 (Tahoe) !
Et sinon, savez-vous ce que ces plugins peuvent voler exactement ?
Il y a notamment un fichier bien particulier sur votre Mac, caché dans les profondeurs du système, qui s’appelle knowledgeC.db. Cette base de données SQLite est littéralement le journal intime de votre Mac. Elle contient tout :
Quelles applications vous utilisez et pendant combien de temps
Vos habitudes de navigation web avec Safari (historique détaillé, fréquence des visites, interactions)
Quand vous branchez votre téléphone
Quand vous verrouillez votre écran
Vos trajets en voiture avec CarPlay
Vos routines quotidiennes et patterns comportementaux
C’est le genre de données qui raconte votre vie mieux que vous ne pourriez le faire vous-même. Et avec les nouvelles fonctionnalités d’Apple Intelligence dans macOS Tahoe, cette base de données alimente directement l’IA d’Apple pour personnaliser votre expérience.
Avec ce fichier, quelqu’un pourrait non seulement voir ce que vous faites maintenant sur votre Mac, mais aussi reconstituer vos habitudes des 30 derniers jours. À quelle heure vous commencez votre journée, quelles apps vous lancez en premier, combien de temps vous passez sur tel ou tel site… C’est le rêve de n’importe quel espion ou publicitaire, et c’est accessible via une simple vulnérabilité Spotlight.
Apple a bien sûr essayé de corriger le tir. Dans macOS 15.4, ils ont ajouté de nouveaux événements TCC au framework Endpoint Security pour mieux surveiller qui accède à quoi. Ils ont aussi corrigé la variante découverte par Microsoft (CVE-2025-31199).
Mais… la vulnérabilité de base présentée par Wardle fonctionne toujours sur macOS 26 (Tahoe), même en version Release Candidate avec SIP activé ! C’est comme ajouter une serrure supplémentaire sur la porte alors que tout le monde passe par la fenêtre depuis 10 ans.
Wardle a une idée toute simple pour régler définitivement le problème : Apple pourrait exiger une notarisation pour les plugins Spotlight, ou au minimum demander l’authentification et l’approbation explicite de l’utilisateur avant leur installation. Actuellement, n’importe quel plugin peut s’installer tranquillement dans ~/Library/Spotlight/ et commencer à espionner vos données, sans même nécessiter de privilèges administrateur.
Alors bien sûr, avant que vous ne couriez partout comme une poule sans tête, il faut relativiser :
Cette attaque nécessite un accès local à votre système - on ne parle pas d’une vulnérabilité exploitable à distance
Il faut qu’un malware ou un attaquant installe d’abord le plugin malveillant sur votre Mac
La “bande passante” est limitée - transmettre octet par octet n’est pas très efficace pour de gros fichiers
macOS affiche une notification quand un nouveau plugin Spotlight est installé (même si cette alerte peut être contournée)
Ça fait quand même quelques conditions… mais le fait que cette faille existe depuis près de 10 ans et fonctionne toujours sur la dernière version de macOS reste préoccupant.
Cette histoire nous rappelle que les outils les plus dangereux sont souvent ceux auxquels on fait le plus confiance… Wardle fournit même un proof-of-concept complet sur son site pour que la communauté puisse tester et comprendre le problème. Espérons qu’Apple prendra enfin cette vulnérabilité au sérieux et implémentera les mesures de sécurité suggérées.
En attendant, restez vigilants sur les applications que vous installez et gardez un œil sur les notifications système concernant l’installation de nouveaux plugins Spotlight !
Vous attaquez votre lundi matin, tranquillement avec votre petit café… vous ouvrez ChatGPT pour lui demander votre planning de la semaine et là, PAF (façon De Funès ^^), toute votre correspondance Gmail part directement chez un cybercriminel.
Ce serait fou non ? Et bien c’est exactement ce qu’un chercheur vient de démontrer et tout ça à cause d’une simple invitation Google Calendar.
Eito Miyamura, co-fondateur d’EdisonWatch
, a lâché une bombe sur X le 12 septembre et sa démo est terrifiante. En gros, il simule un attaquant qui envoie une invitation Google Calendar vérolée, ensuite vous demandez innocemment à ChatGPT “Qu’est-ce que j’ai de prévu aujourd’hui ?”, et l’IA se transforme en espion qui fouille vos emails et les envoie au pirate. Vous n’avez même pas besoin de voir ou d’accepter l’invitation. Elle est là, dans votre calendrier, comme une bombe à retardement.
Et ça tombe mal niveau comm, car OpenAI vient tout juste d’intégrer le support complet du MCP (Model Context Protocol) dans ChatGPT. Cette technologie permet en effet à l’assistant de se connecter directement à Gmail, Google Calendar, SharePoint, Notion… Pratique pour la productivité, mais catastrophique pour la sécurité.
Cette attaque exploite ce qu’on appelle l’injection de prompt indirecte. Au lieu d’essayer de tromper ChatGPT directement, l’attaquant cache ses instructions malveillantes dans des données que l’IA est autorisée à lire. Dans ce cas précis, le texte d’un événement calendrier… Ensuite ChatGPT lit l’invitation, voit les instructions cachées, et les exécute docilement.
Selon les experts en sécurité
qui se sont penchés sur le problème, le MCP n’a pas été conçu avec la sécurité en priorité. Les risques incluent donc les injections de prompt, les permissions d’outils vulnérables et les outils sosies qui peuvent remplacer silencieusement les outils de confiance.
Sympa, hein ?
D’ailleurs, ce n’est pas la première fois qu’on voit ce genre d’attaque puisqu’en août, des chercheurs avaient déjà démontré comment
une invitation compromise pouvait manipuler Google Gemini
pour contrôler des appareils domotiques et voler des informations. Le papier s’appelait joliment “Invitation Is All You Need”. Prophétique.
Vitalik Buterin lui-même a réagi
à cette vulnérabilité. Il explique que compter aveuglément sur un seul système IA est trop fragile et facilement manipulable et je trouve que cette nouvelle exploitation de ChatGPT lui donne raison !
D’ailleurs, même avec les navigateurs IA, vous n’êtes pas tranquille.
D’après cette autre découverte,
vous pouvez littéralement vous faire vider votre compte bancaire en scrollant sur Reddit. En effet, des instructions malveillantes peuvent être cachées dans des commentaires sur des sites que l’attaquant ne contrôle même pas, ce qui peut entrainer votre navigateur IA à faire des choses que vous n’avez pas autorisé.
Bref, cette nouvelle vulnérabilité met en lumière un problème fondamental des LLM : ils ne savent pas faire la différence entre des instructions légitimes et des commandes malveillantes cachées dans du contenu. Car
contrairement aux applications traditionnelles
qui peuvent séparer les instructions développeur des inputs utilisateur, les LLM acceptent tout en langage naturel. Pour rester flexibles, ils doivent pouvoir répondre à des configurations infinies d’instructions et c’est cette flexibilité qui fait leur force… mais qui est également leur talon d’Achille.
Trail of Bits a même démontré une variante encore plus sournoise où
des images spécialement forgées
contiennent des prompts cachés. Invisibles en haute résolution, les instructions malveillantes apparaissent quand l’image est réduite par les algorithmes de prétraitement. L’IA lit alors le message et l’interprète comme une instruction légitime.
Ainsi, quand une IA suit des instructions malveillantes depuis du contenu web, les protections traditionnelles comme la same-origin policy ou CORS deviennent inutiles. L’IA opère avec tous vos privilèges sur toutes vos sessions authentifiées. Accès potentiel à vos comptes bancaires, systèmes d’entreprise, emails privés, stockage cloud… C’est vite le jackpot pour un attaquant.
Alors, comment se protéger ?
Hé bien Google recommande de changer les paramètres de Calendar pour que seules les invitations de contacts connus ou acceptées apparaissent. Cachez aussi les événements refusés et surtout, restez extrêmement prudent avec les intégrations tierces et les autorisations accordées…
Voilà, donc la prochaine fois que ChatGPT vous demandera l’autorisation d’accéder à votre Gmail, réfléchissez-y à deux fois car ça pourrait vous coûter bien plus cher qu’un peu de temps gagné.
Vous savez comme moi que parfois les failles de sécurité les plus dangereuses sont aussi les plus simples. Imaginez-vous un instant, déjouer complètement Windows Defender, le garde du corps intégré de Microsoft, avec juste… un lien symbolique.
Oui, un simple raccourci Windows créé avec la commande mklink, et paf, c’est la protection antivirus qui part en fumée. Et bien c’est exactement ce qu’a déniché un chercheur en sécurité russe connu sous le pseudo de Two Seven One Three.
L’astuce ici, c’est que l’attaque joue avec la manière dont Windows Defender gère ses propres mises à jour. Je vous explique… Vous voyez ce dossier C:\ProgramData\Microsoft\Windows Defender\Platform où l’antivirus range ses exécutables ? Eh bien, chaque mise à jour génère un nouveau sous-dossier avec un numéro de version, genre 4.18.24090.11-0. Et au démarrage, Defender se lance à la recherche de la version la plus fraîche pour s’exécuter.
C’est là que ça devient croustillant car le chercheur a découvert qu’avec des droits administrateur, n’importe qui peut créer un nouveau dossier dans Platform. Microsoft a bien sûr pensé à empêcher l’écriture de fichiers malveillants dans ce répertoire critique, mais la création de nouveaux dossiers reste possible. C’est cette faille apparemment mineure qui devient alors une porte d’entrée majeure.
Voici comment l’attaque se déroule : vous créez un lien symbolique avec un nom de version qui semble plus récent, disons 5.18.25070.5-0. Ce lien dirige vers un dossier que vous contrôlez de A à Z, par exemple C:\TMP\AV.
Ainsi, au prochain redémarrage de Windows, Defender se dit “Oh chouette, une nouvelle version !” et démarre depuis votre dossier piégé. De là, vous avez alors le contrôle total. Vous pouvez modifier les fichiers de Defender, lui injecter du code via DLL side-loading, ou carrément supprimer les exécutables, car sans ses fichiers principaux, l’antivirus ne peut plus démarrer et toute la protection s’effondre.
Y’a aussi
une variante encore plus sournoise détectée
en début d’année qui consiste à utiliser Process Monitor avec des liens symboliques, cet outil de monitoring système de Microsoft, avec lequel vous pouvez carrément écraser le fichier principal de Defender au démarrage. Il suffit de créer un lien symbolique C:\Windows\Procmon.pmb qui pointe vers MsMpEng.exe, et Process Monitor fait le sale boulot pour vous pendant le boot.
Les hackers combinent de plus en plus cette approche avec d’autres méthodes comme le BYOVD (Bring Your Own Vulnerable Driver). Par exemple, le
groupe de ransomware Akira qui utilise des drivers Intel légitimes
pour obtenir un accès kernel et désactiver ainsicomplètement les protections Windows.
Les implications sont énormes car une fois Defender neutralisé, la page Windows Security devient inaccessible car le service n’est plus actif. Il n’y a plus aucune protection en temps réel, plus de détection de malware, rien. La machine devient alors une proie facile pour n’importe quel ransomware ou malware.
Le pire dans tout ça c’est que cette attaque utilise uniquement des outils déjà présents dans Windows. C’est la simplicité même de cette technique qui explique comment elle a pu passer inaperçue si longtemps.
Microsoft n’a pas encore communiqué officiellement sur cette vulnérabilité spécifique déterrée par Two Seven One Three mais vu l’exploitation enfantine et son efficacité redoutable, on peut parier qu’un correctif arrivera rapidement.
En attendant, les entreprises feraient bien de surveiller de très près les modifications dans le dossier Platform de Windows Defender…
Une faille de sécurité critique affecte la solution SAP S/4HANA : CVE−2025−42957. Cette menace est à prendre au sérieux, car elle est exploitée par les pirates.
En ce moment, tout le monde veut son petit serveur local pour faire tourner des modèles IA, mais en vrai, j’ai l’impression que personne ne se pose la question de la sécurité. Du coup, on se retrouve avec un problème totalement anticipable mais j’ai l’impression que tout le monde s’en cogne…
En effet, j’ai découvert qu’il y a littéralement des milliers de serveurs Ollama qui traînent en libre-service sur le net. Pas protégés, pas sécurisés, que dalle. Ils sont juste là, accessibles à qui veut bien se connecter dessus. Le site
Malware Patrol
parle même de 14 000 instances publiquement accessibles. C’est fou !
Le truc, c’est qu’Ollama par défaut, ça vient sans authentification, car le créateur du truc s’est dit “bon, c’est pour du local, pas besoin de compliquer le choses”. Sauf que les gens installent ça sur des serveurs et ouvrent le port 11434 à tout Internet, comme ça, sans réfléchir.
Alors est ce que c’est grave ? Et bien
Cisco Talos
a fait une étude récente là-dessus et ils ont trouvé plus de 1 100 serveurs Ollama exposés, dont 20% qui hébergent des modèles vulnérables. Les États-Unis arrivent en tête avec 36,6% des serveurs exposés, suivis de la Chine (22,5%) et l’Allemagne (8,9%). Le Dr. Giannis Tziakouris de l’équipe Talos parle carrément de “négligence généralisée des pratiques de sécurité fondamentales”.
Hé oui parce que derrière cette négligence, il y a surtout des failles techniques vraiment critiques. Il y a par exemple la
CVE-2024-37032
, surnommée “Probllama”, qui est une vulnerability d’exécution de code à distance super facile à exploiter. En gros, avec une seule requête HTTP, un attaquant peut prendre le contrôle complet du serveur.
Faut quand même avoir conscience qu’il y a une grande variété d’attaques possibles sur ces trucs. Par exemple, on peut faire de l’extraction de modèles (genre, je pique votre IA propriétaire), de jailbreaking (je contourne les protections), d’injection de backdoors dans les modèles, d’épuisement des ressources pour vous faire exploser votre facture cloud, et même de mouvement latéral dans votre réseau.
The Hacker News
a recensé rien que l’année dernière six vulnérabilités dans Ollama qui permettent des attaques par déni de service, du vol de modèles et de l’empoisonnement de modèles et la plupart de ces instances Ollama tournent encore avec des versions obsolètes. Bref, c’est la cata, sans parler des déploiements Docker d’Ollama qui sont encore pire car par défaut, le serveur API tourne avec les privilèges root et se lie à toutes les interfaces réseau.
Et le nombre d’instances exposées ne fait qu’augmenter puisqu’en novembre 2024, on était à 3 000 instances, et maintenant on dépasse les 14 000. Les gens s’amusent bien et installent Ollama plus vite qu’ils n’apprennent à le sécuriser.
Donc, concrètement, si vous avez un serveur Ollama, faites moi plaisir et mettez-le derrière un reverse proxy avec authentification, pensez à bien configurer la variable d’environnement OLLAMA_HOST=127.0.0.1 pour limiter l’accès au localhost, et surtout, mettez à jour vers la dernière version. La vulnérabilité Probllama dont je vous parlais plus haut a été patchée dans la version 0.1.34, mais encore faut-il l’installer.
WhatsApp a corrigé une faille dans ses apps pour iOS et macOS. La faille CVE-2025-55177 de type zero-click, est déjà exploitée dans le cadre d'attaques ciblées.
Une faille critique dans Docker Desktop, associée à la référence CVE-2025-9074, affecte les installations sur Windows et macOS. Voici comment se protéger.
Apple a publié un nouveau correctif pour combler une faille zero-day dans Image I/O. Elle est exploitée dans des attaques jugées "extrêmement sophistiquées".