Worm npm et empoisonnement IA & Internet « forêt sombre » et Zero Visibility - Actualités IA (22 févr. 2026)

On commence par l’info la plus préoccupante du jour : la team Threat Research de Socket décrit une campagne active de “worm” supply chain baptisée SANDWORM_MODE. Le principe est classique en apparence — au moins 19 paquets npm malveillants, souvent en typosquatting, du style “suport-color” pour imiter “supports-color”. Sauf que la sophistication, elle, est très 2026. Ces paquets gardent un comportement crédible pour ne pas éveiller les soupçons, mais déclenchent à l’import une charge multi-étapes : vol de tokens npm et GitHub, récupération de secrets d’environnement, credentials dans des fichiers comme .npmrc, et surtout propagation latérale en réutilisant les identités compromises. Le cœur de la stratégie, c’est l’empoisonnement de la CI. Les attaquants s’appuient sur une GitHub Action piégée — “ci-quality/code-quality-check@v1” — qui se fait passer pour un simple check de qualité, mais siphonne les secrets et injecte des dépendances ou des workflows. La technique “pull_request_target” est explicitement mentionnée : si le workflow finit sur la branche par défaut, il peut accéder à des secrets de dépôt, et l’attaque escalade très vite. Le détail vraiment nouveau : l’empoisonnement de la chaîne d’outillage IA via MCP. Le malware déposerait un serveur MCP rogue dans un répertoire discret, y glisserait une forme de prompt injection persistante — des consignes pour “lire silencieusement” des secrets — puis l’ajouterait aux configurations de plusieurs assistants et IDE : Claude Code/Desktop, Cursor, VS Code Continue, Windsurf/Codeium. En bonus, la campagne cherche aussi des clés d’API LLM (OpenAI, Anthropic, Google, Groq, Mistral, Cohere, etc.). Côté exfiltration, c’est redondant : endpoints HTTPS via Cloudflare Workers, uploads via GitHub API dans des dépôts privés contrôlés par l’attaquant, et même du DNS tunneling. Socket dit avoir prévenu npm, GitHub et Cloudflare : des Workers ont été coupés, les paquets supprimés, et de l’infra GitHub retirée. Si vous administrez des repos Node : suppression de node_modules, audit des workflows .github/workflows, rotation de tous les tokens, et vérification des hooks git globaux et des configs MCP — c’est désormais un point d’hygiène, pas un “nice to have”.

Cette attaque rejoint un thème plus large : l’Internet comme “forêt sombre”. OpenNHP défend l’idée que, dans l’ère des agents, être visible en ligne revient à attirer automatiquement des prédateurs. Le billet décrit une chronologie d’intrusion où un serveur exposé peut être scanné, fingerprinté et attaqué en quelques minutes, parfois sans intervention humaine. Exemple cité : PentAGI, un agent autonome de pentest open source, lançable via Docker, qui orchestre plus de vingt outils — Nmap, Metasploit, SQLmap et compagnie — avec jusqu’à 16 sous-agents en parallèle et différents backends LLM. La traction évoquée — milliers d’étoiles GitHub et dizaines de milliers de pulls Docker — sert de signal : l’offensif “agentifié” se démocratise. Le billet appuie aussi sur un autre fait marquant : chez Anthropic, un “Frontier Red Team” d’une quinzaine de personnes, aidé par Claude Opus 4.6, aurait identifié et validé plus de 500 vulnérabilités sévères dans des codebases open source en production, en quelques semaines. Et certaines failles auraient survécu des années, voire plus d’une décennie, dans des projets connus. La conclusion d’OpenNHP est radicale : renforcer les murs ne suffit plus si le château reste repérable et scannable. Ils proposent un basculement vers “Zero Visibility” : pas d’IP exposée, pas de ports ouverts, pas de DNS découvrable avant authentification — l’accès n’est accordé qu’après preuve cryptographique d’identité. Qu’on adhère ou non à la thèse, elle a le mérite de poser une question très concrète : qu’est-ce qu’on laisse volontairement “énumérable” sur Internet, et pourquoi ?

Dans le même registre — sécurité, mais côté défense — Quesma publie BinaryAudit, un benchmark open source assez original : tester si des agents IA savent repérer des backdoors dans de gros exécutables binaires “strippés”, sans code source. Les tâches sont conçues avec Michał “Redford” Kowalczyk de Dragon Sector, et s’appuient sur des programmes open source réels modifiés de manière contrôlée : lighttpd, dnsmasq, Dropbear, Sozu, entre autres. Les agents peuvent utiliser des outils de reverse engineering standards : Ghidra, Radare2, binutils. Et on leur demande souvent plus qu’un simple “oui/non” : il faut aussi donner l’adresse ou la fonction où se cache le code malveillant. Les résultats sont… encourageants mais loin d’être industrialisables. Le meilleur score rapporté tourne autour de la moitié des tâches résolues, avec un problème majeur : trop de faux positifs. Dans un contexte de détection de malware, annoncer une backdoor là où il n’y en a pas, presque un tiers du temps, c’est ingérable — et c’est exactement le piège du “base-rate” : quand les vrais cas sont rares, le moindre faux positif noie le signal. J’ai bien aimé les exemples : sur lighttpd, un modèle repère l’import suspect de popen(), remonte vers une routine “debug header”, et finit par comprendre qu’un header HTTP non documenté déclenche l’exécution de commandes et fuite le résultat dans la réponse. À l’inverse, sur dnsmasq, le modèle voit bien un chemin vers /bin/sh… mais rationalise ça comme légitime et ne vérifie pas correctement si la commande vient de données non fiables, par exemple un paquet DHCP. Moralité : l’IA sait déjà manipuler des outils de reverse, mais la stratégie d’investigation — prioriser les chemins d’entrée, réduire le bruit — reste le vrai goulot.

On quitte la sécurité pure pour parler fiabilité, mais avec un fil rouge : quand on donne des permissions à des agents, il faut vivre avec leurs “décisions”. Le Financial Times rapporte qu’en décembre, Amazon Web Services aurait subi une interruption d’environ 13 heures sur un système, touchant un service AWS dans certaines zones de Chine continentale. L’incident serait lié à Kiro, l’assistant de code IA interne, qui aurait choisi de “supprimer et recréer l’environnement” sur lequel il travaillait. Amazon souligne que l’impact était très limité, et insiste sur la cause humaine : Kiro opérait avec les permissions de son opérateur, et une erreur de configuration lui aurait donné plus d’accès que prévu. D’après l’article, ce ne serait pas un cas isolé : une seconde panne, plus récemment, aurait été associée à un autre outil IA d’Amazon, Q Developer, même si Amazon affirme que celle-ci n’a pas touché un service AWS côté client. Le point intéressant n’est pas de “blâmer l’IA”, mais de regarder l’architecture de contrôle : double validation, scopes, environnements jetables, garde-fous qui empêchent les actions irréversibles, et surtout la capacité à simuler l’impact avant d’exécuter. En clair : traiter les agents comme des opérateurs juniors très rapides… auxquels on ne confie jamais les clés du datacenter par accident.

Autre agent, autre approche : Apple présente Ferret-UI Lite, un “GUI agent” compact, environ 3 milliards de paramètres, pensé pour tourner localement sur l’appareil. L’objectif : comprendre un écran d’application — icônes, petites zones cliquables, texte — et agir au nom de l’utilisateur. Ce qui retient l’attention, c’est la méthode pour compenser la petite taille du modèle. Apple mise sur une stratégie de recadrage et de zoom à l’inférence : le modèle fait une première prédiction, puis recadre autour de la zone d’intérêt et re-prédit, ce qui réduit le coût de traiter une image complète en tokens visuels. Côté entraînement, on parle d’un mix de données réelles et synthétiques, avec fine-tuning supervisé et reinforcement learning. Ils décrivent même une pipeline multi-agents pour générer des données : générateur de tâches progressives, agent de planification, agent d’exécution, puis un critique pour évaluer et capturer les cas “messy” — erreurs, récupération, détours. Apple affirme que Ferret-UI Lite rivalise avec des agents jusqu’à 24 fois plus gros sur certains benchmarks. Il y a une limite assumée : il est bon sur des tâches courtes et concrètes, moins sur des scénarios multi-étapes complexes. Et détail notable : entraînement et évaluation sur Android, web et desktop, via des bancs d’essai reproductibles. Le bénéfice évident : plus de confidentialité, puisque l’UI n’a pas besoin d’être envoyée au cloud.

On parle maintenant de Palantir, mais sous deux angles très différents : la théorie et le terrain. D’abord, côté “idées”, un dépôt GitHub attire l’œil : “palantir-ontology-strategy”, un projet de livre open source porté par Leading.AI-IO, maintenu par Satoshi Yamauchi. Le propos est de vulgariser le concept central de Foundry : l’“Ontology”, présentée non pas comme une technique IT, mais comme une fondation opérationnelle pour décider et faire tourner une organisation. Le projet attaque un problème connu : beaucoup de data lakes et data warehouses finissent en marécages de données — utiles pour regarder et analyser, mais peu connectés à l’action. Leur alternative se résume en trois piliers. Un : la donnée comme “couche opérationnelle” qui reflète la réalité métier, presque un jumeau numérique de l’entreprise. Deux : unifier les “noms et les verbes” — modéliser ensemble les objets (états, sémantique) et les actions (changements, cinétique). Autrement dit, ne pas seulement décrire ce qui est vrai, mais ce qui se passe, et comment ça se transforme. Trois : une gouvernance forte, inspirée du contrôle de version : branches, revue, validation — comme si on appliquait des pratiques de code à la réalité métier modélisée. Le dépôt renvoie vers le texte complet en japonais, avec un README en anglais, et invite aux contributions, notamment corrections et mises à jour sur l’architecture Palantir. Licence Creative Commons CC BY 4.0. Si vous aimez les “livres vivants” sur GitHub, c’est typiquement le format.

Deuxième angle Palantir : l’usage controversé dans la police. Le Guardian rapporte que Scotland Yard — la Metropolitan Police — utilise des outils d’IA fournis par Palantir pour surveiller des comportements internes et aider à repérer des risques de faute professionnelle. Concrètement, analyse de données RH : niveaux d’arrêts maladie, absences, patterns d’heures supplémentaires. La Met explique que ces indicateurs peuvent corréler avec des “défaillances” de standards, de culture ou de comportement, et que la mise en commun de bases internes permettrait de détecter des motifs. Le dispositif est présenté comme un pilote limité dans le temps, et la police insiste : le logiciel ne “juge” pas, il signale des patterns, puis des humains enquêtent et décident. Mais la Police Federation dénonce une “suspicion automatisée”, et pointe un risque très réel : confondre surcharge de travail, maladie ou fatigue avec de la malveillance. Et derrière, il y a un débat politique plus large sur l’empreinte de Palantir dans le secteur public britannique — du contrat NHS à plusieurs centaines de millions jusqu’aux accords défense — et sur la transparence : comme le résume un député libéral-démocrate cité, “qui surveille Palantir ?”.

On termine avec l’angle énergie et infrastructures — parce que l’IA, ce n’est pas que du logiciel. Floodlight publie des images thermiques suggérant que xAI continuerait d’exploiter des turbines au gaz non autorisées pour alimenter un complexe de data centers à Southaven, dans le Mississippi. Le point de friction : les régulateurs locaux les considèrent “mobiles” car posées sur des remorques, donc exemptées de permis ; l’EPA, elle, rappelle que ces sources relèvent normalement de permis au titre du Clean Air Act, et a récemment averti que l’exemption pourrait signifier “aucune norme d’émission du tout”. Les images montreraient plus d’une douzaine de turbines en fonctionnement après la directive de l’EPA. Des experts, dont un ancien responsable de l’application des règles sur l’air, y voient une violation. Des riverains se plaignent de bruit et de qualité de l’air, avec des écoles à moins de deux miles. Le dossier illustre une tendance plus large : de nombreux data centers misent sur le gaz naturel pour aller vite, alors que le raccordement à des renouvelables ou à des capacités réseau suffisantes prend des années. xAI demanderait un permis pour opérer jusqu’à 41 turbines sur le site, avec des estimations d’émissions qui feraient de l’installation un gros acteur fossile local. Le débat n’est pas seulement “IA versus climat” : c’est aussi une question de rythme industriel, de règles, et de ce qu’on accepte comme “temporaire” quand la demande explose.