Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.

GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.

L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.

Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.

Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.

Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.

Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.

En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.

Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.

Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.

Source : The Register

Le logiciel qui a piloté la descente du module lunaire Eagle le 20 juillet 1969 dort tranquillement dans un dépôt GitHub que n'importe qui peut cloner, lire, voire compiler chez soi. Deux gros paquets d'assembleur AGC : Comanche055 pour le module de commande, Luminary099 pour le module lunaire. Tout est dans le domaine public, puisque développé par la NASA.

Le dépôt chrislgarry/Apollo-11 existe depuis 2016, mais il faut imaginer ce qu'il y a dedans : des dizaines de milliers de lignes d'assembleur écrites à la main entre 1965 et 1969, assemblées sur les mainframes d'époque, puis gravées physiquement dans de la mémoire tissée, la fameuse rope memory, par des ouvrières chez Raytheon qui cousaient le code à l'aiguille. Oui, cousaient, vous voyez le genre en illustration de cet article, ou la photo ci-dessous signée Martin Hertig .

Le travail de numérisation vient de Paul Fjeld, du MIT Museum et de Ron Burkey, qui dirige le projet Virtual AGC depuis des années. Ils ont scanné et corrigé à la main les listings papier conservés au musée, avant que Chris Garry, stagiaire NASA à l'époque, ne les pousse sur GitHub. Le résultat est 100% assembleur AGC, assemblable via l'outil yaYUL qui tourne sous Linux, macOS, Windows et même FreeBSD.

Les commentaires, surtout, font tout le sel de l'archive. Les équipes de Margaret Hamilton, qui dirigeait la Software Engineering Division au MIT Instrumentation Lab, laissaient des remarques moqueuses au milieu des routines critiques. La plus connue : "BURN BABY BURN -- MASTER IGNITION ROUTINE", juste au-dessus du bloc qui déclenchait la mise à feu. Il y a aussi "TEMPORARY, I HOPE HOPE HOPE", collé sur un patch resté en place pendant toute la mission.

Le passage le plus parlant reste la séquence d'alarmes 1201 et 1202 pendant la descente finale. Un radar de rendez-vous mal positionné saturait le calculateur en pleine approche. Le logiciel écrit par l'équipe Hamilton a fait exactement ce qu'il devait faire : abandonner les tâches non critiques, garder le pilotage actif, et laisser Armstrong se poser. Environ 64 Ko de mémoire et deux kilos de ferrite, gérés en priorité tournante, ont sauvé la mission.

Côté usage concret, cloner le dépôt prend deux secondes. Compiler avec Virtual AGC demande un peu plus de patience, mais ça tourne. Vous pouvez ensuite lancer un simulateur et rejouer la descente touche par touche. Pour les curieux, c'est une archive historique géniale. Pour les étudiants en informatique, c'est un cours d'architecture système qu'aucun manuel ne remplace.

Bref, du code vieux de 57 ans, libre, commenté avec humour, et qui a posé deux humains sur la Lune. Pas mal !

Source : Techspot

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.

Des milliers de faux messages imitant des notifications de sécurité Visual Studio Code ont été postés sur GitHub. Le but : rediriger les développeurs vers un site malveillant qui collecte leurs données système. La méthode est franchement vicieuse.

Une campagne massive sur GitHub Discussions

Les chercheurs en sécurité de Socket viennent de mettre le doigt sur une opération d'ampleur. Des centaines, voire des milliers de messages quasi identiques ont été publiés en quelques minutes sur la section Discussions de nombreux dépôts GitHub.

Chaque message reprend le même modèle : un titre alarmiste du type "Vulnérabilité grave Mise à jour immédiate requise", un faux identifiant CVE pour faire sérieux, et un lien vers une prétendue extension VS Code corrigée hébergée sur Google Drive.

Les comptes utilisés sont soit tout neufs, soit quasi inactifs, mais ils se font passer pour des mainteneurs de projets ou des chercheurs en sécurité. Et comme GitHub envoie des notifications par e-mail aux personnes qui suivent un dépôt ou qui sont taguées, les fausses alertes arrivent directement dans la boîte mail des développeurs. Vous pouvez donc vous faire avoir sans même ouvrir GitHub.

Un système de filtrage avant le malware

Bien sûr, le lien Google Drive ne vous amène pas d'un coup vers un fichier infecté. Il déclenche avant une série de redirections qui vous emmènent inlassablement vers un domaine bien foireux, où un script JavaScript va se charger du sale boulot.

Ce script collecte automatiquement le fuseau horaire, la langue, le système d'exploitation, l'identifiant du navigateur et même des indicateurs d'automatisation. Tout est envoyé vers un serveur de commande sans que vous n'ayez à cliquer sur quoi que ce soit.

L'idée derrière ce dispositif, c'est de trier les visiteurs. Les robots et les chercheurs en sécurité sont écartés, et seuls les vrais humains reçoivent la suite de l'attaque. Les chercheurs de Socket n'ont d'ailleurs pas réussi à capturer le malware de deuxième étape, ce qui montre que le filtrage fonctionne plutôt bien.

Ce n'est pas la première fois

GitHub a déjà été ciblé par ce genre de campagne. En mars 2025, une attaque similaire avait touché 12 000 dépôts avec de fausses alertes de sécurité qui poussaient les développeurs à autoriser une application OAuth malveillante.

Cette fois-là, les pirates obtenaient un accès direct aux comptes GitHub des victimes. En juin 2024, c'était via des commentaires et des demandes de fusion bidon que les attaquants redirigeaient vers des pages d'hameçonnage.

Le procédé est malin. Utiliser les notifications GitHub pour donner une apparence officielle à des messages bidons, c'est le genre d'astuce qui marche bien sur des développeurs pressés. 

Bon par contre, un lien Google Drive dans une alerte de sécurité, ça devrait quand même mettre la puce à l'oreille. Si vous recevez ce type de message, vérifiez toujours le CVE sur le site du NVD ou de MITRE avant de cliquer où que ce soit. Et si le lien pointe ailleurs que sur la boutique officielle de VS Code, passez votre chemin.

Source : Bleeping Computer

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.

À partir du 24 avril, GitHub activera par défaut la collecte des données d'interaction Copilot pour les utilisateurs Free, Pro et Pro+. Le gros sujet ici, c'est que le code, les suggestions acceptées et même la structure de vos dépôts pourront servir à améliorer les modèles d'IA de la plateforme.

Ce qui change à partir du 24 avril

GitHub vient d'annoncer une mise à jour de sa politique de confidentialité qui concerne directement Copilot. À compter du 24 avril 2026, la plateforme collectera par défaut les données d'interaction de ses utilisateurs pour entraîner ses modèles d'intelligence artificielle.

On parle ici des suggestions de code acceptées ou modifiées, des extraits de code envoyés au modèle, du contexte autour du curseur, des commentaires, de la documentation, des noms de fichiers, de la structure des dépôts, et même des retours comme les pouces en l'air ou en bas sur les suggestions.

Mario Rodriguez, le directeur produit de GitHub, assure que cette collecte permettra aux modèles de mieux comprendre les méthodes de développement et de proposer des suggestions de code plus précises et sécurisées.

Qui est concerné

Tous les abonnés Copilot Free, Pro et Pro+ sont concernés par ce changement. Et c'est automatique, pas besoin de cocher quoi que ce soit. Par contre, les comptes Copilot Business et Enterprise échappent à cette collecte, tout comme les étudiants et enseignants qui bénéficient de Copilot Pro gratuitement.

GitHub précise aussi que les utilisateurs qui avaient déjà désactivé le partage de données pour l'amélioration du produit conserveront leur réglage. Pour les autres, c'est l'opt-out qui s'applique, c'est-à-dire que c'est activé par défaut et c'est à vous de faire la démarche pour refuser.

Comment désactiver la collecte

Pour ceux qui ne souhaitent pas que leur code serve à nourrir les modèles de GitHub, la manipulation est assez simple. Il faut se rendre dans les paramètres du compte, section Copilot, puis dans les options de confidentialité.

L'option à désactiver s'appelle "Allow GitHub to use my data for AI model training". GitHub insiste sur le fait que le contenu des dépôts privés n'est pas collecté "au repos", mais attention, si vous utilisez Copilot activement avec le partage activé, vos interactions dans un dépôt privé sont bien concernées.

La tendance est lourde : après Anthropic, JetBrains et Microsoft lui-même, GitHub suit le mouvement et pioche dans les données de ses utilisateurs pour alimenter ses modèles.

Le choix de l'opt-out plutôt que de l'opt-in est quand même un classique américain qui passe toujours un peu mal de ce côté de l'Atlantique. D'ailleurs, sur la page de discussion GitHub, les réactions parlent d'elles-mêmes : 59 pouces vers le bas contre 3 petites fusées.

Difficile de faire plus clair comme signal. Bon par contre, au moins les comptes pro entreprise et les étudiants sont protégés, c'est déjà ça. Reste que pour tous les développeurs indépendants et les contributeurs open source en offre gratuite, c'est un peu l'histoire du produit gratuit dont on finit par être la matière première. Allez, un petit tour dans les paramètres et on n'en parle plus.

Source : Ghacks.net

GitHub vient d'annoncer que les interactions avec l'IA Copilot seront utilisées pour entraîner les modèles IA. Voici comment désactiver la collecte de données.

Le post GitHub va activer par défaut la collecte de données Copilot pour entraîner l’IA a été publié sur IT-Connect.

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.

L'attaque supply chain orchestrée contre Trivy par TeamPCP a été jusqu'à la propagation de malwares sur Docker Hub et le piratage de l'organisation sur GitHub.

Le post L’attaque contre Trivy s’étend jusqu’au Docker Hub : attention aux malwares a été publié sur IT-Connect.

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.

Dans un article publié le 18 février 2026, le média britannique The Register revient sur l'exaspération de nombreux modérateurs open source confrontés au fait de devoir vérifier et corriger des demandes de modification de code boostées par IA. Une gronde qui pousse bon nombre de projets à adopter des mesures de précaution.