Analyse approfondie

RCE par appel vocal sur Telegram pour Android, corrigée dans 12.10.4

Telegram pour Android 8.6.2 à 12.10.3 laissait un appelant exécuter du code si la victime répondait. Aucune exploitation connue. Corrigé dans 12.10.4.

Ostorlab Team 29 octobre 2026

En bref

Une faille de Telegram pour Android permettait à un attaquant d’exécuter du code sur le téléphone d’une victime par un appel vocal dès que la victime répondait, comme l’a divulgué la société de sécurité NebuSec le 29 octobre 2026. L’attaquant n’avait besoin que d’un compte Telegram ordinaire, et NebuSec a confirmé l’exécution sur des téléphones ARM64. Il n’existe ni identifiant CVE ni score CVSS au 29 octobre 2026.
Toutes les versions de 8.6.2, publiée en mars 2022, à 12.10.3, publiée en septembre 2026, sont affectées, selon NebuSec. Telegram pour iOS a livré le correctif dans 12.7 en mai et Telegram Desktop dans 7.0.1 en juillet, si bien qu’Android a été la dernière plateforme à le recevoir.
Aucune exploitation lors d’attaques réelles n’est connue : The Hacker News a demandé à NebuSec et à Telegram si la faille avait été utilisée, et aucun des deux n’avait répondu publiquement au 29 octobre. Aucune analyse technique ni code de preuve de concept n’étaient publics à cette date ; la démonstration est la vidéo de NebuSec.
Mettez immédiatement à jour Telegram pour Android vers 12.10.4 ou ultérieur. Le numéro de version apparaît en bas de la page Réglages de l’application.

Suis-je concerné ?

Vous êtes concerné si vous utilisez Telegram pour Android dans une version de 8.6.2 à 12.10.3. Ces versions sont sorties entre mars 2022 et septembre 2026 : toute installation non mise à jour depuis fin septembre 2026 est donc dans la plage.

Vérifiez la version sur le téléphone : ouvrez Telegram, ouvrez Réglages et lisez le numéro de version affiché en bas de la page. Sur un téléphone équipé d’une version plus ancienne, la fiche Google Play de Telegram affiche un bouton Mettre à jour.

La faille se trouve dans le code que les deux applications d’un appel s’échangent, donc l’exposition suppose un appel vocal auquel la victime répond.

Telegram pour iOS et Telegram Desktop ont livré le correctif de la bibliothèque avant Android (iOS 12.7 en mai 2026, Desktop 7.0.1 en juillet 2026). NebuSec n’a aucune preuve que la faille les affecte, ni les appels de groupe (voir la FAQ).

Comment corriger le problème ?

Mettez à jour Telegram pour Android via Google Play :

Installez la version 12.10.4 ou ultérieure.
Ouvrez Réglages et confirmez le numéro de version en bas de la page.

Telegram n’avait publié ni avis ni solution de contournement au 29 octobre 2026, et aucune configuration autre que la mise à jour ne supprime la faille.

Refuser les appels de comptes inconnus évite le déclencheur, car la faille suppose que la victime réponde. Cela ne corrige pas la faille et ne constitue pas une recommandation de l’éditeur.

Pour un parc d’appareils, lisez la version installée dans le rapport d’applications de votre outil de gestion d’appareils mobiles pour le package org.telegram.messenger, le nom de package de Telegram pour Android sur Google Play.

Quelle est la cause racine ?

Le code qui analyse un message d’appel MediaState validait un champ puis lisait l’itérateur d’un autre champ facultatif, donc un message qui omettait le second champ faisait déréférencer l’itérateur de fin de la map et toucher de la mémoire qu’il ne devait pas.

Pendant un appel Telegram, les deux applications s’envoient de courts messages pour établir l’appel et signaler son état. L’un d’eux, MediaState, indique si le micro est coupé, si la caméra est active et comment la vidéo est pivotée.

Le code d’analyse se trouve dans la copie embarquée de tgcalls, la bibliothèque que les applications Android, iOS et de bureau de Telegram utilisent pour les appels, dans TMessagesProj/jni/voip/tgcalls/v2/Signaling.cpp. Il utilise json11, dont le Json::object est une std::map<std::string, Json>, et object.find() renvoie l’itérateur end() de la map quand le champ est absent.

L’analyseur commence correctement : il cherche le champ facultatif videoState et, si le champ est absent, prend la branche par défaut, laissant l’itérateur videoState pointer sur end() :

const auto videoState = object.find("videoState");
if (videoState != object.end()) {
    ...
} else {
    message.videoState = MediaStateMessage::VideoState::Inactive;
}

La faille se trouve dans le bloc suivant, qui analyse la rotation vidéo. Il cherche videoRotation, vérifie que la valeur est un nombre, puis lit la rotation depuis le mauvais itérateur : chaque comparaison lit videoState->second, l’itérateur du champ facultatif qui peut ne pas exister, au lieu de l’itérateur videoRotation qu’il vient de valider. Voici le code de la version 12.10.3 :

const auto videoRotation = object.find("videoRotation");
if (videoRotation != object.end()) {
    if (!videoRotation->second.is_number()) {
        RTC_LOG(LS_ERROR) << "Signaling: videoRotation must be a number";
        return absl::nullopt;
    }
    if (videoState->second.int_value() == 0) {              // reads videoState, not videoRotation
        message.videoRotation = MediaStateMessage::VideoRotation::Rotation0;
    } else if (videoState->second.int_value() == 90) {      // reads videoState, not videoRotation
        message.videoRotation = MediaStateMessage::VideoRotation::Rotation90;
    } else if (videoState->second.int_value() == 180) {     // reads videoState, not videoRotation
        message.videoRotation = MediaStateMessage::VideoRotation::Rotation180;
    } else if (videoState->second.int_value() == 270) {     // reads videoState, not videoRotation
        message.videoRotation = MediaStateMessage::VideoRotation::Rotation270;
    } else {
        ...
    }
}

Un message MediaState qui porte un nombre videoRotation mais pas de chaîne videoState, une forme que le code d’analyse sait par ailleurs tolérer, fait déréférencer end() dans les comparaisons. La description de NebuSec correspond : le code « ne gérait pas correctement les champs absents et accédait à de la mémoire à laquelle il ne devait pas ». La manière dont NebuSec a transformé cette lecture en exécution de code sur téléphones ARM64 n’avait pas été publiée au 29 octobre 2026.

Comment la faille est-elle exploitée ?

Aucun code de preuve de concept n’est public, donc les étapes ci-dessous suivent la divulgation de NebuSec et sa vidéo de démonstration telles que rapportées par The Hacker News.

L’attaquant, qui n’a besoin que d’un compte Telegram ordinaire, passe un appel vocal à la victime depuis l’application.
La victime répond. À partir de ce moment, les deux applications échangent les courts messages d’établissement et d’état qui portent l’appel.
Le client de l’attaquant envoie un message MediaState conçu pour la faille : un nombre videoRotation est présent et le champ facultatif videoState est omis.
L’application de la victime analyse le message, valide le nombre de rotation, puis lit la rotation via l’itérateur videoState qui pointe au-delà des champs du message.
L’analyseur lit de la mémoire qu’il ne devrait pas, et la démonstration de NebuSec montre le téléphone sous le contrôle de l’attaquant : environ une demi-minute après le début de l’appel, le téléphone de la victime passe à son écran d’accueil, les icônes d’applications tombent de l’écran et un logo « HACKED BY NEBUSEC » apparaît.

Quel est le déroulement de l’attaque ?

La chaîne tient dans un message : la victime répond à un appel, l’attaquant envoie un message MediaState avec un champ présent et un absent, et l’analyseur lit au-delà d’un itérateur de fin dans une mémoire qu’il ne devait pas toucher.

flowchart LR A["L’attaquant passe un appel
vocal Telegram"] --> B["La victime répond à l’appel"] B --> C["L’attaquant envoie un message MediaState :
videoRotation présent,
videoState omis"] C --> D["L’analyseur valide videoRotation,
puis le lit via l’itérateur
videoState"] E["La recherche videoState a renvoyé end() :
le champ est absent"] --> D D --> F["Lecture hors limites via
l’itérateur de fin"] F --> G["Exécution de code sur le téléphone
ARM64 de la victime, selon NebuSec"]

Que peut faire un attaquant ?

Un attaquant peut exécuter du code sur le téléphone de la victime depuis un appel auquel la victime répond, sans plus de privilège qu’un compte Telegram ordinaire côté appelant. NebuSec a confirmé l’exécution lors d’appels en tête-à-tête sur des téléphones ARM64. La vidéo montre l’appareil changer d’écran et afficher le logo de l’attaquant.

Les conditions dont l’attaque a besoin :

Une version de Telegram pour Android de 8.6.2 à 12.10.3 sur le téléphone de la victime. Le code d’appel qui utilise ce message a été activé dans la version 8.6.2, la première version citée par NebuSec.
La victime répond à un appel vocal entrant. L’interaction utilisateur est la seule barrière : la faille se déclenche après la réponse, pas à la sonnerie.
Un appel en tête-à-tête sur Android : aucune preuve n’étend l’impact à Telegram pour iOS, à Telegram Desktop ni aux appels de groupe (voir la FAQ).

NebuSec a divulgué la faille le 29 octobre 2026. The Hacker News a demandé à NebuSec et à Telegram si la faille avait été utilisée lors d’attaques réelles. Il a aussi demandé ce que le code d’un attaquant pouvait atteindre sur un téléphone. Aucune des deux entreprises n’avait publié de réponse au 29 octobre.

Pourquoi le correctif fonctionne-t-il ?

Le correctif, dans la version 12.10.4, lit la rotation depuis l’itérateur qu’il a validé. Chaque comparaison du bloc passe de videoState->second.int_value() à videoRotation->second.int_value() :

if (videoRotation->second.int_value() == 0) {
    message.videoRotation = MediaStateMessage::VideoRotation::Rotation0;
} else if (videoRotation->second.int_value() == 90) {
    message.videoRotation = MediaStateMessage::VideoRotation::Rotation90;
} else if (videoRotation->second.int_value() == 180) {
    message.videoRotation = MediaStateMessage::VideoRotation::Rotation180;
} else if (videoRotation->second.int_value() == 270) {
    message.videoRotation = MediaStateMessage::VideoRotation::Rotation270;
} else {
    ...
}

Le bloc avait déjà vérifié que videoRotation->second est un nombre avant la première comparaison, donc lire cette même valeur ne peut plus sortir des champs du message. La même modification de quatre lignes a été faite dans la seconde copie de l’analyseur que l’application compile, v2_4_0_0/Signaling_4_0_0.cpp, qui contenait la même erreur. Un champ videoState absent retombe toujours sur sa valeur par défaut, Inactive.

Le correctif a atteint les plateformes à des moments différents. La même correction a été faite dans la bibliothèque partagée tgcalls le 21 avril 2026, dans un commit intitulé « Fix camera rotation », et les plateformes l’ont reprise une à une : Telegram pour iOS l’a incluse à partir de la version 12.7, publiée en mai 2026, et Telegram Desktop à partir de la version 7.0.1, publiée en juillet 2026. Telegram pour Android l’a reçue dans 12.10.4 en septembre 2026, parce que l’application Android embarque sa propre copie de la bibliothèque, dans TMessagesProj/jni/voip/tgcalls, que chaque plateforme met à jour séparément.

Android a reçu le correctif 156 jours après la bibliothèque partagée — Figure 1 : le correctif tgcalls du 21 avril 2026 n’a atteint l’application Android qu’avec 12.10.4 le 24 septembre 2026. Source : commits TelegramMessenger/tgcalls et DrKLO/Telegram, consultés le 29 octobre 2026.

Comment vérifier si j’ai été compromis ?

Aucun indicateur de compromission n’existe, car aucune exploitation n’a été signalée. La divulgation de NebuSec décrit la faille, et ni l’entreprise ni Telegram n’ont déclaré au 29 octobre 2026 qu’elle avait été utilisée contre quiconque.

La divulgation ne fournit rien à chercher non plus : l’attaque emprunte les mêmes messages MediaState qu’un échange d’appel ordinaire, et la lecture hors limites de l’analyseur ne laisse aucun artefact nommé dans une source publique. Considérez la mise à jour comme la réponse, et considérez tout téléphone encore en 12.10.3 ou antérieur comme exposé, pas comme compromis.

Chronologie

Mars 2022 : la version 8.6.2 sort, première version citée comme affectée par NebuSec et, selon l’analyse de code de The Hacker News, version qui a activé le code d’appel utilisant ce message.
2026-04-21 : la correction arrive dans la bibliothèque partagée tgcalls, dans le commit « Fix camera rotation ».
Mai 2026 : Telegram pour iOS inclut la bibliothèque corrigée à partir de la version 12.7.
Juillet 2026 : Telegram Desktop inclut la bibliothèque corrigée à partir de la version 7.0.1.
2026-09-17 : Telegram pour Android 12.10.3, dernière version affectée, est commité.
2026-09-24 : Telegram pour Android 12.10.4, qui corrige la faille, est commité, dans une version que The Hacker News date de fin septembre.
2026-10-29 : NebuSec divulgue la faille.

FAQ

Quelles versions de Telegram pour Android sont affectées ?

Toutes les versions de 8.6.2 à 12.10.3, selon NebuSec, soit toutes les sorties de mars 2022 à septembre 2026. La version 12.10.4, commitée le 24 septembre 2026, est la première version corrigée, et la version à vérifier est 12.10.4 ou ultérieure.

Telegram pour iOS ou Telegram Desktop sont-ils affectés ?

Pas de façon démontrée. Les trois applications partagent la bibliothèque d’appels tgcalls où vivait la faille, mais iOS a inclus la bibliothèque corrigée à partir de la version 12.7 en mai 2026 et Desktop à partir de 7.0.1 en juillet 2026, avant le correctif Android en septembre. NebuSec n’a aucune preuve que la faille affecte directement ces applications ni les appels de groupe, et The Hacker News indique que rien ne montre que le code antérieur pouvait y être exploité.

Existe-t-il un CVE ou un score CVSS ?

Non. La faille n’avait pas d’identifiant CVE au 29 octobre 2026, et aucun score CVSS n’avait été publié pour elle non plus. L’énoncé d’impact vient de la divulgation de NebuSec : le code de l’attaquant s’exécute sur le téléphone de la victime quand celle-ci répond à l’appel.

La faille est-elle exploitée lors d’attaques réelles ?

Aucune utilisation réelle n’a été signalée au 29 octobre 2026 ; ni NebuSec ni Telegram n’a dit publiquement si la faille avait été utilisée. La faille n’est pas dans le catalogue CISA Known Exploited Vulnerabilities, qui ne suit que les identifiants CVE.

Y a-t-il une preuve de concept avec laquelle tester ?

Seulement une vidéo. La démonstration de NebuSec montre deux téléphones, l’un marqué comme attaquant et l’autre comme victime, le téléphone de la victime passant sous le contrôle de l’attaquant environ une demi-minute après le début de l’appel. La vidéo n’indique pas quelle version de Telegram ou d’Android le téléphone de la victime exécutait, et aucune analyse technique de la faille n’était sur le site de NebuSec au 29 octobre 2026.

Les appels de groupe exposent-ils le même chemin ?

Aucune preuve ne le dit. La divulgation de NebuSec couvre les appels entre deux parties, où les applications échangent directement des messages MediaState, et l’entreprise n’a aucune preuve que les appels de groupe soient affectés.

Analysez vos applications Android avec Ostorlab

Lancez un scan mobile Ostorlab sur les applications Android que vous développez ou distribuez : il analyse le package de l’application, y compris les bibliothèques natives qu’il embarque, pour que les composants vulnérables soient signalés avant qu’une version n’atteigne les utilisateurs.

Références

The Hacker News, « Telegram Android Flaw Lets Attackers Run Code When Users Answer Voice Calls », 29 octobre 2026, avec la plage affectée de NebuSec, la confirmation ARM64, les versions de correctif iOS et de bureau, et l’analyse au niveau du code des versions défaillante et corrigée : https://thehackernews.com/2026/10/telegram-android-flaw-lets-attackers.html (consulté le 29 octobre 2026)
Divulgation de NebuSec sur X, 29 octobre 2026, citée par The Hacker News : https://x.com/nebusecurity/status/2115601122727702634 (consultée le 29 octobre 2026)
Source de Telegram pour Android version 8.6.2, commit « Update to 8.6.2 » du 20 mars 2022, qui ajoute tgcalls/v2/Signaling.cpp à la compilation et le protocole d’appel 4.0.0 aux versions disponibles : https://github.com/DrKLO/Telegram/commit/0abe4541ddbafa65bb79beff5d81c452c7e9626d (consultée le 29 octobre 2026)
Source de Telegram pour Android version 12.10.3, l’analyseur MediaStateMessage_parse défaillant dans la copie embarquée de tgcalls, commit « update to 12.10.3 (7089) » du 17 septembre 2026 : https://github.com/DrKLO/Telegram/blob/9552e5541e1274b9557c9832b204dbfcaf44b3dc/TMessagesProj/jni/voip/tgcalls/v2/Signaling.cpp#L720-L740 (consultée le 29 octobre 2026)
Source de Telegram pour Android version 12.10.4, le bloc d’analyse corrigé, commit « update to 12.10.4 (7099) » du 24 septembre 2026 : https://github.com/DrKLO/Telegram/blob/c84801762fd5f936c8296ecf09a14a48ebfc4fe4/TMessagesProj/jni/voip/tgcalls/v2/Signaling.cpp#L727-L747 (consultée le 29 octobre 2026)
Commit de correction en amont tgcalls, « Fix camera rotation », 21 avril 2026, qui modifie v2/Signaling.cpp et v2_4_0_0/Signaling_4_0_0.cpp : https://github.com/TelegramMessenger/tgcalls/commit/a6ea40ebf18233fad5aae29aa3d30561f839a6a8 (consulté le 29 octobre 2026)
Telegram pour iOS version 12.7, dont le sous-module tgcalls pointe sur le commit de correction : https://github.com/TelegramMessenger/Telegram-iOS/tree/release-12.7/submodules/TgVoipWebrtc (consultée le 29 octobre 2026)
Telegram Desktop 7.0.1, publiée le 14 juillet 2026, première version de bureau dont le sous-module tgcalls inclut le correctif : https://github.com/telegramdesktop/tdesktop/releases/tag/v7.0.1 (consultée le 29 octobre 2026)
Telegram pour Android sur Google Play, le bouton Mettre à jour de la fiche : https://play.google.com/store/apps/details?id=org.telegram.messenger (consultée le 29 octobre 2026)
Flux JSON du catalogue CISA Known Exploited Vulnerabilities, vérifié le 29 octobre 2026 pour l’absence d’identifiant de cette faille : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

Tags :

security, Android, Telegram, remote code execution, vulnerability