Menu

PixelLeak : 13 000 captures d’écran internes publiées par des agents de code, sans attaquant et sans que personne l’ait demandé

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
3 min de lecture
⏱️
Temps de lecture estimé
~7 minutes

Pour joindre une capture d’écran à une pull request, des agents de code ont créé des dépôts publics sous les comptes personnels de développeurs. Glow Labs en a compté plus de 13 000 images internes, issues de plus de 300 organisations, dont des écrans de facturation et de trésorerie.

Un incident sans attaquant

Un développeur demande à son agent de changer la couleur d’un en-tête et de montrer le résultat dans la pull request, avant et après. Banal. L’agent fait le changement, prend ses captures, et se heurte à un détail : en ligne de commande, il ne sait pas les joindre à la PR. GitHub n’affichait les pièces jointes que depuis le navigateur.

Il fait alors ce que ferait un collègue obligeant : il trouve un moyen. Il crée un dépôt voisin, public, y pose les images, et les référence depuis la pull request privée. Le relecteur voit les captures. Tout le monde est content, sauf que ces captures montrent des registres de facturation clients, des consoles de trésorerie et des écrans de retrait nominatifs.

C’est ce que Glow Labs a baptisé PixelLeak. L’entreprise a contacté les organisations concernées à partir du 9 septembre, puis publié ses conclusions le 29. Les chiffres : plus de 13 000 images internes, plus de 300 organisations, plus de 900 dépôts. Dans la liste, un laboratoire d’IA majeur, un éditeur de logiciels d’entreprise, un groupe du Fortune 500 dans les voyages et des acteurs du cloud, de la santé, de la fintech et du secteur public.

Note du PandaRedacteur : ni 0-day, ni phishing, ni panda en capuche. Treize mille écrans internes en clair parce qu’un agent voulait que son relecteur voie le bouton. Les analystes de menaces vont devoir inventer une catégorie pour « zèle ».

Le mécanisme, en cinq temps

  1. Le développeur demande une modification d’interface avec preuve visuelle.
  2. L’agent, qui travaille en ligne de commande, ne peut pas utiliser le chemin d’envoi d’images réservé au navigateur.
  3. Il contourne l’obstacle en créant ou en réutilisant un dépôt public adjacent, généralement sous le compte personnel du développeur.
  4. Il lie les images depuis la pull request privée.
  5. Les images restent publiques après la fusion de la PR.

Glow a reproduit le comportement en lab sur un projet de démo : l’agent a créé de lui-même un dépôt public (sweeper-demo/pr-assets) en notant que les images stockées dans le dépôt privé s’afficheraient cassées pour les relecteurs. Il n’a pas hésité, il a justifié. Claude Code avec Opus 5 faisait partie des configurations testées, et le phénomène touche plusieurs modèles d’éditeurs différents.

Voilà pour l’incident et son mécanisme. Ce qui l’a industrialisé, ce que ça coûte et comment s’en protéger se trouve dans la version complète, et le menu est juste en dessous.

📬 Cette analyse est partie d'abord aux abonnés Substack
Mes analyses sortent en avant-première sur ma newsletter Substack, avant d'être publiées ici. Pour les recevoir dès leur sortie, abonnez-vous ; vous pouvez aussi relire cette analyse sur Substack et la commenter.

Au menu de la version abonnés :
  • l'outil gitshot et son comportement par défaut, qui explique l'ampleur de la fuite ;
  • le skill partagé qui a fait partir plus de 1 000 captures en une semaine, et pourquoi 93 % des cas échappent aux contrôles habituels ;
  • l'analyse STRIDE et le tableau d'impact ;
  • les mitigations concrètes et un script de détection ;
  • et la sketchnote du PandaRedacteur résumant tout cela en anglais.

📚 Quelques références pour aller plus loin

LinkedIn Reddit Substack