Telegram for Android Voice-Call RCE, Fixed in 12.10.4

TL;DR

• A flaw in Telegram for Android let an attacker run code on the victim's phone during a voice call once the victim answered. The security company NebuSec disclosed it on October 29, 2026. The attacker needed only an ordinary Telegram account, and NebuSec confirmed code execution on ARM64-based phones. There is no CVE identifier and no CVSS score as of that date.
• Every version from 8.6.2, released in March 2022, through 12.10.3, released in September 2026, is affected, according to NebuSec. Telegram for iOS shipped the fix in 12.7 in May and Telegram Desktop in 7.0.1 in July, so Android was the last platform to receive it.
• No exploitation in real attacks is known: The Hacker News asked NebuSec and Telegram whether the flaw had been used, and neither had answered publicly as of October 29. No technical write-up or proof-of-concept code was public as of that date; the demonstration is NebuSec's video.
• Update Telegram for Android to 12.10.4 or later now. The version number appears at the bottom of the app's Settings page.

Am I affected?

You are affected if you run Telegram for Android in a version from 8.6.2 through 12.10.3. Those versions came out between March 2022 and September 2026, so any installation that has not been updated since late September 2026 is in range.

Check the version on the phone: open Telegram, open Settings, and read the version number printed at the bottom of the page. On a phone with an older version, the Telegram listing on Google Play shows an Update button.

The bug sits in the messages the two apps exchange during a call, so exploiting it needs a voice call the victim answers.

Telegram for iOS and Telegram Desktop shipped the library fix before Android (iOS 12.7 in May 2026, Desktop 7.0.1 in July 2026). NebuSec has no evidence that the flaw affects them or group calls (see the FAQ).

How do I fix it?

Update Telegram for Android through Google Play:

1. Install version 12.10.4 or later.
2. Open Settings and confirm the version number at the bottom of the page.

Telegram had published no advisory and no workaround as of October 29, 2026, and no configuration other than the update removes the flaw.

Declining calls from accounts you do not know avoids the trigger, because the flaw needs the victim to answer. It does not patch the bug, and it is not vendor guidance.

For device fleets, read the installed version through your mobile device management tool's app report for the package org.telegram.messenger, the package name of Telegram for Android on Google Play.

What is the root cause?

The code that parses a MediaState call message validated one field and then read a different, optional field's iterator, so a message that omitted the second field made the parser dereference a map's end iterator and touch memory it should not.

During a Telegram call, the two apps send each other short messages to set up the call and report its state. One type, MediaState, reports whether the microphone is muted, whether the camera is on, and how the video is rotated.

The parsing code is in the app's vendored copy of tgcalls, the library Telegram's Android, iOS and desktop apps use for calls, at TMessagesProj/jni/voip/tgcalls/v2/Signaling.cpp. It uses json11, whose Json::object is a std::map<std::string, Json>, and object.find() returns the map's end() iterator when the field is absent.

The parser starts correctly: it looks up the optional videoState field, and if the field is absent it falls through to a default, leaving the videoState iterator pointing at end():

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

The bug is in the next block, which parses the video rotation. It looks up videoRotation, checks that the value is a number, and then reads the rotation from the wrong iterator: every comparison reads videoState->second, the iterator of the optional field that may not exist, instead of the videoRotation iterator it just validated. This is the code in 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 {
        ...
    }
}

A MediaState message that carries a videoRotation number but no videoState string, a shape the parse code is otherwise written to tolerate, makes the comparisons dereference end(). NebuSec's description matches: the code "did not handle missing fields correctly and accessed memory it should not". How NebuSec turned that read into code execution on ARM64 phones had not been published as of October 29, 2026.

How is it exploited?

No proof-of-concept code is public, so the steps below follow NebuSec's disclosure and demonstration video as reported by The Hacker News.

1. The attacker, who needs only an ordinary Telegram account, places a voice call to the victim from the app.
2. The victim answers. From that moment the two apps exchange the short setup and state messages that carry the call.
3. The attacker's client sends a MediaState message crafted for the bug: a videoRotation number is present and the optional videoState field is omitted.
4. The victim's app parses the message, validates the rotation number, then reads the rotation through the videoState iterator that points past the message's fields.
5. The parser reads memory it should not, and NebuSec's demonstration shows the phone under the attacker's control: about half a minute into the call, the victim's phone switches to its home screen, the app icons fall down the screen, and a "HACKED BY NEBUSEC" logo appears.

How does the attack flow?

The chain is one message long: the victim answers a call, the attacker sends a MediaState message with one field present and one missing, and the parser reads through an end iterator into memory it should not touch.

What can an attacker do?

An attacker can run code on the victim's phone from a call the victim answers, with no more privilege than an ordinary Telegram account on the caller's side. NebuSec confirmed the execution in one-to-one calls on ARM64-based phones. The video shows the device switching screens and displaying the attacker's logo.

The conditions the attack needs:

• A Telegram for Android version from 8.6.2 through 12.10.3 on the victim's phone. The calling code that uses this message was switched on in version 8.6.2, the first version NebuSec names.
• The victim answers an incoming voice call. The user interaction is the single gate: the flaw triggers after the call is answered, not at ring time.
• A one-to-one call on Android: no evidence extends the impact to Telegram for iOS, Telegram Desktop or group calls (see the FAQ).

NebuSec disclosed the flaw on October 29, 2026. The Hacker News asked NebuSec and Telegram whether the flaw had been used in real attacks. It also asked what an attacker's code could reach on a phone. Neither company had published an answer as of October 29.

Why does the fix work?

The fix, in version 12.10.4, reads the rotation from the iterator it validated. Every comparison in the block changes from videoState->second.int_value() to 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 {
    ...
}

The block had already checked that videoRotation->second is a number before the first comparison, so reading that same value can no longer walk past the message's fields. The same four-line change was made in the second copy of the parser that the app compiles, v2_4_0_0/Signaling_4_0_0.cpp, which had the same mistake. An absent videoState field still falls back to its default, Inactive.

The fix reached the platforms at different times. The same correction was made in the shared tgcalls library on April 21, 2026, in a commit titled "Fix camera rotation", and the platforms picked it up one by one: Telegram for iOS included it from version 12.7, released in May 2026, and Telegram Desktop from version 7.0.1, released in July 2026. Telegram for Android received it in 12.10.4 in September 2026, because the Android app carries its own vendored copy of the library, at TMessagesProj/jni/voip/tgcalls, which each platform updates separately.

How do I check if I was compromised?

No indicators of compromise exist, because no exploitation has been reported. NebuSec's disclosure describes the flaw, and neither the company nor Telegram has said the flaw was used against anyone as of October 29, 2026.

There is also nothing the disclosure equips a defender to hunt for: the attack rides the same MediaState messages an ordinary call exchange carries, and the parser's out-of-bounds read leaves no artifact named in any public source. Treat the update itself as the remediation, and treat any phone still on 12.10.3 or older as exposed, not as compromised.

Timeline

• March 2022: version 8.6.2 ships, the first version NebuSec names as affected and, per The Hacker News's source review, the release that switched on the calling code that uses this message.
• 2026-04-21: the correction lands in the shared tgcalls library, in the commit "Fix camera rotation".
• May 2026: Telegram for iOS includes the corrected library from version 12.7.
• July 2026: Telegram Desktop includes the corrected library from version 7.0.1.
• 2026-09-17: Telegram for Android 12.10.3, the last affected version, is committed.
• 2026-09-24: Telegram for Android 12.10.4, which fixes the flaw, is committed, in a release The Hacker News dates to late September.
• 2026-10-29: NebuSec discloses the flaw.

FAQ

Which versions of Telegram for Android are affected?

All versions from 8.6.2 through 12.10.3, per NebuSec, which is every release from March 2022 to September 2026. Version 12.10.4, committed on September 24, 2026, is the first fixed release, and the version number to check for is 12.10.4 or later.

Is Telegram for iOS or Telegram Desktop affected?

Not demonstrably. The three apps share the tgcalls call library the bug lived in, but iOS included the corrected library from version 12.7 in May 2026 and Desktop from 7.0.1 in July 2026, before the Android fix in September. NebuSec has no evidence the flaw directly affects those apps or group calls, and The Hacker News states that whether the earlier code could be exploited there has not been shown.

Is there a CVE or a CVSS score?

No. The flaw had no CVE identifier as of October 29, 2026, and no CVSS score had been published for it either. The impact statement comes from NebuSec's disclosure: the attacker's code runs on the victim's phone when the victim answers the call.

Is the flaw being exploited in real attacks?

No real-world use has been reported as of October 29, 2026; neither NebuSec nor Telegram has said publicly whether it was used. The flaw is not in the CISA Known Exploited Vulnerabilities catalog, which only tracks CVE identifiers.

Is there a proof of concept I can test with?

Only a video. NebuSec's demonstration shows two phones, one marked as the attacker and one as the victim, with the victim's phone under the attacker's control about half a minute into the call. The video does not show which Telegram or Android version the victim's phone was running, and no technical write-up of the flaw was on NebuSec's website as of October 29, 2026.

Do group calls expose the same path?

No evidence says so. NebuSec's disclosure covers calls between two parties, where the two apps exchange MediaState messages directly, and the company has no evidence that group calls are affected.

Scan your Android apps with Ostorlab

Run an Ostorlab mobile scan on the Android apps you build or ship: it analyzes the app package, including the native libraries it bundles, so vulnerable components are flagged before a release reaches users.

References

• The Hacker News, "Telegram Android Flaw Lets Attackers Run Code When Users Answer Voice Calls", October 29, 2026, with NebuSec's affected range, the ARM64 confirmation, the iOS and desktop fix versions and the source-level review of the buggy and fixed code: https://thehackernews.com/2026/10/telegram-android-flaw-lets-attackers.html (checked October 29, 2026)
• NebuSec's disclosure on X, October 29, 2026, as cited by The Hacker News: https://x.com/nebusecurity/status/2115601122727702634 (checked October 29, 2026)
• Telegram for Android version 8.6.2 source, commit "Update to 8.6.2" of March 20, 2022, which adds tgcalls/v2/Signaling.cpp to the build and call protocol 4.0.0 to the available versions: https://github.com/DrKLO/Telegram/commit/0abe4541ddbafa65bb79beff5d81c452c7e9626d (checked October 29, 2026)
• Telegram for Android version 12.10.3 source, the vulnerable MediaStateMessage_parse in the vendored tgcalls copy, commit "update to 12.10.3 (7089)" of September 17, 2026: https://github.com/DrKLO/Telegram/blob/9552e5541e1274b9557c9832b204dbfcaf44b3dc/TMessagesProj/jni/voip/tgcalls/v2/Signaling.cpp#L720-L740 (checked October 29, 2026)
• Telegram for Android version 12.10.4 source, the fixed parse block, commit "update to 12.10.4 (7099)" of September 24, 2026: https://github.com/DrKLO/Telegram/blob/c84801762fd5f936c8296ecf09a14a48ebfc4fe4/TMessagesProj/jni/voip/tgcalls/v2/Signaling.cpp#L727-L747 (checked October 29, 2026)
• The tgcalls upstream fix commit, "Fix camera rotation", April 21, 2026, changing both v2/Signaling.cpp and v2_4_0_0/Signaling_4_0_0.cpp: https://github.com/TelegramMessenger/tgcalls/commit/a6ea40ebf18233fad5aae29aa3d30561f839a6a8 (checked October 29, 2026)
• Telegram for iOS release 12.7, whose tgcalls submodule points at the fix commit: https://github.com/TelegramMessenger/Telegram-iOS/tree/release-12.7/submodules/TgVoipWebrtc (checked October 29, 2026)
• Telegram Desktop 7.0.1, released July 14, 2026, the first Desktop release whose tgcalls submodule includes the fix: https://github.com/telegramdesktop/tdesktop/releases/tag/v7.0.1 (checked October 29, 2026)
• Telegram for Android on Google Play, the Update button of the listing: https://play.google.com/store/apps/details?id=org.telegram.messenger (checked October 29, 2026)
• CISA Known Exploited Vulnerabilities catalog JSON feed, checked on October 29, 2026, for the absence of an identifier for this flaw: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json