60 Mo de source maps (ces fichiers qui permettent de remonter du code minifié à l'original) ont été oubliés dans un paquet npm. Et voilà comment Anthropic a involontairement balancé en public le code source complet de Claude Code, son outil à 2.5 milliards de dollars de revenus annuels.

Alors qu'est-ce qui s'est passé exactement ?

Hé bien hier, la version 2.1.88 du package @anthropic-ai/claude-code sur le registre npm embarquait un fichier .map de 59.8 Mo. Un truc normalement réservé au debug interne, sauf que ce fichier .map contenait les pointeurs vers les 1 900 fichiers TypeScript originaux, en clair. Chaofan Shou, un développeur chez Solayer Labs, a alors repéré la boulette et l'a partagée sur X. Le temps qu'Anthropic réagisse, le code était déjà mirroré partout sur GitHub, avec 41 500+ forks en quelques heures. Autant dire que le dentifrice ne rentrera pas dans le tube !

Pour ma part, j'avais un petit dépôt à moi assez ancien avec quelques trucs relatifs à Claude Code, qui n'avait rien à voir avec tout ça, qui s'est même retrouvé striké... Ils ratissent large avec leur DMCA donc.

Et là, c'est la fête pour les curieux comme moi parce que les entrailles de l'outil révèlent pas mal de surprises. Côté architecture, on découvre environ 40 outils internes avec gestion de permissions, un moteur de requêtes de 46 000 lignes de TypeScript, un système multi-agents capable de spawner des essaims de sous-tâches en parallèle, et un pont de communication entre le terminal et votre éditeur VS Code ou JetBrains. Le tout tourne sur Bun (pas Node.js ^^) avec Ink pour l'interface terminal. Par contre, pas de tests unitaires visibles dans le dump.

Côté mémoire, c'est plutôt bien pensé puisqu'au lieu de tout stocker bêtement dans la fenêtre de contexte du modèle, l'outil utilise un fichier texte MEMORY.md ultra-léger (genre 150 caractères par entrée) qui sert d'index de pointeurs. Les vraies données, elles, sont distribuées dans des fichiers thématiques chargés à la demande, et les transcripts bruts ne sont jamais relus entièrement, mais juste fouillés à la recherche d'identifiants précis. L'agent traite en fait sa propre mémoire comme un "hint" ce qui le force à vérifier toujours le vrai code avant d'agir. En gros, il a une mémoire sceptique, et pour moi c'est clairement le truc le plus intéressant du dump.

Y'a aussi un truc qui s'appelle KAIROS (mentionné 150 fois dans le code) qui est un genre de mode daemon autonome. En fait, pendant que vous allez chercher votre café, l'agent tourne en arrière-plan et fait ce qu'ils appellent autoDream : il consolide sa mémoire dans des fichiers JSON, vire les contradictions et transforme les observations vagues en données structurées. Comme ça, quand vous revenez devant votre écran, le contexte est nettoyé.

Et puis le code balance aussi la roadmap interne d'Anthropic (bon courage au service comm ^^). On y trouve les noms de code des modèles... Capybara pour un variant de Claude 4.6, Fennec pour Opus 4.6, et un mystérieux Numbat qui n'est pas encore sorti. D'ailleurs, les commentaires internes révèlent que Capybara v8 a un taux de fausses affirmations qui tourne autour de 30%, ce qui est une grosse régression par rapport aux 17% de la v4. Y'a même un "Undercover Mode" qui permet à l'agent de contribuer à des repos publics sans révéler d'infos internes (c'est sympa pour les projets open source).

Anthropic a confirmé la fuite : "C'était un problème de packaging lié à une erreur humaine, pas une faille de sécurité. Aucune donnée client n'a été exposée." Mouais, attention quand même, parce que le code est déjà partout et n'en repartira pas. Et même si aucun secret client n'a fuité, exposer l'architecture complète d'un agent IA à 2.5 milliards de revenus, c'est pas rien non plus.

Bon, et maintenant qu'est-ce qu'on peut en faire ? Bah pas mal de choses en fait.

Par exemple, le système de mémoire auto-correcteur est un pattern directement réutilisable pour vos propres agents IA. L'architecture "index léger + fichiers à la demande" résout élégamment le problème de la pollution de contexte qui fait halluciner les LLM sur les longues sessions. Les +40 outils internes permettent aussi de comprendre comment structurer un système de permissions granulaires dans un agent autonome . Et le concept KAIROS/autoDream, la consolidation mémoire pendant l'idle, c'est une idée qu'aucun outil open source n'implémente encore. Autant dire que les alternatives open source à Claude Code ou Codex vont monter en gamme dans les jours qui viennent. Et le code est déjà nettoyé, réécris en Rust et mis sur GitHub si vous voulez fouiller. Bon, pas sûr que le pattern autoDream soit simple à reimplémenter, mais le système de mémoire oui.

Je trouve ça assez marrant que le code proprio d'une boite qui a aspiré tout l'open source du monde voire plus, sans autorisation, pour le revendre sous la forme de temps machine / tokens, devienne lui aussi en quelque sorte "open source" sans qu'on leur demande leur avis ^^. La vie est bien faite.

Maintenant, pour les développeurs qui publient sur npm, la leçon est limpide : Vérifiez votre .npmignore et votre champ files dans package.json. Ou plutôt, lancez la commande npm pack --dry-run dans votre terminal avant chaque publish. Ça prend 2 secondes et ça vous montre exactement ce qui sera inclus dans le paquet. Ça aurait évité 60 Mo de secrets industriels qui partent en public.

Bref, un .npmignore bien configuré, ça coûte 0 euro. Alors qu'une fuite de propriété intellectuelle évaluée à 2.5 milliards... un peu plus !

Source

La bibliothèque JavaScript Axios, téléchargée plus de 100 millions de fois par semaine, a été compromise. Un attaquant a détourné le compte du mainteneur principal pour y glisser un malware multiplateforme qui vise aussi bien macOS que Windows et Linux.

Un compte piraté, deux versions vérolées

Tout est parti du compte npm de jasonsaayman, le mainteneur principal d'Axios. L'attaquant a réussi à prendre le contrôle du compte, a changé l'adresse mail vers un ProtonMail anonyme, et a publié deux versions malveillantes : axios 1.14.1 et axios 0.30.4.

Les deux ont été mises en ligne en l'espace de 39 minutes, et pas via le processus habituel. Au lieu de passer par GitHub Actions, le pipeline d'intégration continue du projet, les paquets ont été poussés directement avec la ligne de commande npm. Un détail qui aurait pu alerter plus tôt, mais qui est passé entre les mailles du filet pendant deux à trois heures avant que npm ne retire les versions concernées.

Un malware bien préparé, avec auto-destruction

Le plus vicieux dans l'affaire, c'est la méthode. Plutôt que de modifier directement le code d'Axios, l'attaquant a ajouté une dépendance fantôme appelée plain-crypto-js. Elle n'est jamais importée dans le code source, son seul rôle est d'exécuter un script d'installation qui fonctionne comme un programme d'installation de malware. 

Ce qui veut dire que dès que vous faites un npm install, le script contacte un serveur de commande en moins de deux secondes et télécharge un programme malveillant adapté à votre système : un daemon déguisé sur macOS, un script PowerShell sur Windows, une porte dérobée en Python sur Linux. Et une fois le malware déployé, le script se supprime, remplace son propre fichier de configuration par une version propre, et fait comme si de rien n'était. Même un npm list affiche alors un numéro de version différent pour brouiller les pistes.

Une attaque attribuée à la Corée du Nord

StepSecurity et Socket.dev ont été les premiers à repérer la compromission. Selon Ashish Kurmi, CTO de StepSecurity, ce n'est pas du tout une attaque opportuniste. La dépendance malveillante avait été préparée 18 heures à l'avance, trois programmes malveillants différents étaient prêts pour trois systèmes d'exploitation, et les deux branches de publication ont été touchées en moins de 40 minutes.

Elastic a de son côté relevé que le binaire macOS présente des similitudes avec WAVESHAPER, une porte dérobée en C++ déjà documentée par Mandiant et attribué à un acteur nord-coréen identifié sous le nom UNC1069. Pour les chercheurs en sécurité, le message est clair : si vous avez installé axios 1.14.1 ou axios 0.30.4, considérez votre machine comme compromise. Il faut supprimer la dépendance, faire tourner les identifiants, et dans certains cas, réinstaller la machine.

Franchement, c'est le genre d'attaque qui fait froid dans le dos. Axios, c'est une brique de base pour à peu près tous les projets JavaScript qui font des appels réseau. Et là, en deux heures, un attaquant a réussi à transformer cette brique en porte d'entrée pour un cheval de Troie, y compris sur Mac.

Le plus déroutant, c'est que le système de publication npm permet encore de pousser un paquet manuellement sans que personne ne bronche. Bon par contre, il faut reconnaître que StepSecurity et Socket.dev ont fait du bon boulot en détectant le problème aussi vite.

Sans eux, la fenêtre d'exposition aurait pu être bien plus large, c'est faramineux quand on y pense. Et quand on sait que la piste nord-coréenne revient de plus en plus souvent dans ce genre d'opérations, on se dit que la sécurité de la chaîne logicielle mérite qu'on s'y intéresse de près.

Source : The Register

Des faux entretiens d'embauche avec des repos GitHub vérolés pour piéger les devs Next.js... on croit rêver et pourtant, Microsoft vient de documenter cette campagne ciblée et vous allez voir, c'est violent.

En fait, un groupe de hackers se fait actuellement passer pour des recruteurs et contacte des développeurs JavaScript en leur proposant un entretien technique. Le deal c'est de cloner un repo GitHub pour un "test de compétences"... sauf que le repo en question est truffé de malware.

Microsoft a ainsi identifié plusieurs vecteurs d'infection planqués dans ces repos. Le premier, c'est via les fichiers de configuration VS Code, c'est à dire ceux dans le dossier .vscode/, qui peuvent exécuter du code dès que vous cliquez "Trust" à l'ouverture du projet (ce que la plupart des devs font sans réfléchir).

Le deuxième passe par un npm run dev piégé, la commande de dev classique qui lance le malware en même temps que le serveur (car oui, c'est aussi simple que ça...).

Et le troisième est encore plus sournois puisqu'il s'agit d'un module backend qui décode une URL depuis le fichier .env, exfiltre toutes les variables d'environnement (tokens cloud, clés API...), puis exécute du JavaScript reçu en retour. Sympaaaaaa....

Du coup, le malware est plutôt bien pensé. C'est un loader JavaScript qui se télécharge depuis l'infrastructure Vercel (comme ça, ça a l'air légitime), et qui s'exécute entièrement en mémoire, et spawne un processus Node.js séparé pour ne pas éveiller les soupçons. Une fois installé, il se connecte alors à un serveur C2 qui change d'identifiant régulièrement, histoire de compliquer la détection. Et là, ça se met à exfiltrer tout ce qui traîne... code source, secrets, credentials cloud... bref, tout ce qui a de la valeur.

Alors, comment on se protège de ce genre de menace quand on est un simple dev ? Hé bien déjà, vérifiez le profil du "recruteur". Pas de site d'entreprise vérifiable, des messages génériques... c'est un joli red flag !

Ensuite, avant de lancer quoi que ce soit, lisez le package.json à la recherche de scripts suspects dans preinstall, postinstall ou prepare, inspectez le dossier .vscode/ (surtout tasks.json), et faites un npm install --ignore-scripts pour bloquer l'exécution automatique des hooks. Lancez aussi un safe-npm et un npm audit une fois les dépendances installées. Et côté VS Code, désactivez l'exécution auto des tasks avec "task.allowAutomaticTasks": "off" dans vos settings.

Ça me rappelle les campagnes type Shai-Hulud et les packages npm vérolés , mais avec un vecteur social bien plus élaboré. Le piège, c'est qu'on ne balance plus des packages malveillants dans le registry en espérant qu'un dev les installe par erreur... non, non, on cible directement les développeurs, un par un, en exploitant ce stress de la recherche d'emploi comme le ferait un conseiller France Travail quand vous arrivez en fin de droits chomdu...

Et si vous êtes en pleine recherche d'emploi, attention, ne lancez JAMAIS un projet d'un inconnu dans votre environnement principal. Utilisez une VM, un container Docker (docker run --rm -it -v $(pwd):/app node:20 bash et c'est réglé), ou au minimum un compte utilisateur séparé sans accès à vos tokens et clés SSH. On n'est jamais trop prudent !

Maintenant vous savez... si un recruteur vous envoie un repo GitHub sans profil LinkedIn ni site d'entreprise véritable et vérifiable... c'est que c'est pas un recruteur. Voilà voilà...

Source

Romain, fidèle lecteur de korben.info a développé un scanner pour détecter l’attaque Shai-Hulud qui a secoué l’écosystème npm dernièrement ! L’occasion parfaite pour moi de vous raconter cette histoire complètement dingue.

Vous vous souvenez de CrowdStrike ? Cette entreprise de cybersécurité qui a provoqué la plus grande panne informatique mondiale en juillet 2024 avec une mise à jour défaillante ? Celle qui a cloué au sol des milliers d’avions et fait planter des millions de PC Windows ? Eh bien figurez-vous qu’en septembre 2025, des packages npm mis à disposition par CrowdStrike ont été touchés. Et si Crowdstrike n’a pas été directement piraté, ces packages publics (qui n’étaient pas utilisés dans leurs solutions de sécurité, ni en interne chez eux) utilisaient ces dépendances qui ont été compromises par l’attaque.

C’est ce qu’on appelle une supply chain attack et l’attaque Shai-Hulud (oui, comme le ver des sables dans Dune) n’est pas juste un malware de plus. C’est le premier ver informatique qui s’est propagé de manière autonome dans l’écosystème npm, infectant des centaines de paquets en quelques heures.

Le ver utilise TruffleHog, un outil de sécurité normalement conçu pour DÉTECTER les secrets dans le code, c’est à dire les tokens GitHub, npm, AWS et GCP.

Puis quand il trouve des credentials valides, le ver fait les trois choses suivantes : D’abord, il crée un dépôt GitHub public nommé “Shai-Hulud” où il balance toutes les données volées. Ensuite, il pousse une GitHub Action malicieuse dans tous les repos accessibles pour exfiltrer encore plus de secrets. Et le pompon c’est que parfois, il transforme même les repos privés d’entreprise en repos publics personnels. J’vous laisse imaginer la tête du RSSI qui découvre que tout le code proprio de sa boîte est accessible à tout le monde sur GitHub…

Et quand le ver trouve des tokens npm dans son environnement, il publie automatiquement des versions infectées de tous les paquets auxquels il a accès. C’est d’ailleurs la première fois qu’on voit ce comportement de ver auto-répliquant dans l’écosystème JavaScript. Par exemple, le paquet @ctrl/tinycolor, téléchargé 2 millions de fois par semaine, a été l’un des premiers touchés.

Face à ce bordel monumental, Romain a donc développé npm-shai-hulud-scanner , un outil qui détecte non seulement les paquets connus comme compromis, mais aussi les tentatives de typosquatting et les patterns de code malicieux. Il utilise notamment la distance de Levenshtein pour identifier les variations suspectes de noms de paquets (du genre lodash vs lodash_ ou react vs raect).

Quand vous le lancez, le scanner de Romain vérifie d’abord si vous avez des paquets de la liste des 500+ compromis. Ensuite il analyse votre code à la recherche de patterns suspects : tentatives d’exfiltration de credentials, exécution de code à distance, obfuscation, communications réseau louches. Il peut même tourner en mode monitoring continu pour surveiller votre CI/CD. Et cerise sur le gâteau, il peut mettre en quarantaine les paquets suspects automatiquement. C’est top non ?

Shai-Hulud est l’un des attaques les plus sévères jamais vue sur la supply chain JavaScript et si même CrowdStrike se fait avoir, je me dit que personne n’est à l’abri. Donc soyez hyper vigilants et utilisez des outils de contrôle comme celui de Romain !

On ne sait jamais !

Ça va, pas trop chaud ? Alors tant mieux, parce que je vais vous faire avoir une petite suée tellement ce truc est cool ! Ça s’appelle Memflix et c’est une bibliothèque JavaScript qui transforme vos documents texte en… fichiers vidéo MP4 ! Oui, vous avez bien lu. Et le plus fou, c’est que vous pouvez ensuite faire des recherches sémantiques ultra-rapides dans ces vidéos.

L’idée est tellement simple qu’elle en devient géniale car au lieu de stocker vos données dans une base de données traditionnelle, Memflix encode tout dans des QR codes qui sont ensuite intégrés frame par frame dans une vidéo. Résultat ? Un stockage 10 fois plus efficace qu’une base de données classique et des recherches qui prennent moins d’une seconde, même sur des millions de chunks de texte.