Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Copilot Tasks will turn the AI Chatbot into a Personal Assistant

Microsoft introduced Copilot TasksMicrosoft has introduced a new Copilot Tasks feature to its AI ecosystem, marking a significant move towards autonomous task execution. This new feature gives Copilot the ability to execute tasks and automate actions on behalf of users, making it more than a traditional AI chatbot. Copilot Tasks: Turning an AI Chatbot into a Personal Assistant […]

The post Copilot Tasks will turn the AI Chatbot into a Personal Assistant appeared first on TheWindowsClub News.

AI Recommendation Poisoning can influence AI chats

AI Recommendation PoisoningThe research team at Microsoft discovered a new type of cyberattack called AI Recommendation Poisoning. Unlike a malware-injection attack that targets users’ devices, this attack manipulates the information shown to users, gradually influencing their decisions and acting like digital poison. AI Recommendation Poisoning can influence AI chats AI Recommendation Poisoning occurs when an external actor […]

The post AI Recommendation Poisoning can influence AI chats appeared first on TheWindowsClub News.

TPMS - Vos pneus balancent votre position en clair

Gaël Musquet, mon copain hacker, me parlait déjà de tracking TPMS en 2020. Du coup, quand je vois des chercheurs publier un document de recherche en 2026 pour "découvrir" qu'on peut pister une voiture via ses capteurs de pneus, bon, comment dire... je suis pas tombé de ma chaise.

Mais faut reconnaître que l'étude en question va quand même plus loin qu'une discussion entre 2 stands au FIC. En effet, une équipe d'IMDEA Networks et d'armasuisse (le labo de défense suisse, rien que ça) a posé 5 récepteurs SDR dans une ville pendant 10 semaines. Coût du matos, environ 100 dollars par capteur, qui est en gros un Raspberry Pi 4 avec un dongle RTL-SDR à 25 balles. Et grâce à cela, ils ont capté plus de 6 MILLIONS de messages, provenant de plus de 20 000 véhicules !

un Raspberry Pi 4 avec un dongle RTL-SDR - Source

Car oui, vous ne le savez peut-être pas, mais les capteurs de pression des pneus (TPMS pour les intimes) émettent régulièrement dès que le véhicule roule, sur 433 MHz en Europe. Et ces signaux contiennent un identifiant unique... qui bien sûr est en clair ^^. Pas de chiffrement, pas d'authentification, QUE DALLE. Donc avec un logiciel open source comme rtl_433 , ça devient vite facile de capter tout ça à plusieurs dizaines de mètres à la ronde.

En croisant les identifiants captés par plusieurs récepteurs, les chercheurs ont pu reconstituer les trajets des véhicules, identifier leurs horaires de travail, détecter les jours de télétravail et même estimer les variations de charge du véhicule (et potentiellement déduire la présence de passagers, même si c'est encore approximatif). Le tout sans caméra, sans GPS, et sans accès au réseau du véhicule !

Il suffirait de trouver l'identifiant d'une voiture précise pour déclencher par exemple automatiquement un lâcher de confettis en papier parfaitement inoffensifs à son passage, si vous voyez ce que je veux dire.

Alors attention, tous les véhicules ne sont pas logés à la même enseigne. Les TPMS dits "directs" (dTPMS), qu'on trouve souvent chez Toyota, Peugeot, Citroën, Hyundai ou Mercedes, émettent ces fameux signaux radio captables. Alors que les systèmes "indirects" (iTPMS), utilisés par la plupart des modèles Volkswagen, Audi ou Skoda, se basent sur les capteurs ABS et n'émettent rien par radio. Bref, si vous roulez en Golf de base, y'a de bonnes chances que vous soyez tranquilles sur ce coup-là même si certaines versions sportives ou haut de gamme (Golf R, GTI selon les marchés) peuvent embarquer du dTPMS.

Et le pire dans tout ça c'est que la réglementation UN R155 sur la cybersécurité automobile n'impose pas explicitement le chiffrement des TPMS. En gros, les constructeurs ne sont pas forcés de sécuriser ces transmissions. Pirelli et Bosch bossent bien sur un "Cyber Tyre" en Bluetooth Low Energy, mais c'est réservé au haut de gamme et c'est pas demain que ça arrivera sur votre Clio.

Donc côté protection, soyons honnêtes, y'a pas grand-chose à faire côté utilisateur. Vous ne pouvez pas désactiver vos TPMS (c'est obligatoire depuis 2014 pour les voitures neuves en Europe), et les capteurs ne proposent aucune option de chiffrement. Sauf si vous roulez en véhicule vintage d'avant 2014, c'est open bar. Une des parades serait que les constructeurs implémentent un système de rotation d'identifiants, un peu comme le fait déjà le Bluetooth avec les adresses MAC aléatoires, mais pour l'instant on en est loin.

Pour ceux qui veulent creuser le sujet, j'avais fait une rencontre avec Gaël Musquet il y a quelques années, où il expliquait déjà comment reprendre le contrôle de nos véhicules connectés. Et si vous voulez comprendre comment on hacke une voiture de manière plus générale, c'est un rabbit hole sans fond !

Bref, la prochaine fois que vous gonflez vos pneus... dites-leur bonjour de ma part.

Source

AirSnitch - L'isolation client WiFi ne vous protège pas

Bon, vous connaissez la théorie du travailleur nomade... vous vous posez dans un café avec votre laptop, vous chopez du WiFi gratuit, et vous vous dites que l'isolation client du routeur vous protègera des autres branquignols connectés au même réseau.

Hé ben non ! Car des chercheurs viennent de démontrer que cette protection, c'était du vent... Oui oui, tous les routeurs qu'ils ont testés se sont fait contourner en 2 secondes.

Mais avant, pour ceux qui se demandent ce que c'est, l'isolation client c'est une option que les admins réseau activent sur les bornes WiFi pour empêcher les appareils connectés de communiquer entre eux. En gros, votre laptop ne peut pas voir celui du voisin. Enfin... ça c'est en théorie.

Parce qu'en fait, le truc c'est que cette fonctionnalité n'est même pas définie dans le standard WiFi (IEEE 802.11) ce qui oblige chaque fabricant à faire sa propre tambouille dans son coin, et du coup ça fuit de partout.

L'équipe derrière cette trouvaille, c'est des chercheurs de l'UC Riverside et de KU Leuven, dont Mathy Vanhoef, le même gars qui avait déjà mis le WPA2 à genoux avec KRACK en 2017. Pas un amateur, quoi. Et leur outil, baptisé AirSnitch, vient d'être présenté à la conférence NDSS 2026 .

Ils ont ainsi trouvé 3 méthodes différentes pour contourner la protection d'isolation. La première abuse de la clé de groupe (GTK), normalement réservée au broadcast, pour envoyer du trafic directement à un appareil ciblé. Le pire, c'est que macOS, iOS et Android acceptent ce trafic sans broncher (merci les gars !).

La seconde fait rebondir les paquets via la passerelle, et la troisième vole carrément l'adresse MAC de la victime sur un autre point d'accès pour intercepter son trafic.

Brrrrrr.... 11 routeurs testés, du Netgear R8000 au Cisco Catalyst 9130 en passant par TP-Link, ASUS, Ubiquiti et même OpenWrt 24.10. Et ils sont TOUS vulnérables, sans exception ! Et que vous soyez en WPA2 ou en WPA3, réseau perso ou entreprise, c'est pareil. Donc autant vous dire que ça pue !

Ils ont même réussi à effectuer un Man-in-the-Middle complet (interception de tout le trafic entre vous et Internet) en 2 secondes chrono. La "victime" qui regardait YouTube n'a même pas remarqué de lag et c'est comme ça qu'ils ont pu intercepter tout son trafic, ni vu ni connu.

Alors du coup, on fait quoi ? Hé bien si vous gérez un réseau, oubliez l'isolation client toute seule et passez aux VLANs avec un VLAN par client. Oui c'est lourdingue à mettre en place, mais c'est le prix à payer pour avoir une sécurité solide. Certains constructeurs bossent aussi sur des clés de groupe individuelles par client, ce qui règlerait le problème à la source.

Côté utilisateur, la solution est plus simple... VPN !! Attention, ça ne marche que si le VPN est activé AVANT de vous connecter au réseau, pas après. HTTPS vous protège déjà pour le contenu des sites, mais selon Google, 6 à 20% des pages ne sont toujours pas en HTTPS... et même quand elles le sont, l'attaquant voit quand même où vous surfez et peut tenter du DNS spoofing. Donc sur n'importe quel réseau WiFi public , partez du principe que quelqu'un peut voir votre trafic, parce que visiblement c'est le cas.

Le code source d' AirSnitch est dispo sur GitHub si vous voulez tester votre propre config mais notez que ça nécessitera une carte WiFi compatible avec le mode monitor comme les Alfa (lien affilié), donc pas celle de votre laptop de base.

Bref, la prochaine fois que le WiFi de l'hôtel vous demande d'accepter les CGU en échange d'un accès "sécurisé"... ben gardez votre VPN allumé, hein.

Source

Faux entretiens d'embauche - Le piège qui vise les devs Next.js

Des faux entretiens d'embauche avec des repos GitHub vérolés pour piéger les devs Next.js... on croit rêver et pourtant, Microsoft vient de documenter cette campagne ciblée et vous allez voir, c'est violent.

En fait, un groupe de hackers se fait actuellement passer pour des recruteurs et contacte des développeurs JavaScript en leur proposant un entretien technique. Le deal c'est de cloner un repo GitHub pour un "test de compétences"... sauf que le repo en question est truffé de malware.

Microsoft a ainsi identifié plusieurs vecteurs d'infection planqués dans ces repos. Le premier, c'est via les fichiers de configuration VS Code, c'est à dire ceux dans le dossier .vscode/, qui peuvent exécuter du code dès que vous cliquez "Trust" à l'ouverture du projet (ce que la plupart des devs font sans réfléchir).

Le deuxième passe par un npm run dev piégé, la commande de dev classique qui lance le malware en même temps que le serveur (car oui, c'est aussi simple que ça...).

Et le troisième est encore plus sournois puisqu'il s'agit d'un module backend qui décode une URL depuis le fichier .env, exfiltre toutes les variables d'environnement (tokens cloud, clés API...), puis exécute du JavaScript reçu en retour. Sympaaaaaa....

Du coup, le malware est plutôt bien pensé. C'est un loader JavaScript qui se télécharge depuis l'infrastructure Vercel (comme ça, ça a l'air légitime), et qui s'exécute entièrement en mémoire, et spawne un processus Node.js séparé pour ne pas éveiller les soupçons. Une fois installé, il se connecte alors à un serveur C2 qui change d'identifiant régulièrement, histoire de compliquer la détection. Et là, ça se met à exfiltrer tout ce qui traîne... code source, secrets, credentials cloud... bref, tout ce qui a de la valeur.

Alors, comment on se protège de ce genre de menace quand on est un simple dev ? Hé bien déjà, vérifiez le profil du "recruteur". Pas de site d'entreprise vérifiable, des messages génériques... c'est un joli red flag !

Ensuite, avant de lancer quoi que ce soit, lisez le package.json à la recherche de scripts suspects dans preinstall, postinstall ou prepare, inspectez le dossier .vscode/ (surtout tasks.json), et faites un npm install --ignore-scripts pour bloquer l'exécution automatique des hooks. Lancez aussi un safe-npm et un npm audit une fois les dépendances installées. Et côté VS Code, désactivez l'exécution auto des tasks avec "task.allowAutomaticTasks": "off" dans vos settings.

Ça me rappelle les campagnes type Shai-Hulud et les packages npm vérolés , mais avec un vecteur social bien plus élaboré. Le piège, c'est qu'on ne balance plus des packages malveillants dans le registry en espérant qu'un dev les installe par erreur... non, non, on cible directement les développeurs, un par un, en exploitant ce stress de la recherche d'emploi comme le ferait un conseiller France Travail quand vous arrivez en fin de droits chomdu...

Et si vous êtes en pleine recherche d'emploi, attention, ne lancez JAMAIS un projet d'un inconnu dans votre environnement principal. Utilisez une VM, un container Docker (docker run --rm -it -v $(pwd):/app node:20 bash et c'est réglé), ou au minimum un compte utilisateur séparé sans accès à vos tokens et clés SSH. On n'est jamais trop prudent !

Maintenant vous savez... si un recruteur vous envoie un repo GitHub sans profil LinkedIn ni site d'entreprise véritable et vérifiable... c'est que c'est pas un recruteur. Voilà voilà...

Source

Claude Code - Pilotez votre terminal depuis votre canapé

Claude Code tourne en local et c'est son gros avantage car ça permet par exemple d'agir sur votre machine, de lancer des scripts...etc. Mais c'est aussi sa grosse limite car à cause de ça, vous êtes cloué devant votre terminal. J'étais en quête depuis un moment d'une solution et je vous avais déjà parlé de Vibe Companion y'a pas longtemps mais tous ces outils vont disparaitre puisque Anthropic vient de sortir Remote Control, une feature qui transforme claude.ai ou l'app mobile en télécommande pour votre session locale. Comme ça, vos fichiers restent chez vous et seule l'interface voyage.

Votre ordi fait tourner Claude Code normalement, et vous, vous pouvez continuer à lui parler depuis votre iPhone, votre Android, votre iPad ou n'importe quel navigateur Chrome, Firefox, Safari... Pas de serveur exposé, pas de port ouvert, que du HTTPS sortant. C'est plutôt bien foutu vous allez voir !

Ce qu'il vous faut

Bon déjà, un abonnement Pro (Édit : ? on me dit que c'est pas encore actif pour les pro ?) ou Max (pas le choix, les clés API ne marchent pas et les plans Team/Enterprise sont exclus pour le moment). Ensuite, vérifiez que Claude Code est installé et que vous êtes connecté via /login. Acceptez ensuite le "workspace trust" dans votre projet et hop, c'est tout côté prérequis.

Lancer une session

Deux options s'offrent à vous ensuite... Soit vous démarrez une nouvelle session dédiée :

claude remote-control

Soit vous êtes déjà en train de bosser dans Claude Code et vous tapez /rc (alias de /remote-control). Avec claude remote-control, seule l'URL apparaît... donc appuyez sur espace pour afficher le joli QR code.

3 flags utiles (uniquement avec claude remote-control, pas /rc) : --verbose pour voir ce qui transite, --sandbox pour forcer le mode bac à sable (désactivé par défaut) et --no-sandbox pour le couper si vous l'avez activé dans votre config.

Se connecter depuis un autre appareil

Ensuite, la méthode la plus rapide c'est de scanner le QR code avec votre téléphone. Sinon, copiez l'URL affichée et collez-la dans n'importe quel navigateur. Dernière option, allez sur claude.ai/code et votre session apparaît dans la liste (les sessions actives ont un petit point vert).

Une fois connecté, vous récupérez votre conversation en cours, vos fichiers, votre contexte... tout. Vous pouvez envoyer des messages, voir les résultats, approuver les modifications de fichiers. Bref, comme si vous étiez devant votre terminal, sauf que vous êtes dans votre canapé, votre lit ou en train de pousser le caddie chez Auchan !

Activer par défaut

Maintenant, si vous voulez que CHAQUE session Claude Code soit automatiquement accessible à distance, tapez /config dans une session Claude Code, puis activez l'option "Enable Remote Control for all sessions". Et voilà, plus besoin d'y réfléchir ! Chaque claude lancé dans un terminal sera pilotable depuis votre navigateur ou l'app mobile.

Vos sessions prennent le nom de votre dernier message (ou "Remote Control session" par défaut), donc utilisez /rename mon-projet-cool pour les retrouver facilement dans la liste sur claude.ai/code.

Sinon, dans Claude Code avec /mobile vous pouvez aussi afficher directement le QR code pour télécharger l'app Claude sur iOS ou Android.

Les limites à connaître

Bon, après c'est pas non plus parfait car déjà, c'est cappé à UNE SEULE session à distance par instance de Claude Code (si vous en lancez une deuxième, la première se déconnecte). Par contre, plusieurs instances dans des terminaux différents peuvent chacune avoir leur session remote. Le terminal doit également rester ouvert (si vous le fermez, c'est fini). Mais bonne nouvelle quand même, si le laptop passe en veille ou que le réseau saute, ça se reconnectera tout seul au réveil. Le piège, c'est si la machine reste sans réseau plus de 10 minutes... là, la session expire et il faudra relancer claude remote-control.

Soyez rassurés quand même côté sécurité c'est propre (uniquement du HTTPS sortant sur le port 443, zéro port entrant et des identifiants éphémères), mais gardez en tête que Claude Code a accès à votre terminal donc sauf si vous activez --sandbox, il peut de ce fait exécuter n'importe quelle commande... donc les mêmes précautions qu'en local s'appliquent !

Du coup si vous en avez marre de rester scotché devant votre terminal, maintenant vous savez quoi faire.

Merci à Lorenper !

Onlook - Fini les allers-retours entre Figma et le code

Bonne nouvelle pour ceux qui en ont ras la casquette de se taper des allers-retours entre Figma et VS Code ! Parce qu'avec Onlook , l'éditeur visuel open source qui vous permet de modifier le design de vos apps React directement dans le navigateur, vous allez pouvoir cliquer simplement sur un élément de design, et en changer la couleur, la typo...etc et hop, ça modifiera le code derrière.

Pas mal, non ?

Vous ouvrez votre projet Next.js dans Onlook, et vous vous retrouvez avec une interface à la Figma, sauf que c'est branché sur votre code source. Vous sélectionnez un titre, un bouton, n'importe quel composant, et vous modifiez son style visuellement... couleurs, padding, marges, polices, tout y passe.

Et en fait, le truc qui change tout par rapport à un inspecteur CSS classique, c'est que quand vous cliquez sur "Publish", les modifications atterrissent DIRECTEMENT dans vos fichiers .tsx. C'est donc du vrai code propre, pas du CSS inline dégueulasse.

Côté technique, l'outil gère nativement TailwindCSS (parce que bon, en 2026, si vous faites du React sans Tailwind, vous aimez forcément le cuir qui claque et la souffrance). Vous éditez en mode visuel, ça génère les bonnes classes Tailwind, et vous gardez un contrôle total. Y'a aussi un mode LLM intégré... "rends ce bouton bleu avec des coins arrondis" et hop, c'est fait. Comme ça, pas besoin de chercher si c'est rounded-lg ou rounded-xl dans la doc.

Pour ceux qui connaissent Bolt.DIY ou qui se souviennent d' Amplify Studio (le truc de AWS qui tentait de faire le pont Figma vers React), Onlook prend le problème dans l'autre sens. Au lieu de partir du design pour générer du code, on part du code existant et on le modifie visuellement. Du coup, pas de code généré bancal à maintenir, c'est finalement VOTRE codebase qui est éditée.

Le projet est open source sous licence Apache 2.0 sur GitHub et la version open source est gratuite et self-hostable, donc vous pouvez la faire tourner chez vous sans débourser un centime. Après pour ceux qui veulent du cloud managé avec collab temps réel, y'a des plans payants.

Après attention, c'est encore jeune et le support se limite à React et Next.js pour l'instant, donc si votre stack c'est Vue ou Svelte, ça ne marchera pas. Et l'IA mouline un peu sur les layouts complexes mais le projet avance vite, la communauté est active, et pour un outil gratos qui fait le lien entre design et code en open source, y'a pas grand-chose d'équivalent.

Bref, à tester, c'est gratos.

Et merci à Lorenper !

Clés API Google - 3000 clés publiques donnent accès à Gemini

Les clés API Google que vous collez dans votre JavaScript pour afficher une carte Maps... hé bien elles ne sont plus si inoffensives. Car depuis que Gemini est entré dans la danse, ces mêmes clés donnent maintenant accès à vos fichiers privés et surtout à votre facture IA.

Et personne ne nous a prévenu...

En gros, Google utilise un format de clé unique, les fameuses AIza..., aussi bien pour Maps et Firebase (public, collé dans le HTML, tout le monde s'en fout) que pour Gemini (privé, accès aux fichiers, facturation). Le problème c'est que quand vous activez l'API Gemini sur un projet Google Cloud, TOUTES les clés existantes de ce projet héritent automatiquement de l'accès Gemini. Sans warning, sans notification, sans rien... Ouin !

Les chercheurs de TruffleSecurity ont ainsi trouvé presque 3000 clés API Google valides dans le dataset Common Crawl de novembre 2025. Des clés qui trainent dans du code JavaScript, des pages HTML, des repos GitHub publics... et qui fonctionnent sur l'endpoint Gemini. Il suffit d'un simple curl avec une clé Maps récupérée sur un site web, et hop, vous accédez à l'API Gemini du propriétaire. Fichiers privés, contenu en cache, facturation sur son compte.

Et parmi les victimes, on trouve des institutions financières, des boîtes de cybersécurité, et... Google eux-mêmes (oui oui, vraiment).

Le 21 novembre 2025, TruffleSecurity signale donc le problème et la réponse de Google le 25 novembre c'est : "intended behavior" (comportement normal)... Sauf que le 2 décembre, Google a reclassifié ça en bug, puis le 13 janvier 2026, ça passe finalement en Tier 1. On est donc passé du "c'est normal les frérots" à "ah oui quand même, oupsi oups", en 7 semaines.

Maintenant, pour ceux qui se demandent si leurs clés API Google sont concernées, direction console.cloud.google.com , section "APIs & Services" puis "Identifiants".

Si vous voyez l'API " Generative Language " de Gemini API activée sur un projet avec des clés non restreintes... attention, c'est le moment de faire le ménage. Ajoutez des restrictions IP ou HTTP referrer, et surtout, utilisez des comptes de service plutôt que des clés API pour tout ce qui touche à Gemini (sauf si vous aimez les surprises sur votre facture ^^).

Le truc tordu, c'est que la doc Firebase dit noir sur blanc que les clés API ne sont pas des secrets. Google Maps vous dit carrément de les coller dans votre HTML. Et maintenant, ces mêmes clés donnent accès à une IA qui peut lire vos fichiers. Du CWE-1188 pur et dur ! Et c'est pas la première fois que Google se fait taper sur les doigts pour ce genre de souci avec Gemini .

Du coup, Google a annoncé des nouvelles mesures, du scoped defaults, du blocage de clés fuités, des notifications proactives...etc. Reste donc à voir si ça arrivera avant que les presque 3000 clés exposées soient exploitées par des gens moins bien intentionnés.

Bref, dix ans à dire que c'est public, et hop, aujourd'hui c'est devenu top secret. Bien joué Google !!

Source

❌