Archives par mot-clé : GitHub

Cybersécurité, Entreprise, Espionnage Spy, Linux, Mise à jour, Securite informatique, Social engineering

ChocoPoC cible les chercheurs en vulnérabilités

18 août 2026 Damien Bancal

Des chercheurs français en cybersécurité ont identifié une campagne sophistiquée utilisant de faux exploits CVE pour infecter les environnements des pentesters avec un cheval de Troie Python.

Une enquête menée par YesWeHack et Sekoia révèle une attaque de chaîne d’approvisionnement visant directement les chercheurs en vulnérabilités. Depuis fin 2025, des acteurs malveillants diffusent de faux dépôts GitHub proposant des preuves de concept pour des failles critiques. Sept dépôts piégés ont été identifiés. Leur installation déclenche des dépendances Python malveillantes capables de déployer ChocoPoC, un RAT conçu pour voler des fichiers, récupérer des identifiants et exécuter des commandes.

Des exploits CVE transformés en pièges

L’affaire débute le 25 juin 2026. Après la publication d’un modèle Nuclei consacré à Joomla JCE, l’équipe de YesWeHack reçoit une suggestion concernant deux preuves de concept associées à une vulnérabilité critique Joomla. L’un des dépôts, consacré à CVE-2026-48908, attire rapidement l’attention.

Son fichier de dépendances réclame un paquet Python inconnu nommé « frint ». Celui-ci installe à son tour « skytext », publié récemment sur PyPI. Le paquet se présente comme une bibliothèque destinée à produire rapidement des couleurs dans un terminal. Son contenu réel est beaucoup moins décoratif.

Skytext distribue des extensions compilées pour Linux et Windows. L’analyse de la version Windows révèle du code obfusqué, une exploration du Process Environment Block, des fonctions résolues dynamiquement et plusieurs blocs chiffrés. Le programme vérifie également son environnement avant d’exécuter son activité malveillante.

Cette précaution complique fortement l’analyse automatisée. Le code recherche notamment la présence d’un fichier portant un nom précis, comme « EXPLOIT_POC.py ». Sans ce contexte, aucune charge utile ne se déclenche. Un échantillon isolé dans un bac à sable peut ainsi sembler inoffensif.

Lorsque les conditions attendues sont réunies, l’extension déchiffre plusieurs composants et modifie l’environnement Python. Elle installe une version détournée du paquet _distutils_hack ainsi que des fichiers .pth. Ces éléments sont ensuite chargés lors du démarrage d’un nouvel interpréteur Python.

Cette persistance permet de lancer choco.py, le téléchargeur intermédiaire de ChocoPoC. Celui-ci récupère une nouvelle charge utile grâce à un jeu de données hébergé chez Mapbox. Les requêtes DNS peuvent passer par DNS-over-HTTPS, notamment via AliDNS ou Cloudflare, afin de contourner certains mécanismes locaux de filtrage.

Le trafic conserve par ailleurs l’apparence d’une connexion légitime vers l’API Mapbox. Cette infrastructure sert de point mort pour récupérer le RAT et échanger des informations, réduisant la visibilité du canal de commande.

Une campagne pensée pour les outils offensifs

Le dernier étage de l’infection est un RAT (logiciel espion) écrit en Python. ChocoPoC peut collecter des données issues de Chrome, Brave, Edge et Firefox, notamment les mots de passe, cookies, historiques et informations de remplissage automatique.

Il recherche également certains fichiers locaux, des bases de données, des historiques de commandes shell, des informations réseau et la liste des processus actifs. L’opérateur peut lancer des commandes système, exécuter dynamiquement du code Python, récupérer des fichiers ou modifier la fréquence des communications avec le serveur de contrôle.

L’enquête a permis d’identifier au moins sept dépôts GitHub malveillants associés à des vulnérabilités très médiatisées. Les leurres visaient notamment FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Checkpoint VPN et Joomla SP Page Builder.

Deux chaînes de dépendances apparaissent. En 2025, plusieurs dépôts utilisaient les paquets « slogsec » et « logcrypt.cryptography ». En 2026, les opérateurs ont privilégié « frint » et « skytext ». Malgré ces changements, YesWeHack et Sekoia relèvent plusieurs caractéristiques communes, dont le même identifiant de fonctionnalité Mapbox, des contrôles environnementaux similaires et des mécanismes identiques contre les relances récursives.

Ces éléments conduisent les chercheurs à attribuer avec une forte confiance les deux périodes d’activité au même acteur. Selon leur analyse, l’opérateur aurait régulièrement changé de comptes GitHub, PyPI et Mapbox pour limiter les blocages et compliquer le suivi de son infrastructure.

Les adresses électroniques utilisées pour certaines publications semblent également liées à des comptes compromis. Des identifiants concernant deux des quatre adresses étudiées figuraient dans des bases de données de fuites, dont l’une probablement issue d’une infection par infostealer.

Les statistiques de téléchargement renforcent l’inquiétude sans démontrer, à elles seules, une compromission. Le paquet skytext aurait enregistré environ 2 400 téléchargements sur Linux et Windows, avec une majorité sous Linux. Plusieurs hausses coïncident avec la divulgation ou l’exploitation publique de vulnérabilités importantes.

Le risque dépasse donc la seule machine d’un chercheur. Un pentester compromis peut manipuler des identifiants clients, des rapports confidentiels, des données techniques sensibles ou des informations concernant des systèmes vulnérables.

ChocoPoC illustre ainsi une évolution préoccupante du renseignement cyber : le code visible peut rester crédible tandis que l’infection se déplace vers les dépendances, transformant l’urgence autour des nouvelles CVE en véritable surface d’attaque.

Cybersécurité, Entreprise

OpenAI lance Aardvark, un agent IA dédié à la chasse aux failles

6 novembre 2025 Damien Bancal

OpenAI dévoile Aardvark, un agent GPT-5 autonome capable d’analyser le code, détecter les failles et suggérer des correctifs, marquant son entrée dans la cybersécurité.

OpenAI a lancé Aardvark, un agent d’intelligence artificielle fondé sur GPT-5 et destiné aux équipes de sécurité. L’outil scanne les dépôts de code, identifie les vulnérabilités, reproduit les exploitations en environnement isolé et propose des correctifs vérifiés. Intégré à GitHub, il fonctionne sur les projets open source comme en entreprise. D’après les tests internes, Aardvark détecte 92 % des vulnérabilités connues. OpenAI prévoit aussi des analyses gratuites pour certains dépôts publics afin de renforcer la sécurité de la chaîne logicielle. Le programme reste en bêta fermée, accessible sur demande via un formulaire d’inscription disponible sur le site d’OpenAI.

Un nouvel acteur dans la cybersécurité

Jusqu’ici concentrée sur les modèles de langage, OpenAI s’ouvre à la cybersécurité avec Aardvark, présenté comme une « avancée majeure dans la recherche en IA et en sécurité ». Cet agent agit comme un chercheur automatisé capable d’examiner des dépôts entiers et de construire un modèle de menace contextuel. Il s’intègre nativement à GitHub et s’adapte aux environnements d’entreprise comme aux projets open source.

Aardvark fonctionne en quatre étapes : cartographie des risques, analyse des commits, reproduction d’exploitations en sandbox et élaboration de correctifs via le moteur Codex d’OpenAI. Chaque rapport est soumis à validation humaine avant tout déploiement. Ce modèle hybride garantit rapidité et fiabilité, tout en maintenant la supervision humaine au cœur du processus de correction.

Résultats prometteurs et concurrence émergente

Les tests internes d’OpenAI indiquent une détection de 92 % des vulnérabilités connues et synthétiques. En pratique, Aardvark a découvert plusieurs failles inédites dans des projets open source, certaines déjà enregistrées sous identifiant CVE. Ce positionnement s’inscrit dans une stratégie de contribution à la sécurité numérique mondiale. L’entreprise offrira gratuitement des analyses à des dépôts non commerciaux pour renforcer la sécurité de la chaîne logicielle libre. Ce que propose OpenAI avec Aardvark rappelle CodeMender de Google, un outil concurrent capable de détecter et corriger automatiquement des vulnérabilités dans le code. Aucune date de sortie officielle n’a été communiquée, mais l’accès à la version bêta peut être demandé via le formulaire disponible sur le site d’OpenAI.

Cybersécurité, Mise à jour, Patch

Microsoft publie enfin le code source historique de BASIC 6502

8 septembre 2025 Damien Bancal

Après des décennies de rumeurs et de copies non officielles, Microsoft ouvre le code source de son BASIC pour processeur MOS 6502, pierre angulaire de l’informatique personnelle.

Microsoft a mis en accès libre le code source de son interpréteur BASIC pour processeur MOS 6502. Longtemps resté dans l’ombre, accessible uniquement via des fuites ou des archives, il est désormais disponible sous licence MIT. Ce langage, porté en 1976 et adopté dès 1977 par Commodore pour ses ordinateurs PET, VIC-20 et Commodore 64, a contribué à démocratiser l’informatique personnelle. Le dépôt GitHub publié par Microsoft inclut près de 7 000 lignes d’assembleur, des notes historiques et des commits rétrodatés. Ce geste éclaire les origines de l’entreprise et la centralité du BASIC dans son modèle économique initial, tout en offrant à la communauté un patrimoine technologique à explorer et réinventer.

Un langage fondateur libéré

Microsoft a publié le code source de la version 1.1 de son BASIC pour le processeur MOS 6502, une première dans l’histoire de l’entreprise. Écrit en assembleur, le fichier compte 6 955 lignes et reprend les améliorations proposées par l’ingénieur de Commodore John Feagans, ainsi que par Bill Gates lui-même, en 1978. Cette mouture correspond à ce que les utilisateurs des Commodore PET connaissaient sous l’appellation BASIC V2. Jusqu’à présent, il n’existait qu’à travers des copies non officielles, des disquettes de musée ou des projets de rétro-ingénierie.

Le dépôt GitHub mis en ligne sous licence MIT autorise une réutilisation sans restriction, y compris commerciale. Microsoft y a ajouté des commits artificiellement datés d’« il y a 48 ans » et des notes explicatives retraçant l’évolution du langage. L’entreprise redonne ainsi vie à un élément clé de son ADN technologique.

Du prototype Altair aux millions de Commodore

Le premier BASIC de Microsoft a été conçu en 1975 pour l’Altair 8800, un ordinateur équipé du processeur Intel 8080. Ce travail fondateur a été réalisé par Bill Gates et Paul Allen. Dès 1976, avec l’aide de Rick Weiland, le langage est porté sur le MOS 6502, un processeur qui allait s’imposer dans l’histoire de l’informatique.

En 1977, Commodore obtient une licence pour 25 000 $ (≈ 23 000 €). Le BASIC est alors intégré aux PET, puis aux VIC-20 et Commodore 64. Ces deux derniers modèles atteignent des ventes de masse, propulsant le langage et l’entreprise américaine sur le devant de la scène. La stratégie de licences de Microsoft trouve là son premier socle économique solide, bien avant l’ère MS-DOS et Windows.

Le code révèle également une attention extrême portée à l’efficacité mémoire. Sur des systèmes 8 bits limités, la gestion des chaînes, l’arithmétique en virgule flottante et le ramasse-miettes représentaient des défis techniques cruciaux. Des « Easter Eggs » signés Bill Gates, dissimulés dans certaines étiquettes du code (STORDO, STORD0), attestent d’une pratique déjà courante de signatures cachées dans les logiciels.

Le processeur MOS 6502 a équipé des machines devenues emblématiques : Apple II, consoles Atari 2600, Nintendo NES et toute la gamme Commodore. Sa simplicité d’architecture et son faible coût l’ont rendu incontournable. Ce processeur reste un symbole pour les passionnés qui continuent à le reproduire en FPGA, à créer des émulateurs et à imaginer de nouvelles éditions de machines historiques comme le Commodore 64.

Le geste de Microsoft s’inscrit dans cette dynamique patrimoniale. En mettant à disposition ce code, l’entreprise offre à la communauté non seulement une ressource technique, mais aussi une pièce d’histoire. L’initiative résonne avec l’engouement croissant pour l’archéologie numérique et les expérimentations rétro-informatiques.

BASIC a façonné l’accès à l’informatique personnelle : du curseur clignotant sur l’écran d’un Commodore aux projets de réédition en 2025, son empreinte reste intacte. La publication du code sous licence libre garantit sa transmission et son adaptation, loin des contraintes propriétaires d’autrefois.

La mise en ligne du BASIC 6502 dépasse l’acte symbolique. Elle rappelle comment un langage compact et efficace a façonné l’économie et la culture de Microsoft. Elle pose aussi une question contemporaine : dans un monde dominé par les logiciels propriétaires et les plateformes fermées, quelle place reste-t-il pour la transmission libre des codes fondateurs ?

Cybersécurité, IA

Mode YOLO de lIA Cursor : de graves failles découvertes

22 juillet 2025 Damien Bancal

Révélation sur le mode YOLO du nouvel outil d’intelligence artificielle Cursor. Il comporte plusieurs failles de sécurité majeures, permettant de contourner aisément les mécanismes de protection censés limiter les actions automatisées du programme.

Rejoignez-nous sur les réseaux sociaux

Aucun spam – Désinscription en un clic – Vie privée respectée

Risques concrets liés à l’automatisation avancée du mode YOLO

Le mode YOLO (« you only live once ») de l’outil Cursor permet à l’agent d’exécuter automatiquement des séquences d’actions complexes sans validation systématique par l’utilisateur. Selon la documentation officielle de Cursor, ce mode serait encadré par des garde-fous tels qu’une liste de commandes autorisées, une liste noire de commandes interdites, et une option spécifique pour empêcher la suppression de fichiers. Ce dispositif vise à rassurer les développeurs sur la sécurité de l’automatisation dans les processus de programmation.

« La suppression automatique de fichiers et l’exécution de commandes arbitraires deviennent possibles, malgré les filtres intégrés. »

Cependant, une analyse conduite par Backslash Security a démontré que ces mesures ne résistent pas à des tentatives délibérées de contournement. Les experts en cybersécurité ont identifié quatre techniques principales permettant de déjouer les restrictions imposées par Cursor. Les agents IA peuvent notamment recourir à l’obfuscation du code, exécuter des commandes à travers une sous-couche shell (« subshell »), écrire des scripts sur le disque avant de les lancer, ou encore utiliser des manipulations sophistiquées de guillemets dans bash afin d’échapper aux blocages attendus.

Ces méthodes contournent ainsi facilement les listes noires de commandes. Par exemple, même si la commande « curl » est ajoutée à la liste des interdictions, Cursor peut l’exécuter si elle est chiffrée en Base64 ou intégrée dans une autre commande shell. La protection affichée par l’éditeur apparaît alors comme largement inefficace dans la pratique.

⏳ Jusqu’où tolérerez-vous d’être piraté ?

CTI ZATAZ – Scannez les menaces vous concernant avant qu’il ne soit trop tard.

✅ Scanner mes risques

Confidentiel. Instantané. Sécurisé. Zéro intermédiaire. 100 % Made in France.

Les faiblesses structurelles du système de sécurité de Cursor

La possibilité de contourner les garde-fous a des conséquences directes pour les développeurs. En important des instructions ou des modèles d’agents issus de dépôts publics tels que GitHub, il devient possible d’introduire des comportements malveillants dans l’environnement Cursor. Ce risque ne se limite pas aux fichiers exécutables ou scripts manifestes. Un simple commentaire ou un extrait de texte placé dans le README d’un projet peut constituer un vecteur d’attaque si l’agent IA l’interprète et l’exécute sans contrôle supplémentaire.

Par ailleurs, la fonctionnalité censée empêcher l’effacement de fichiers s’avère elle aussi inefficace dès lors que les autres couches de protection sont contournées. Selon le rapport publié, aucune option dans le paramétrage du mode YOLO ne saurait garantir l’intégrité du système si un agent acquiert la capacité de lancer un code malveillant. Les filtres actuels ne constituent donc qu’une barrière symbolique.

Cursor n’a pas fourni de commentaire officiel concernant ces découvertes au moment de la publication de l’enquête. Toutefois l’éditeur prévoit d’abandonner le mécanisme de liste noire jugé inefficace dans la prochaine version majeure 1.3, encore non déployée à ce jour. Ce changement d’approche vise à combler les lacunes structurelles de la solution actuelle, sans qu’aucun détail précis n’ait été communiqué quant aux nouveaux dispositifs de sécurité envisagés.

Tant que les mécanismes de validation ne seront pas revus en profondeur, la seule protection efficace consiste à éviter l’activation de l’exécution automatique pour les tâches critiques, et à vérifier systématiquement l’intégrité des instructions importées depuis des sources tierces. (BS)