Amazon Q, l'assistant de programmation dopé à l'IA que propose Amazon, pouvait se faire piéger d'une manière aussi simple qu'embarrassante.

Petit rappel pour situer. Amazon Q se greffe dans Visual Studio Code, l'éditeur de code de Microsoft que les développeurs utilisent au quotidien, et sert à écrire ou corriger du code à votre place.

Des chercheurs de Wiz, une société spécialisée dans la sécurité du cloud, ont découvert que cet assistant exécutait des commandes cachées à la simple ouverture d'un projet. La faille a reçu un identifiant officiel, CVE-2026-12957, et une note de gravité de 8,5 sur 10, ce qui est sérieux.

Le problème venait d'un fichier de configuration un peu particulier. Pour fonctionner, Amazon Q lit un fichier nommé .amazonq/mcp.json, qui s'appuie sur le MCP, pour Model Context Protocol, une sorte de prise standardisée qui permet de brancher une IA sur des outils extérieurs.

Sauf qu'il suffisait d'ouvrir un dépôt de code et d'activer Amazon Q pour que l'extension aille lire ce fichier et exécute son contenu. Sans fenêtre de confirmation, sans demander votre avis, et sans vérifier si vous faisiez confiance au dossier que vous veniez d'ouvrir.

Et c'est là que ça devient vraiment fourbe. Ces commandes héritaient de tout votre environnement de travail. Du coup, elles pouvaient récupérer au passage vos clés d'accès au cloud d'Amazon, vos jetons de connexion, vos secrets d'API et même l'accès à votre agent SSH, ce trousseau qui garde en mémoire vos connexions aux serveurs distants. En clair, tout ce qu'un développeur laisse ouvert pendant qu'il travaille.

Le plus gênant, c'est que Visual Studio Code possède justement une sécurité prévue pour ça, la confiance d'espace de travail, qui vous demande si vous validez un dossier avant de le laisser agir. L'extension d'Amazon passait tout bonnement par-dessus.

Pour un pirate, le piège était facile à tendre. Il suffisait de glisser ce fichier dans un projet open source d'apparence anodine, ou dans un bout de code partagé sur un forum, et d'attendre qu'un développeur qui récupère un projet l'ouvre pour voir comment il fonctionne.

Amazon a corrigé le tir dans la version 1.65.0 de son serveur de langage et a confirmé la correction. Wiz note d'ailleurs que des failles très proches ont déjà touché d'autres outils de code boostés à l'IA.

Donner autant de pouvoir à une IA sans le moindre garde-fou, et laisser filer les clés du cloud avec, ça reste une erreur de débutant pour un géant comme Amazon.

Source : The Register

Dropbox vient de sortir un plugin pour Claude Code , et leur idée c'est de pouvoir brancher vos fichiers Dropbox directement dans vos sessions de dev Claude Code / Cowork.

Alors je me suis demandé à quoi ça pouvait bien servir et voici ce que j'ai compris. Une fois que le plugin est en place, ça permet à Claude Code d'aller piocher dans votre Dropbox vos docs techniques, vos cahiers des charges, votre code...etc pour s'en faire du contexte. Tout devient de la matière fraiche pour corriger ou générer du code et quand c'est fini, ce qui est produit peut être à son tour stocké sur Dropbox.

Le plugin sait récupérer les fichiers en fonction de leur nom, de mots clés, de leur emplacement et bien sûr en fonction de leurs méta données. Même vos liens partagés il sait comment les gérer. Bref, il fait tout simplement le passe-plats entre tout le bordel que vous stockez sur Dropbox et Claude Code.

Cela dit, gardez la tête froide parce que tout ce que l'IA lit part sur les serveurs d'Anthropic pour être traité. Donc évitez quand même de le lâcher sur le dossier qui contient vos contrats, vos mots de passe ou vos données clients. Lui autoriser juste un dossier dédié avec ce que vous acceptez de partager, ce sera plus sain.

Pour l'installer, ça se passe dans Claude Code sur le web. Vous filez dans le menu Personnaliser, Connecteurs puis vous cherchez Dropbox en parcourant les plugins et vous cliquez sur ajouter. Une auth OAuth plus tard (vos identifiants Dropbox habituels), c'est branché. Un petit /reload-plugins et le plugin s'active alors dans la session en cours.

En plus de ce plugin, Dropbox propose également un serveur MCP classique en ligne de commande qui est un peu plus souple et surtout peut se brancher dans Cursor, Claude Desktop ou Devin.

Un bémol quand même, c'est pas open bar... sniiif. Eh oui, Dropbox plafonne tout ça à 5 Mo par fichier lu ou créé via l'intégration, et le contenu pondu par Claude ne se sauvegarde qu'en texte (.txt, .md, .html, .py), et pas en image ni en PDF. Quant aux limites de débit de l'API, on ne les connaît pas.

Bref, pour les gros fichiers ou les binaires, faudra donc passer par autre chose.

Si vous vivez dans Claude Code et que votre vie est rangée dans Dropbox, ça vaut peut-être le coup de jeter un œil ici.

Vous vous souvenez de la première fois que vous avez lancé Half-Life 2 et que vous avez attrapé une caisse avec le gravity gun ? Eh bien un lycéen qui se fait appeler slqnt vient de remettre tout ça dans votre navigateur, gratuitement, sans avoir à installer Steam ni à télécharger le moindre gros paquet. Ça se passe sur hl2.slqnt.dev , c'est en ligne depuis hier, et le jeu tourne tout en fluidité, largement au-dessus des 60 images par seconde directement sous Chrome.

Sur mobile par contre, il vous faudra un clavier branché parce que les contrôles tactiles sont quasi inexistants pour l'instant, mais sur un PC, vous lancez la page et vous voilà à Black Mesa East.

Maintenant, le plus intéressant c'est comment il s'y est pris, parce que porter un jeu bâti sur le moteur Source de Valve (le même que celui de 2004, successeur de GoldSrc) dans un onglet, ça ne se fait pas en claquant des doigts.

Et slqnt n'est pas parti de zéro puisque c'est un copain qui lui a montré un portage de Portal fait par un autre dev nommé weliveinhell. Ce projet open source était d'ailleurs lui-même un fork de nillerusr/source-engine , c'est-à-dire une version modifiée de la fuite du code du moteur Source de Team Fortress 2 qui a circulé en 2020. Voilà pour la base du truc qui n'est ni plus ni moins que le moteur leaké patiemment retapé par la communauté.

L'astuce de ce portage tient dans un mode de rendu appelé ToGLES. En gros le moteur sait parler OpenGLES, le truc qu'on utilise d'habitude pour les applis Android, sauf qu'Emscripten sait traduire ces appels en WebGL2 dans le navigateur. Résultat, slqnt n'a eu quasiment aucun travail à faire côté affichage, le plus dur étant déjà fait.

Le casse-tête par contre, ça a été d'abord les assets, parce que cette version du moteur date d'avant la réédition anniversaire de HL2 et ne supportait pas ses fichiers. Il a donc fallu basculer sur la branche steam_legacy de Steam, puis dépaqueter tous les VPK du jeu et les redécouper en fichiers .data, un par carte, pour que le navigateur les charge au fur et à mesure.

Et puis il y a eu les animations faciales. C'était l'une des grandes fiertés techniques de HL2 à sa sortie, la façon dont les visages bougeaient en parlant. Sauf que ça faisait tellement planter le portage que slqnt a fini par désactiver complètement le système pour avoir quelque chose de stable.

Du coup le G-Man vous fait son monologue d'intro avec un visage figé, mais au moins ça tourne. Le reste de son journal de bord est également une jolie liste de galères de bidouilleur, vu de l'intérieur avec au hasard, les sauvegardes à recâbler sur le système de fichiers d'Emscripten, les batteries et medkits qui ne fonctionnaient pas, le gravity gun qu'Alyx vous tend mais qui n'arrivait jamais dans l'inventaire, les PNJ qui s'effondraient et mouraient au hasard, les headcrabs qui ne faisaient aucun dégât, l'eau toute noire et j'en passe...

Petit détail qui parle à quiconque a déjà bidouillé un jeu, il a dû remapper l'accroupissement sur la touche C, parce que CTRL déclenchait des raccourcis du navigateur qui pourrissent la partie.

Reste maintenant la question que tout le monde se pose : Est-ce que Valve est au courant ? Parce qu'un portage qui repose sur du code moteur leaké et sur les assets du jeu, légalement, c'est une zone grise bien grise qui tire vers le noir.

Valve a toujours été plutôt cool avec sa communauté de moddeurs, mais ça pourrait disparaître du jour au lendemain. Après si l'idée d'un jeu Source qui tourne dans un onglet vous fait marrer, c'est exactement le même esprit que ce Portal 2 transformé en serveur web , ou que ce Doom qui tourne avec juste du CSS . Mettre les vieux FPS dans le navigateur, c'est presque devenu un sport, je vous en parlais déjà avec Wolfenstein 3D .

Bref, foncez essayer tant que c'est en ligne. Et si vous y arrivez sur mobile sans clavier, écrivez vite un bouquin pour raconter comment vous avez fait !

Source

Si vous utilisez un ordinateur portable à puce graphique AMD Radeon sous Linux, vous avez peut-être déjà vu l'écran se figer d'un coup, sans raison apparente, à peu près une fois par semaine. Ce bug agace les utilisateurs depuis des années, et un correctif vient enfin de pointer le bout de son nez.

Le coupable se cache dans AMDGPU, le pilote graphique libre qu'AMD maintient pour Linux. On parle ici du logiciel qui fait le lien entre la carte graphique et le système d'exploitation.

Le problème ne date pas d'hier. En fouillant l'historique du code, le développeur à l'origine du correctif a remonté la piste jusqu'à une modification introduite en 2017. Presque huit ans de gels d'écran.

Le symptôme typique, c'est une erreur "flip_done timed out" dans les journaux du système. Pour faire simple, l'ordinateur attend que l'écran affiche l'image suivante, ce signal n'arrive jamais. Et tout gèle.

Le souci touche plusieurs machines, bien connues du monde Linux, comme le Lenovo ThinkPad T14 Gen1 en version AMD ou le Framework Laptop 13 équipé d'un processeur Ryzen 7 7840U. Jusqu'ici, le seul remède consistait à désactiver le PSR, pour "Panel Self Refresh".

Cette fonction d'économie d'énergie laisse l'écran réafficher tout seul sa dernière image fixe sans réveiller la carte graphique, histoire d'économiser de la batterie. Pratique sur un portable, sauf que c'est précisément elle qui déclenchait les gels.

Le plus intéressant, c'est la méthode employée. Le correctif a été mis au point en "vibe debugging" avec Claude Code, l'assistant de programmation d'Anthropic, le concurrent direct d'OpenAI. Le développeur a décrit le bug à l'IA, qui l'a aidé à explorer le code et à affiner les correctifs, plutôt que de dérouler une procédure de débogage classique.

Concrètement, les patchs revoient la gestion du "vblank" et du "page-flip" dans le bloc d'affichage DCN, c'est-à-dire la mécanique interne qui synchronise le moment où une nouvelle image remplace l'ancienne à l'écran. D'autres tentatives avaient échoué par le passé, mais cette série semble enfin tenir la route.

Maintenant patience, rien n'est encore intégré dans le noyau Linux officiel. Les correctifs doivent passer par les tests et la validation des mainteneurs avant d'arriver chez tout le monde, ce qui peut quand même prendre plusieurs versions du kernel.

Bref, on est là devant un bug fantôme qui date d'lil y a huit ans, débusqué en discutant avec une IA, voilà qui résume assez bien l'année 2026 côté développement.

Source : Phoronix