L’architecture de chiffrement des données locales de Telegram est en théorie irréprochable. Les données de session des utilisateurs sont chiffrées au moyen d’une clé de chiffrement de données dédiée (DEK), elle-même protégée par une clé de chiffrement de clé (KEK) dérivée du code d’accès de l’utilisateur. Pourtant, sous l’environnement de bureau Windows, un simple lien malveillant a suffi à réduire à néant l’ensemble de ces défenses cryptographiques. Le chercheur en sécurité beaksec a divulgué la vulnérabilité CVE-2026-107181 affectant Telegram Desktop : en incitant la victime à cliquer sur un lien forgé, un attaquant pouvait déclencher l’envoi silencieux des fichiers clés de sa session vers un groupe ciblé, aboutissant à une prise de contrôle totale du compte.
VulnCheck, en tant qu’autorité de numérotation CVE (CNA), a attribué à cette vulnérabilité un score CVSS 4.0 de 8.6, contre un score CVSS 3.1 de base de 8.1. Cet écart s’explique par la pondération accrue que la nouvelle norme accorde aux répercussions systémiques en aval déclenchées par une interaction minime de l’utilisateur. Cette chaîne d’attaque a pu prospérer parce que Telegram Desktop a fait converger des appels internes de confiance et des entrées externes non fiables au sein d’un même canal de communication exempt de vérification. Lorsqu’un maillon en amont ne considère pas les données externes comme suspectes par défaut, la forteresse cryptographique la plus solide ne peut résister à la chute de ses frontières d’isolation.
Un délimiteur non échappé expose une porte dérobée interne
Le point de départ de l’attaque réside dans le traitement défaillant des délimiteurs d’enregistrements sur le socket local d’instance unique (CWE-143). Lorsqu’un utilisateur clique sur un lien externe alors que Telegram Desktop est déjà en cours d’exécution, le système d’exploitation transmet le lien à un nouveau processus. Ce dernier se connecte à l’instance principale via un socket local et lui soumet l’URI formaté sous la forme OPEN:<url>;, le destinataire découpant ensuite le flux selon les points-virgules pour identifier les commandes. La faille d’ingénierie réside dans l’absence d’échappement des points-virgules présents dans l’URL. Ni l’assemblage dans sandbox.cpp:295-297 ni la séparation dans sandbox.cpp:453-463 n’imposaient de restrictions sur les caractères spéciaux. Un lien piégé tel que tg://x?a=1;CMD:quit se retrouvait ainsi scindé en deux instructions distinctes, permettant à une entrée non fiable de s’échapper directement dans le flux d’exécution interne.
Schéma : Chaîne d’attaque depuis le clic sur un lien jusqu’à l’exfiltration des fichiers de session. Source : beaksec.github.io
L’instruction injectée prenait ensuite le relais du deuxième maillon : le schéma d’URI interne interpret:. D’après l’implémentation de application.cpp:1162-1164, l’application place le chemin d’accès correspondant dans sa file d’exécution. La fonction InterpretSendPath (située dans support_helper.cpp:673-680) lit alors le fichier local désigné par le fichier d’instructions et le transmet à un canal ou supergroupe prédéfini, sans aucun contrôle d’autorisation ni fenêtre de confirmation. À l’origine, ce protocole était un outil interne destiné au déploiement des mises à jour via le script de compilation build/updates.py. Le fichier d’instructions prévoyait bien un champ from: censé vérifier l’identité du compte actif, mais en l’absence de cette ligne, le mécanisme ignorait purement et simplement le contrôle. L’absence de rigueur dans l’analyseur revenait à livrer l’exécution de fonctions privilégiées internes à des assaillants distants.
Le téléchargement automatique assemble une chaîne d’exploitation déterministe
La vulnérabilité ouvrait un point d’entrée ; la concrétiser en prise de contrôle de compte nécessitait un enchaînement d’états d’une précision chirurgicale. L’attaquant commence par créer un supergroupe et y ajoute la victime, tirant parti des paramètres de confidentialité par défaut de Telegram qui autorisent l’ajout à des groupes sans accord préalable. Il envoie ensuite dans le groupe trois fichiers d’instructions en texte brut contenant des directives de lecture interpret: pointant vers les fichiers sensibles locaux de la cible. En profitant du téléchargement automatique par défaut des pièces jointes de moins de 8 MiB, ces trois fichiers sont enregistrés en silence dans C:\Users\<user>\Downloads\Telegram Desktop\.
Le protocole interpret: prend en charge les chemins relatifs résolus depuis le répertoire de travail de Telegram sous Windows (%APPDATA%\Telegram Desktop). Grâce au chemin ../../../Downloads/Telegram%20Desktop/instructions.txt, l’attaque atteint avec certitude les fichiers de charge utile sans avoir besoin de connaître le nom d’utilisateur Windows de la victime. L’attaquant publie ensuite dans le groupe un lien HTTP effectuant une redirection 302 vers l’adresse tg:// piégée. Dès que la cible clique dessus, l’injection s’exécute instantanément.
Les trois fichiers d’instructions lisent et transmettent les données requises pour le détournement de session : le fichier tdata/key_datas contenant le sel non chiffré, le fichier D877F783D5D3EF8Cs stocké dans un sous-dossier généré à partir du nom par défaut, et l’index associé maps. L’identifiant de dossier D877F783D5D3EF8C n’est pas aléatoire : il est dérivé de manière déterministe de la chaîne data, selon la logique documentée dans storage_file_utilities.cpp:241-250, produisant un résultat rigoureusement identique sur toute installation standard. En l’absence de mot de passe local défini, celui-ci équivaut à une chaîne vide. Grâce au sel extrait de key_datas, l’attaquant peut recalculer la KEK via les algorithmes publics, déchiffrer la DEK et reconstruire localement la session MTProto de la victime. Pris individuellement, le téléchargement automatique, les chemins relatifs et l’absence de mot de passe obligatoire sont des fonctionnalités ergonomiques courantes ; réunies dans le même contexte d’exécution, elles ont formé une chaîne d’attaque dévastatrice.
Quatre modifications du code source pour reconstruire les limites de communication
Face à ce scénario, Telegram a fait le choix de supprimer intégralement les fonctionnalités obsolètes. Lors du commit db3405699f du 16 septembre 2026, l’équipe de développement a appliqué quatre modifications majeures. En premier lieu, le schéma interpret:// et sa fonction d’envoi associée Support::InterpretSendPath ont été purement et simplement retirés de la base de code. En second lieu, les délimiteurs d’enregistrements du socket ont reçu un échappement hexadécimal avec préfixe pour cent, éliminant tout risque d’injection de commandes multiples. Deux assertions de durcissement sont venues compléter le dispositif : ignorer les enregistrements CMD: et CTRL: si OPEN: est présent sur la même connexion, et abandonner toute requête de chemin local ultérieure dès lors qu’une URL non locale est repérée.
Publiée dès le lendemain, la version 7.2.9 embarquait l’ensemble de ces correctifs. Toutefois, le journal des modifications n’évoquait que des corrections liées au moteur de rendu, passant sous silence l’avis de sécurité et l’impact de la vulnérabilité. Le calendrier montre que le signalement a été reçu par la ZDI le 25 juin 2026, que le correctif a été développé discrètement le 16 septembre, que la ZDI a clôturé le dossier le 30 septembre, avant que beaksec ne publie son analyse technique le 3 octobre et que le CVE ne soit officiellement attribué le 7 octobre. Cette pratique des correctifs silencieux prive les organisations des informations indispensables pour mesurer l’exposition au risque de leurs clients. À ce jour, la grille d’évaluation SSVC de la CISA classe l’exploitation au stade de “poc”, et la faille ne figure pas dans le catalogue KEV.
Trois lignes de défense pour bloquer l’attaque sans mise à jour
Les démonstrations de faisabilité ont été conduites sous Windows sur la version 6.9.3. Pour les utilisateurs ne pouvant pas basculer immédiatement vers la version 7.2.9 ou supérieure, certains réglages intégrés à l’application offrent une protection efficace. Activer l’option « Demander où enregistrer chaque fichier » dans les paramètres avancés neutralise l’hypothèse de chemin d’accès fixe sur laquelle repose l’attaque, empêchant les charges utiles d’atterrir dans le répertoire attendu. Restreindre la permission « Qui peut m’ajouter à des groupes » à « Mes contacts » évite qu’un agresseur n’enrôle de force la victime dans un groupe malveillant. De plus, il convient de rester méfiant face aux alertes de navigateur invitant à « Ouvrir Telegram » et de surveiller la liste des sessions actives pour déceler tout accès anormal.
La barrière la plus déterminante demeure d’ordre cryptographique : configurer un code de verrouillage local dans Telegram. L’exploitation repose sur le fait qu’aucun mot de passe local n’est paramétré, permettant un déchiffrement direct à l’aide des paramètres par défaut et du sel dérobé. Dès lors qu’un code local est défini, le système exige la saisie du mot de passe en clair pour dériver une KEK valide. Même si l’attaquant parvient à exfiltrer key_datas et les fichiers associés, il lui sera impossible d’accéder au contenu sans ce secret. Lorsque la logique applicative franchit les frontières de confiance, des réglages de sécurité stricts constituent le dernier rempart contre le piratage de compte.
Liens de référence :
- Analyse de la prise de contrôle en un clic sur Telegram Desktop (beaksec)
- Évaluation de la vulnérabilité et notation VulnCheck
