Autoblog de korben.info

Si vous avez installé Bitwarden CLI via npm entre 17h57 et 19h30 PM (heure de New York) ce 22 avril, faut faire le ménage sur votre machine de toute urgence !! En effet, le package @bitwarden/cli version 2026.4.0 a été compromis durant 93 minutes, et le malware qui s'y trouvait a fait des dégâts chez les 334 personnes qui l'ont téléchargé pendant cette fenêtre.

Mais alors c'est quoi cette histoire encore ?

Hé bien des attaquants ont réussi à piéger le pipeline GitHub Actions de Bitwarden, à y injecter un fichier bw1.js dans le package npm officiel, et à le publier sans qu'aucune alerte ne parte. Jusqu'à ce que l'équipe sécurité de Bitwarden capte le truc et retire le package une heure et demie plus tard.

Et y'a un truc qui fait tiquer dans cette histoire, c'est que le malware s'annonce fièrement comme "Shai-Hulud: The Third Coming". En fait c'est la troisième vague d'une campagne npm qu'on avait déjà croisée en septembre 2025 . Et les attaquants restent cohérents dans leur branding puisque les dépôts publics qu'ils créent chez les victimes portent des noms issu de Dune comme atreides, fremen, sardaukar ou harkonnen. Donc sachez le, si vous voyez ça apparaître sur votre GitHub, vous êtes cuit !

Le payload, lui, est propre dans son approche crasseuse, selon l'analyse de Socket . Il chope tout ce qui traîne sur votre machine : tokens GitHub (ghp_*), tokens npm, credentials AWS dans ~/.aws, tokens Azure, SSH keys, fichiers .npmrc, configs Claude et MCP.

Puis il chiffre le tout en AES-256-GCM avec une clé RSA éphémère, balance le paquet vers audit.checkmarx[.]cx/v1/telemetry (un domaine qui imite Checkmarx pour brouiller les pistes), puis injecte une backdoor dans vos .bashrc et .zshrc. Ah et le malware vérifie également votre localisation système et se barre en silence sans faire de dégâts si elle commence par "ru". Ohhh comme c'est bizarre ^^.

Bref, si vous êtes concerné, voici la liste des trucs à faire dans l'ordre :

• npm uninstall -g @bitwarden/cli puis npm cache clean --force
• Rotation complète de vos secrets : tokens GitHub, tokens npm, credentials AWS/Azure/GCP, clés SSH
• Vérifiez vos repos GitHub pour des créations suspectes avec des noms Dune
• Cherchez "LongLiveTheResistanceAgainstMachines" dans vos commits (c'est leur marker d'exfiltration)
• Virez les modifications suspectes dans vos ~/.bashrc et ~/.zshrc
• Installez la version 2026.4.1 qui est propre

Faut bien le reconnaître, Bitwarden a été hyper réactif dans cette histoire. Détection en interne, mise en quarantaine en 93 minutes, communication claire, et CVE émis dans la foulée. Et heureusement, aucune donnée utilisateur n'a fuité vu que les vaults restent chiffrés côté client de toute façon, et que seuls les développeurs qui ont installé le CLI pendant ce créneau sont touchés. Les extensions navigateur, l'app desktop, mobile, le package snap, rien de tout ça n'a bougé.

Mais ça reste quand même la preuve que npm est devenu LE cauchemar de la supply chain moderne. Après Axios le mois dernier et la campagne Shai-Hulud de septembre, on en est au point où chaque package JS avec un script d'install équivaut à une bonne vieille roulette russe. Donc si vous bossez dans un environnement CI/CD, soyez vigilant et jetez aussi un oeil à safe-npm pour mettre un peu de paranoïa automatisée dans votre workflow quotidien.

Voilà, si vous avez installé Bitwarden CLI avant-hier soir via npm, vous avez du boulot. Sinon, respirez car Bitwarden a tenu bon !

Source

Les bannières cookies, franchement, plus personne à part quelques no-life ne les lisent. On clique tous sur "Accepter tout" par flemme et on sait tous pertinemment que nous venons de nous "auto-tracker" comme des débilos. Mais heureusement, y'a une extension Firefox qui fait le refus automatique à votre place, et qui envoie même un signal légal pour dire "non merci" aux sites qui jouent le jeu.

Cette extension s'appelle Auto Reject Cookies , elle est open source sous licence MIT,et se fait rapidement oubliée une fois installée sur Firefox (Desktop ou Android).

Ensuite, son boulot, elle le fait en arrière-plan : Quand une bannière de consentement apparaît, elle cherche le bouton "Reject All" et clique dessus toute seule. Pour les bannières en deux étapes (celles qui cachent le "tout refuser" derrière un bouton "Paramètres" bien planqué), elle va aussi chercher plus loin.

Et le truc chouette, c'est que cette extension supporte +25 plateformes de gestion du consentement (OneTrust, CookieBot, Sourcepoint, Didomi et compagnie) et reconnaît les boutons en plus de 10 langues, français inclus. Et pour parfaire le tout, une coche verte s'affiche quand un rejet a réussi, histoire que vous sachiez qu'elle a fait le job.

J'ai testé sur Le Monde, Reddit, HackerNews, GitHub et quelques gros sites US, c'est 95% de réussite direct. Sur les sites avec des CMP ultra-customs par contre (genre un vieux forum fais maison ou un dashboard d'entreprise à la con), ça rate parfois et faut cliquer à la main. Rien de grave hein, le web est tellement varié, ça peut pas taper dans le mille à tous les coups.

Et si y'a un site où vous avez besoin des cookies (votre banque, votre boulot, le site de votre prof de lancer de hâches), vous le mettez en liste blanche et c'est réglé.

Et le vrai atout de ce logiciel, c'est surtout le signal GPC (Global Privacy Control) que l'extension envoie avant chaque chargement de page. Elle injecte l'en-tête "Sec-GPC: 1" et définit le paramètre "navigator.globalPrivacyControl" dans le navigateur. En gros, ça dit aux sites : "cet utilisateur ne veut pas que ses données soient vendues". Et si le site respecte cette règle, vous êtes OK.

En France on est sur du RGPD/ePrivacy donc le signal GPC n'a pas (encore) de poids légal, mais l'extension l'envoie quand même, et vu la direction que prend la CNIL sur le tracking, ça coûte rien d'être en avance.

La différence avec Consent-O-Matic (que j'avais déjà abordé l'an dernier), c'est le scope. Consent-O-Matic supporte +200 CMPs et propose des profils de préférences personnalisés alors que Auto Reject Cookies est moins large mais ajoute le GPC systématique et reste sur un refus total par défaut.

Niveau permissions, l'extension demande l'accès aux onglets et aux données de tous les sites web (normal, vu qu'elle doit intercepter les bannières partout), mais le développeur mouth_brood indique que rien n'est collecté. Et comme c'est du MIT, le code est dispo sur GitHub si vous voulez vérifier.

Bref, à tester !

Dans son document S-1 déposé à la SEC en vue de son entrée en Bourse, SpaceX liste la fabrication de ses propres GPU parmi ses dépenses en capital en cours. Reuters a repéré l'extrait, qui fait partie des postes identifiés comme substantiels par l'entreprise, même si aucun chiffre précis n'est donné dans le document public.

Le projet passe par Terafab, le complexe de fabrication de puces IA que xAI, Tesla et SpaceX développent ensemble à Austin, au Texas. Jusqu'ici, Musk avait surtout évoqué des puces destinées aux voitures, aux robots humanoïdes et aux data centers spatiaux.

Le S-1 ajoute donc une pièce importante : des GPU, probablement pour alimenter l'ambition IA du groupe sans dépendre uniquement de Nvidia.

SpaceX prévient aussi ses futurs investisseurs qu'il pourrait manquer de puces pour soutenir sa croissance. L'entreprise ne dispose pas de contrats long terme avec plusieurs de ses fournisseurs directs, ce qui est la façon polie d'expliquer que la chaîne d'approvisionnement n'est pas vraiment sécurisée au-delà de quelques trimestres. L'IPO visée autour de 1 750 milliards de dollars se construit justement sur ce genre de promesses d'indépendance technologique, vous voyez donc où se situe le problème. Fabriquer en interne devient une sécurité contre la rupture et surtout contre l'explosion des prix du silicium dédié à l'IA.

Musk qui fabrique ses propres GPU, ça boucle aussi plusieurs morceaux de son empire. Tesla avait déjà la puce Dojo pour l'entraînement de ses modèles de conduite, xAI a besoin de capacités énormes pour faire tourner Grok, et SpaceX pousse carrément sur les data centers en orbite. Un fournisseur unique mutualisé entre les trois, ça permettrait l'air de rien d'écraser les coûts et de mettre Nvidia à une distance polie.

De son côté, Intel a mis des années à sortir sa gamme IA, et Google a pris son temps avec les TPU, et même Apple n'attaque pas Nvidia de front. Du coup, l'annonce dans le S-1 ressemble plus à une communication dédiée investisseurs qu'à projet clair et bien cadré.

Quoi qu'il en soit, Musk continue de construire sa verticalité complète, du lanceur à la puce. À ce rythme, il finira par acheter du sable et une centrale électrique dédiée.

Source : Reuters via Yahoo

Environ 180 tonnes d'objets fabriqués par l'homme sont déjà posés sur la Lune, dont une grosse partie datant des missions Apollo. 

e site Hackaday vient de publier un recensement assez complet, qui rappelle que l'exploration lunaire n'a pas laissé que des traces de pas dans le régolithe.

Côté matériel technique, il y a les étages de descente des modules lunaires, quelques rovers, des instruments scientifiques et surtout sept réflecteurs optiques encore utilisés aujourd'hui par les astronomes pour mesurer précisément la distance Terre-Lune au laser, avec une résolution de quelques millimètres.

C'est la partie noble de l'inventaire. À côté, il y a tout le reste : des gants, des surchaussures, des caméras abandonnées, des chariots à outils, des morceaux de mission laissés sur place après usage.

Et puis il y a les déchets organiques. Les missions Apollo ont laissé 96 sacs de déchets humains sur la surface, urine incluse, pour économiser du poids au retour.

Oui, une grosse partie de nos premiers voyages lunaires a consisté à déposer nos excréments sur un autre corps céleste, en même temps que le drapeau. Bienvenue dans l'histoire.

Plus touchant, on trouve aussi des objets personnels déposés par les astronautes. Un patch de la mission Apollo 1, en mémoire des trois astronautes morts dans l'incendie de la capsule pendant l'entraînement, a été laissé sur place.

Charles Duke, sur Apollo 16, a posé une photo encadrée de sa famille au sol lunaire. Et quelque part, les cendres du géologue Gene Shoemaker reposent dans un cratère, ce qui en fait le seul humain enterré sur la Lune à ce jour.

Il y a aussi des curiosités plus bizarres. Une plume de faucon apportée par David Scott sur Apollo 15 pour tester en direct la loi de la chute libre de Galilée devant les caméras. Un disque de silicium gravé avec des messages de bonne volonté venus de 73 pays, largué par Apollo 11.

Une tuile en céramique sur laquelle des artistes dont Andy Warhol auraient gravé leurs œuvres, glissée en douce sur un train d'atterrissage d'Apollo 12.

Avec Artemis et toutes les missions chinoises, indiennes, émiraties ou luxembourgeoises qui s'annoncent, le rythme de dépôt va grimper. Il y a de plus en plus de gens qui pensent qu'il faudrait un jour classer certains de ces sites comme patrimoine, avant qu'une autre mission ne roule dessus par inadvertance.

Bref, on raconte toujours l'exploration lunaire en images héroïques, et c'est quand même plus parlant de se rappeler que le premier héritage humain là-haut, c'est 96 sacs d'excréments.

Source : Hackaday

Un logiciel malveillant destiné à effacer définitivement les données de postes informatiques vient de faire surface dans le secteur énergétique vénézuélien.

La bête a été baptisée "Lotus" par les chercheurs de Kaspersky qui l'ont analysé en premier, il a été mise en route en décembre 2025 depuis un ordinateur vénézuélien, et sa cible principale semble être PDVSA, la compagnie pétrolière d'État.

Côté technique, Lotus ne fait pas dans la dentelle. Deux scripts batch préparatoires, OhSyncNow.bat et notesreg.bat, désactivent toutes les défenses, coupent les comptes utilisateurs et ferment les interfaces réseau, histoire de bien tout bloquer.

Ensuite, le binaire principal passe en mode destruction avec diskpart, robocopy et fsutil pour manipuler le système de fichiers, puis descend au niveau IOCTL pour écraser directement des secteurs physiques du disque. Les points de restauration sont supprimés, le journal USN est effacé. Aucune récupération possible.

LKaspersky ne pointe personne, et aucun élément technique ne désigne un État ou un groupe criminel en particulier. Le timing est quand même troublant : fin 2025 et début 2026, le Venezuela a traversé une crise politique majeure avec la capture de l'ancien président Nicolás Maduro le 3 janvier, et les tensions toujours fortes autour des infrastructures énergétiques. Coïncidence ou coordination, on ne saura probablement pas avant longtemps.

En pratique, un wiper qui cible PDVSA, ça rappelle immédiatement les attaques contre les infrastructures critiques qu'on a vues en Ukraine avec Stryker ou contre des clusters Kubernetes avec la variante TeamPCP.

L'objectif n'est pas le chantage ni le vol, c'est la destruction pure. Les opérateurs ne cherchent pas à exfiltrer quelque chose, ils veulent rendre l'infrastructure inutilisable le plus vite possible, pour déstabiliser ou punir.

Un réseau d'alimentation électrique ou de distribution de carburant paralysé quelques jours, ça a des conséquences directes sur la vie quotidienne et sur la stabilité politique d'un régime.

Ce qui inquiète, c'est aussi la qualité du code. Lotus n'est pas un script amateur collé à la va-vite : il enchaîne plusieurs étapes de sabotage méthodique, de la désactivation des défenses à la destruction bas niveau du disque.

Pour un pays qui n'a déjà pas la réputation d'avoir la cybersécurité la plus pointue du continent, encaisser ce genre d'outil, ça fait mal. Et la probabilité que d'autres échantillons du même auteur circulent déjà ailleurs est loin d'être nulle.

Bref, un wiper bien fichu sur une compagnie pétrolière d'État dans un pays en crise, c'est rarement l'œuvre d'un adolescent dans son garage. Affaire à suivre donc.

Source : Bleeping Computer

Vous voulez comprendre ce qui se passe dans le cerveau de votre bagnole ? Hé bien pour cela avant, il fallait du matos pro et des suites logicielles à licence annuelle. Mais maintenant, y'a CANviz .

Un pip install canviz, un module USB à quelques balles branché sur le bus CAN de la voiture, et hop, vous accédez à tous les secrets de votre voiture simplement en ouvrant votre navigateur sur localhost:8080. Toutes les trames qui circulent sur le réseau interne du véhicule s'affichent en direct dans un tableau qui défile sans ramer à 2000 fps si j'en crois le README, donc ça envoie !

Ce projet signé Chanchal Dhiman tourne sur n'importe quelle config équipée de Python 3.10 ou supérieur, et côté matériel, CANviz se branche sur plein de bazars tels que les modules à firmware Candlelight (genre FYSETC UCAN autour de 8 balles ou CANable 1.0 autour de 15), les périphériques slcan via port COM, et du matériel sérieux type PEAK PCAN-USB, Kvaser, Vector ou même socketcan sur Raspberry Pi. En gros, si votre clé USB CAN est compatible avec python-can, CANviz la gère !

L'interface décode alors les fichiers DBC (le format de base de données du CAN), donc au lieu de lire des paquets hexadécimaux chelous, vous voyez directement "vitesse moteur = 1450 rpm" ou "position accélérateur = 34%". Vous pouvez aussi filtrer par ID ou par nom de signal, et le filtre se garde dans l'URL. Comme ça, vous pouvez partager une vue à un pote en copiant simplement le lien.

Le truc vraiment pratique, c'est surtout la partie enregistrement. Vous capturez une session en .asc ou .csv, et vous la rejouez plus tard à vitesse variable (de 0.5x pour décortiquer lentement, jusqu'à 10x pour survoler), ou vous forgez vos propres trames depuis l'interface pour tester la réaction d'un module donné. Une API REST et du WebSocket ouvrent aussi la porte aux bricolages en Python, avec une doc interactive accessible sur /docs.

Autre truc malin, vu que c'est un serveur web derrière : vous pouvez déployer CANviz sur un Raspberry Pi planqué dans la bagnole et le consulter à distance en SSH. Par contre, pas de WebUSB ici. L'auteur a explicitement fait le choix de passer par python-can côté serveur pour des raisons de sécurité. L'accès USB reste donc dans le sandbox Python, et le browser ne touche rien. J'avoue, je préfère.

Le projet est sous licence MIT, et est encore jeune, mais l'approche est éprouvée. Pour ceux qui cherchent des alternatives desktop, y'a bien sûr CANgaroo côté Qt, ou SavvyCAN qui tourne aussi en natif. Et si vous voulez bidouiller votre voiture comme Charlie Miller l'a fait avec la Jeep , y'a toujours le Panda de Comma sorti en 2017 avec son soft Cabana.

Bref, pour quelques euros de module USB et un pip install des familles, vous pouvez transformer votre laptop en analyseur CAN niveau pro et ça c'est plutôt classe !

Source

Apple a publié hier une mise à jour iOS qui ferme une faille utilisée par les forces de l'ordre américaines pour récupérer des messages supprimés dans des applications comme Signal.

La faille concernait la base de données des notifications : quand vous supprimiez un message dans l'appli, la version cachée dans le cache des notifications pouvait rester accessible jusqu'à un mois.

Concrètement, un message Signal effacé côté appli restait lisible par quiconque avait la main sur le téléphone et savait fouiller au bon endroit.

Le FBI, selon les documents repérés par 404 Media début avril, a utilisé cette faiblesse sur plusieurs affaires pour remonter des conversations pourtant explicitement effacées par les utilisateurs, y compris celles utilisant la fonction messages éphémères.

Apple a reconnu le problème, mais si ça a été fait avec les pincettes habituelle, avec une phrase du genre... "les notifications marquées pour suppression pouvaient être conservées sur l'appareil de manière inattendue", ce qui ne veut pas dire grand chose, ou au contraire, tout dire...

Dit plus simplement, il y avait un écart entre ce que l'utilisateur voyait disparaître et ce qui restait réellement sur le disque. Le patch a été rétroporté sur les anciennes versions d'iOS 18, ce qui suggère que la faille existait depuis un bon moment et a probablement été exploitée dans des affaires que l'on ne connaîtra jamais.

Meredith Whittaker, présidente de Signal a rappelé publiquement que les notifications pour des messages effacés ne devraient jamais rester dans la base de notifications d'un OS. C'est une évidence technique. Sauf que dans la pratique, la chaîne cache des notifications plus indexation iOS laisse des traces que les outils forensiques comme Cellebrite ou GrayKey savent exploiter depuis des années.

Le problème dépasse Signal. Toute application qui envoie une notification contenant le texte d'un message entier sur iOS pouvait voir ses contenus persistés dans le cache, même après un effacement explicite. Du coup, pour les journalistes, les avocats, les activistes ou simplement les gens qui tiennent à leur vie privée, mettre à jour le plus vite possible n'est pas une option mais une priorité.

Bref, quand on parle de messagerie chiffrée, la vraie surface d'attaque n'est plus le protocole mais tout ce que l'OS fait autour dans votre dos.

Source : The Hacker News

Vous bossez sur un Dockerfile et vous avez besoin de la dernière version de nginx. Vous ouvrez GitHub, vous cliquez sur Releases, vous copiez-collez. Et 3 minutes plus tard, rebelote pour curl. Puis pour PHP. Sans parler du fait que dans votre script d'auto-update, vous avez hardcodé une "v3.2.1" qui dort là depuis 2023 parce que personne n'a pris le temps de mettre à jour le fichier.

Lastversion , c'est le petit CLI Python signé Danila Vershinin qui remplace cette corvée par une seule ligne. Vous tapez lastversion apache/incubator-pagespeed-ngx et vous récupérez le numéro de la dernière version.

Le truc marche sur GitHub, GitLab, BitBucket, PyPI, Wikipédia, les flux RSS, les plugins WordPress, Helm charts, Gitea, SourceForge... et même sur des sites qui publient leurs versions comme ils veulent, genre nginx.org.

La beauté du bazar, c'est qu'il comprend les humains, parce que, c'est vrai, les mainteneurs font un peu n'importe quoi avec leurs tags. Ils étiquettent release-1.2.3 au lieu de 1.2.3, ils marquent des release candidates en stable sans le faire exprès, ils changent de format entre v20150121 et v2.0.1 sans prévenir. lastversion détecte toutes ces incohérences et vous renvoie la véritable dernière stable, celle que vous vouliez dès le départ. C'est pénible à gérer à la main quand vous avez vingt dépendances à suivre. Maintenant c'est réglé tout seul avec ce petit bidule.

Et les sources exotiques, c'est tout un délire. lastversion windows vous crache le build Windows en cours, lastversion ios pour iOS, lastversion rocky vous renverra 8.4 et lastversion https://en.wikipedia.org/wiki/Rocky_Linux aussi, parce que le bidule va carrément parser la page Wikipédia pour vous.

Alors certains d'entre vous me diront que ce n'est pas utile au quotidien. Peut-être jusqu'au jour où vous devez scripter une vérif de version d'OS sans dépendre d'un outil système. Par contre, si vous enchaînez cinquante requêtes par heure sur un token GitHub anonyme, faudra pas s'étonner de manger un rate limit dans la tronche.

Côté one-liners qui tuent, y'a déjà de quoi faire.

wget $(lastversion --assets mautic/mautic) télécharge direct la dernière archive.

lastversion --pre Aircoookie/WLED --format assets --filter ESP32.bin -d ESP32.bin récupère le dernier firmware ESP32 WLED.

Pour Nginx, lastversion https://nginx.org --major stable renvoie 1.16.1 pendant que --major mainline renvoie 1.17.9.

Vous voyez l'idée, c'est du pipe-friendly pur jus.

Et le mode install, c'est un autre délire. Vous tapez lastversion install mailspring et hop, il récupère l'AppImage ou le RPM du dépôt, il l'installe, et c'est fini. Attention quand même, sur les dépôts un peu bordéliques il va parfois se vautrer sur le packaging et juste vous balancer le tarball brut. Bon, c'est pas la mort, vous dézippez à la main et vous passez à la suite...

Combiné avec cron, @daily /usr/bin/lastversion install mailspring -y et votre bureau sera toujours à jour sans passer par un store. Pour tous les outils qui ne sont ni dans apt, ni dans un snap, ni dans un flatpak, c'est l'alternative la plus propre à avoir sous la main.

L'install se fait via pip install lastversion sur à peu près tout, ou yum install lastversion après avoir ajouté le repo GetPageSpeed si vous êtes sur CentOS, RHEL, Rocky, Alma, Fedora ou Amazon Linux.

Le projet est publié sous licence BSD-2, codé en Python, et il y a aussi une API utilisable directement (from lastversion import latest) si vous préférez appeler ça dans vos scripts plutôt que de piper dans un subprocess.

Bref, un chouette outil à ranger entre vos redirections bash et votre gestionnaire SSH , catégorie petits trucs qui font gagner 10 minutes par semaine.

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

360 Digital Security, la filiale cybersécurité du géant chinois Qihoo 360, revendique environ mille vulnérabilités inédites déterrées par un agent IA maison baptisé Vulnerability Discovery Agent. 

L'annonce, faite le 22 avril, cite nommément Microsoft Office et le framework open source OpenClaw parmi les logiciels touchés. Le chiffre est donné sur un seul cycle de campagne.

Mille failles non documentées en un seul cycle de recherche, ça fait un peu tourner la tête. Ce type d'agent fonctionne en boucle pour scanner massivement les bases de code, trier ce qui est potentiellement exploitable, et valider les candidats avant publication interne.

Plus tôt dans l'année, 360 avait déjà présenté un autre outil dédié à la construction automatisée de chaînes d'exploitation. L'un déterre les failles, l'autre fabrique le code qui les utilise.

Mis bout à bout, ça donne une ligne de production offensive entièrement pilotée par IA, que l'équipe 360 décrit comme une réponse directe au projet Mythos d'Anthropic, qui fait le même pari côté occidental mais en mode défense.

Le vrai souci, c'est le devenir de ces 1 000 failles. Si toutes ont été remontées aux éditeurs concernés, tant mieux. 360 affirme d'ailleurs avoir utilisé les canaux de divulgation responsables, mais sans publier de calendrier de patch.

Sauf que l'entreprise est connue pour ses liens étroits avec le ministère chinois de la Sécurité d'État, et plusieurs de ses chercheurs ont déjà été soupçonnés par le passé de garder pour l'État ce qu'ils trouvaient. Du coup, l'annonce met les équipes de sécurité occidentales quelque peu en alerte.

Microsoft, qui patche Office tous les mois pour des failles trouvées à la main, va probablement devoir accélérer le rythme si ce genre de scan industriel se généralise. En pratique, la chasse aux vulnérabilités est en train de changer d'échelle.

On passe de quelques failles trouvées par un chercheur humain sur plusieurs semaines à un agent qui en déniche des centaines en quelques jours. Et la logique économique derrière est folle : un seul opérateur bien outillé peut désormais couvrir ce qu'il fallait avant à une équipe complète.

Bref, le mur est tombé côté IA offensive. Et les éditeurs qui patchent à la main ont un vrai problème de cadence face à un scan automatisé à cette échelle.

Source : Bloomberg