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 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.
rsync vient de sortir sa version 3.4.3, un correctif censé boucher plusieurs trous de sécurité. Sauf que pour une partie des utilisateurs, leurs sauvegardes incrémentales se sont mises à mal fonctionner juste après la mise à jour.
En fouillant le code, certains ont remarqué un détail qui ne leur a pas plu. Depuis la version 3.4.1, des dizaines de modifications (des "commits", les unités de changement de code) sont signées "tridge and claude". Comprendre Andrew Tridgell, le créateur historique de rsync, et Claude, l'assistant IA d'Anthropic, le concurrent direct d'OpenAI.
Pour situer, rsync est un outil de synchronisation et de sauvegarde de fichiers qui tourne sur les serveurs Unix et Linux depuis les années 90. Une brique discrète mais utilisée par d'innombrables entreprises, hébergeurs et services informatiques. Quand il déraille, ce sont des sauvegardes entières qui sautent.
D'où la réaction épidermique. Sur GitHub, la plateforme où vit le code source, quelqu'un a ouvert un message au titre sans équivoque, "Please Do Not Vibe Fuck Up This Software". En clair, prière de ne pas bousiller ce logiciel à coups de "vibe coding", cette mode qui consiste à confier des bouts de code à une IA et à faire confiance au résultat sans trop vérifier.
Tridgell a reconnu les régressions. Elles touchent surtout des configurations bien précises, le mode serveur avec l'option chroot désactivée, qu'il décrit comme des "cas d'usage valides mais inhabituels" que la suite de tests du projet ne couvrait tout simplement pas.
Sauf que voilà, il refuse l'étiquette du développeur qui aurait bâclé. "Je n'ai pas juste vibe-codé la conversion de la suite de tests en Python. Je suis un ingénieur logiciel avec 40 ans d'expérience", a-t-il écrit dans un billet intitulé "rsync and outrage".
Concrètement, l'IA a surtout servi à réécrire la vieille batterie de tests, jusque-là en scripts shell, vers le langage Python, pour pouvoir mieux vérifier la sécurité du code. Un travail de fond fastidieux.
Tridgell affirme avoir conçu lui-même l'architecture du nouveau système, utilisé Claude mais aussi Codex d'OpenAI et Gemini de Google pour abattre le gros du débroussaillage répétitif, puis relu et validé chaque ligne produite à la main.
Et il n'a aucune intention d'arrêter. Une version 3.4.4 pourrait corriger les régressions, à moins qu'il ne passe directement à la 3.5, plus ambitieuse côté sécurité. Avec les mêmes outils IA.
Au passage, il rappelle un truc que les mainteneurs de logiciels libres vivent au quotidien, ils croulent sous les signalements de failles de sécurité, dont une bonne partie sont eux-mêmes pondus par des IA. L'IA crée la charge et propose dans la foulée de la résorber.
À l’occasion de sa conférence Build 2026, Microsoft a dévoilé une famille de sept nouveaux modèles d'IA développés en interne. Cette nouvelle gamme s'étend notamment de la génération d'images à la gestion de la voix.
Le 2 juin, Microsoft a réuni les développeurs du monde entier à San Francisco pour sa grande conférence annuelle, la Microsoft Build 2026. Le géant du logiciel a dévoilé ses propres modèles d'IA, les MAI conçus sans OpenAI, son agent autonome Microsoft Scout et le projet Solara, une plateforme pour connecter n'importe quel objet à l'intelligence artificielle. Une keynote qui confirme l'ambition de Microsoft : devenir incontournable dans le monde dominé par l'IA générative.
C'est la Software Freedom Conservancy (SFC), l'ONG américaine qui défend les licences libres, qui a sorti l'affaire. Bambu Lab, l'un des plus gros fabricants d'imprimantes 3D grand public du moment, viole l'AGPLv3 depuis environ quatre ans selon l'organisation. Pas qu'un peu donc.
Pour comprendre l'histoire, il faut savoir que Bambu Studio, le slicer maison de la marque (c'est le logiciel qui transforme un modèle 3D en instructions de découpage pour l'imprimante), est en réalité un dérivé de PrusaSlicer, lui-même basé sur Slic3r.
Les deux sont sous licence AGPLv3, ce qui oblige toute boîte qui distribue un logiciel dérivé à publier son code source dans la même licence. Du coup, Bambu Studio aurait dû suivre les mêmes règles depuis le début.
Sauf que voilà, le SFC pointe deux violations très claires. D'abord, une bibliothèque maison appelée libbambu_networking, qui gère toute la communication entre le slicer et les serveurs cloud de Bambu, n'a jamais vu son code publié. La marque reconnaît même son existence dans son propre README sur GitHub. Pire encore, quand le développeur Paweł Jarczak a sorti une version modifiée d'OrcaSlicer (un fork concurrent, c'est-à-dire une copie communautaire améliorée) qui restaurait certaines fonctions cloud bloquées par Bambu, l'entreprise lui a envoyé une mise en demeure pour faire retirer son projet.
C'est la deuxième violation selon le SFC, parce que l'AGPLv3 interdit explicitement d'ajouter des restrictions supplémentaires à ce que la licence autorise. En clair, Bambu n'a pas le droit d'invoquer ses conditions d'utilisation pour empêcher quelqu'un d'exercer les droits que la licence donne.
Côté riposte, le SFC a lancé un projet baptisé baltobu. Trois objectifs : refaire la fameuse bibliothèque à partir de zéro par reverse-engineering (démonter le code propriétaire pour le réécrire proprement), maintenir le fork OrcaSlicer de Jarczak, et créer un remplaçant complet de Bambu Studio. Une levée de fonds visant 250 007 dollars, ouverte jusqu'au 17 juillet, a déjà atteint son premier objectif pour financer des employés à ce travail sur le long terme. Si la cagnotte va au bout, de nouveaux employés pourront rejoindre le projet.
Bambu Lab a réagi du bout des lèvres. L'entreprise a publié un message reconnaissant que sa référence à des conditions d'utilisation et à une potentielle mise en demeure ait pu être perçue comme une menace légale, ce qu'elle regrette. Pas de modification réelle de la pratique pour autant. La bibliothèque reste fermée, et les pratiques cloud restent les mêmes.
Bref, une marque grand public qui surfe sur les briques open source sans en respecter les règles, ça finit toujours par se voir.
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.
HydroTracker, c'est une app Android open source pour suivre votre consommation d'eau au quotidien. C'est sans pub, ça fonctionne hors-ligne et ça a été mis au point par Ali Cem Çakmak, physicien et développeur passionné !
L'écran d'accueil d'HydroTracker, sobre et lisible
Côté fonctionnalités, vous avez donc le suivi quotidien classique avec objectif personnalisé, des graphiques hebdo, des cartes thermiques mensuelles, le suivi des séries de jours réussis et 3 widgets à mettre sur écran d'accueil.
Par contre, ça marche pas pour suivre votre conso de bière, désolé mes amis Chouffinistes ^^
Et puis surtout, y'a l'intégration Health Connect ce qui permet à HydroTracker de lire et écrire dans la base santé Android partagée par Samsung Health, Google Fit, Fitbit, Garmin ou Strava. Comme ça, toutes vos données sont centralisées !
Alors j'sais pas si vous avez déjà tracké votre consommation d'eau mais la plupart des apps d'hydratation se contentent de compter les verres d'eau. Cem, lui, s'appuie sur le Beverage Hydration Index (y'a une
étude à ce sujet publiée dans l'American Journal of Clinical Nutrition
) et applique des coefficients différents selon les boissons, avec les seuils EFSA pour l'Europe et IOM pour les US. Un verre de lait équivaut par exemple à 1,5 fois sa quantité d'eau, et un soluté de réhydratation orale aussi. C'est logique vu la composition réelle, et pourtant aucune app grand public ne pousse le bouchon aussi loin niveau finesse !
Les analytics d'HydroTracker, façon dashboard scientifique
Et le gros morceau, vous l'aviez deviné, c'est surtout la confidentialité. Prenez par exemple Water Reminder, une app concurrente bien installée sur Android. Hé bien avec elle, vos heures de prise d'eau, votre régularité, votre comportement, tout part chez Google.
Alors que HydroTracker, lui, garde tout en local et la synchro Health Connect reste bien sûr à 100% optionnelle. Bref, si vous tenez à votre
indépendance numérique vis-à-vis des géants américains
, et que vous aimez rester hydraté, c'est l'app idéale !
L'app est sous licence GPL v3, dispo sur le
Play Store
(et bientôt sur F-Droid), ou en APK direct depuis les
releases GitHub
. Par contre, pas de version iOS pour l'instant. Ah et j'oubliais, les notifications de l'app s'adaptent à votre cycle de sommeil, donc elle ne vous harcelera pas la nuit. C'est con dit comme ça, mais peu d'apps le font.
Voilà, si vous voulez creuser le code, c'est sur
GitHub
et Cem a même sa page perso sur
cmckmk.com
.
Le piratage du jour vient d'être confirmé par la plateforme qui héberge une bonne moitié du code de la tech mondiale ! En effet, Github a subi un accès non autorisé à ses propres dépôts internes, à cause d'une
extension VS Code piégée
installée sur l'ordi d'un employé !
L'annonce officielle est tombée sur le compte X de l'entreprise à l'instant et c'est comme ça que je suis tombé dessus.
GitHub dit avoir détecté et maîtrisé la compromission hier. L'extension VS Code malveillante a été retirée, le poste de travail isolé, et la rotation des secrets critiques est en cours. Côté impact, le message officiel c'est que "À l'heure actuelle, nous ne disposons d'aucune indication laissant supposer que les informations des clients stockées en dehors des référentiels internes de GitHub aient été compromises".
Du coup, nos repos perso, nos orgs, nos enterprises...etc, rien n'est normalement touché à ce stade, en tout cas selon ce que GitHub voit pour l'instant.
Le thread officiel de GitHub sur l'incident
Sauf que sur le darkweb, un acteur baptisé TeamPCP, repéré par le compte de threat intel Dark Web Informer, prétend détenir et vendre environ 4000 dépôts privés volés à GitHub. L'entreprise n'a pas publié de chiffre officiel mais a reconnu que la revendication était cohérente avec son enquête en cours, le rapport complet arrivera une fois bouclé.
Bref, à prendre au sérieux mais avec des pincettes le temps que ça se vérifie !
C'est vrai qu'en ce moment, on est dans une vague d'attaques supply chain qui
ciblent les extensions VS Code
, qui sont devenues un vrai vecteur d'attaque reconnu. Et tout le monde peut se faire piéger (même les ingés GitHub !).
Donc pour vous qui me lisez, la règle de base reste la même : Installez une extension VS Code uniquement si vous faites confiance à l'éditeur. En pratique, faut regarder le tag publisher verified, l'âge du compte, le nombre d'installs et la date de la dernière release, et surtout méfiez-vous des forks fraîchement republiés sous des noms qui ressemblent à un outil connu.
Pour suivre ça maintenant, le thread officiel et ses mises à jour sont sur le
compte X de GitHub
.
Vous vous souvenez de l'encoche des MacBook Pro et autres Air d'Apple ? Mais siiii, celle qu'on avait tous trouvée bien moche en 2022, au point que je vous avais pondu
un article entier pour la faire disparaître
! Hé bien 4 ans plus tard, sk-ruban a décidé de lui donner une vraie utilité avec
notchi
qui transforme proprement cette encoche maudite en un compagnon fait de pixel-art et d'amour qui réagit en temps réel à votre Claude Code.
La boucle est bouclée, mes amis !
Une fois installée, l'app détecte les événements de votre session Claude Code via les
hooks officiels
car ce sont eux qui balancent les "events" sur un socket Unix local qui sont ensuite parsés en temps réel afin d'animer les sprites logés dans le creux de votre encoche.
Cette mascotte a cinq états bien distincts. Elle se balade en mode idle quand vous bricolez à côté, elle s'agite quand Claude réfléchit, elle pique un roupillon en cas de pause prolongée, elle se concentre quand le contexte se compacte, et elle vous fait les gros yeux quand l'IA attend une validation.
Ça bosse fort !
Un clic sur l'encoche et le panneau s'étend pour afficher le feed des événements, votre temps de session, et le quota d'usage restant.
L'option d'analyse de sentiment est également très sympa. Si vous lui fournissez une clé API Anthropic, l'app analysera alors vos prompts pour faire varier l'humeur de la mascotte entre joyeux, triste, neutre ou pleurnichard. À noter quand même que chaque prompt déclenche un appel API facturé sur votre compte Anthropic, donc à activer en conscience si vous bombardez Claude toute la journée et que vous êtes pété de thunes. Ce dont je ne doute pas un instant !!
Les options de Notchi
Et pour ceux qui jonglent avec plusieurs instances de Claude Code, les sessions concurrentes sont également supportées avec un sprite individuel par session, histoire d'éviter la confusion quand vous lancez 3 agents en parallèle.
Sk-ruban s'est inspiré de Claude Island et Readout (deux autres projets qui détournent l'encoche), et les sprites sont dessinés sur Aseprite. C'est un peu dans le même esprit que
Peon Ping
qui balance des sons de Warcraft à chaque action de votre agent, mais avec un aspect visuel ludique plutôt que sonore. Il y a même déjà
un portage Windows
réalisé par AptatoX pour ceux qui ne sont pas sur Mac.
Au niveau prérequis, comptez macOS 15 Sequoia minimum et un MacBook avec une vraie encoche, ce qui exclut les MacBook Air sans notch et les MBP d'avant la refonte 14/16 pouces. Le projet est sous licence GPL-3.0 et l'install se fait par Homebrew avec brew install --cask notchi, ou en DMG direct depuis les releases.
Et un grand merci à
Camille Roux
pour le partage !
Branislav Đalić, un dev serbe basé à Belgrade, vient de balancer un projet plutôt original baptisé
GitLike
. Il s'agit d'un GitHub décentralisé qui stocke vos repos sur
IPFS
et remplace le mot de passe par votre clé Ethereum (votre wallet quoi...).
Vous connectez votre wallet via SIWE (le standard EIP-4361, signature dans MetaMask ou WalletConnect), vous créez un repo, et hop, chaque commit, chaque fichier, chaque arbre devient un objet IPFS adressé par son CID. Tout pareil que Git côté usage, sauf que derrière y'a pas de serveur GitHub mais un simple Worker Cloudflare qui orchestre Pinata ou Filebase pour pinner vos données.
Côté install, la doc propose tout simplement de faire un npm install -g gitlike avec ensuite l'utiliser avec les commandes Git habituelles (init, clone, push, pull, branch), sauf que le package n'est pas encore publié sur npm public pour l'instant. Du coup, faudra patienter ou aller chercher le code directement dans le repo GitHub si vous voulez bricoler dès aujourd'hui.
La doc officielle mais l'install npm marche pas.
L'architecture tient en 3 étages bien séparés. Votre navigateur s'occupe de l'interface et de la signature avec le wallet, un petit serveur Cloudflare joue les videurs en backend (qui a le droit d'écrire, dans quel ordre, à quelle vitesse), et IPFS stocke tout le code en mode décentralisé via Pinata ou Filebase.
Et si vos repos doivent rester privés, vous pouvez activer un chiffrement qui se fait directement dans votre navigateur, comme ça personne d'autre ne lit vos fichiers en clair. En gros, votre onglet de navigateur fait office de vitrine, le Worker joue le mec de la sécu, et IPFS sert de coffre-fort distribué.
Le truc cool, c'est que GitLike peut importer votre code directement depuis GitHub ou GitLab, donc migrer un projet existant ne prend que quelques clics ! Et vous retrouvez tout le confort moderne, à savoir les pull requests avec gestion des conflits, des règles de protection sur les branches sensibles, et même un système pour déléguer l'écriture à un agent IA avec un périmètre limité dans le temps et l'espace (genre, commit uniquement sur telle branche, et seulement pendant 24h).
Sympa, donc, pour vibe coder avec un agent 100% autonome sans pour autant lui filer toutes vos clés et qu'il ne détruise tout dans une apocalypse nucléaire (Quoi, j'en fais trop ?)
Après même si l'idée semble sympa, je trouve que ça déplace le risque plutôt que de le faire disparaître. Parce que si vous paumez votre wallet, vous perdez l'accès en écriture (et possiblement en lecture si c'est chiffré) à tous vos repos, et y'a plus qu'à recommencer. Donc sauvegarder votre seed phrase (les 12 ou 24 mots de récupération du wallet, vous savez) est donc critique !
Côté concurrence, vous trouverez également
Radicle
qui fonctionne en peer-to-peer pur (mais demande un daemon local) ou l'ancien Mango (Ethereum + IPFS, mais plus trop maintenu). GitLike, lui, mise tout sur le navigateur et votre wallet, donc c'est plus simple !
Après c'est jeune et faut voir ça plus comme un proof of concept solide qu'un GitHub-killer. Mais ça tient bien la route et je trouve l'idée d'un Git contrôlé par un wallet ethereum plutôt classe. C'est peut-être ça le vrai web3 ;)))
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.
Une simple commande git push pour compromettre un serveur ? C'est possible grâce à la faille CVE-2026-3854 qui affecte GitHub.com et GitHub Enterprise Server.
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.
Depuis quelques jours, un outil open-source retient l’attention sur les réseaux sociaux. Son nom : Scrapling. Piloté par des agents IA OpenClaw, il serait capable de contourner toutes les protections anti-scraping du web. Alors, nouvelle crainte disproportionnée ? Cloudflare, en tout cas, prend le sujet très au sérieux.