Telegram for Android Voice-Call RCE: Detection and Remediation Guide for the NebuSec-Disclosed Flaw

Security startup NebuSec publicly disclosed on October 29 a remote code execution vulnerability in Telegram for Android that is about as close to "zero-click" as a calling-flaw gets: the attacker needed only an ordinary Telegram account and a successful voice call. Once the victim answered the call, attacker-controlled code could execute on the device. No malicious link, no attachment, no sideloaded app — just the call itself.

Telegram shipped the fix in version 12.10.4, released in late September. Per the reporting, the vulnerable code path is reachable in effectively every prior release of the Android client, which means the exposed install base at the time of disclosure was enormous. Telegram is one of the most widely deployed messaging platforms on the planet, and it is disproportionately used by journalists, activists, executives, and — relevant to enterprise defenders — employees conducting business communications outside corporate MDM visibility.

Why this matters to your SOC today: the disclosure-to-exploitation gap for mobile messenger RCEs has historically been measured in days, not months. Voice/video call stacks are complex native parsing surfaces (WebRTC-derived media handling, codec negotiation, signaling state machines) and are a known favorite of commercial spyware vendors. If your organization has Android devices running Telegram below 12.10.4, treat this as an active patch-management emergency and a threat-hunting trigger, not a routine mobile update.

Technical Analysis

Affected Products and Versions

How the Attack Works (Defender's View)

While full technical root-cause details have not been published in the source reporting, the exploitation chain described has a very specific and instructive shape:

1. Delivery via the call stack. The attacker initiates a Telegram voice call to the victim. Malicious content is delivered through the call setup / media negotiation path — the same native code path that parses signaling and media parameters before and during call establishment.
2. User interaction is the trigger. Unlike a true zero-click (e.g., an iMessage blastdoor-style parse on receipt), this flaw fires when the victim answers. That detail matters forensically: exploitation will temporally correlate with an answered incoming Telegram call in device logs and call history.
3. Code execution in the Telegram process context. The attacker's code runs within — or escapes from — the Telegram app's execution context on the device. From there, a capable actor's next moves are predictable: staging a second-stage payload, spawning a shell, reading Telegram's local databases, or attempting privilege escalation to escape the Android app sandbox.

This pattern — media/calling stack memory corruption in a mobile messenger — is consistent with the techniques catalogued under MITRE ATT&CK T1203 (Exploitation for Client Execution) and mobile matrix techniques for call-delivered exploitation. The defensive implications are concrete:

• The exploit runs inside an app that legitimately holds microphone, contacts, and storage permissions. Post-exploitation access to the mic, message history, and files is plausible without any additional permission prompts.
• Telegram's process spawning a shell (/system/bin/sh), an interpreter, or an unexpected child process is a high-signal anomaly. Telegram does not spawn interactive shells in normal operation.
• Post-exploitation staging typically involves network egress to attacker infrastructure — domains and IPs with no relationship to Telegram's CDN — originating from the device around the time of the suspicious call.

Exploitation Status

As of the October 29 disclosure:

• No public proof-of-concept exploit has been reported in the source coverage.
• No confirmed in-the-wild exploitation is documented, and the flaw does not appear in CISA's Known Exploited Vulnerabilities catalog at time of writing.
• However: the vulnerability class (one-click/answer-triggered messenger RCE) is precisely what commercial surveillance vendors and state actors pay seven figures for. The window between public disclosure and operational weaponization for this class of bug is short. Defenders should operate as if exploitation attempts are imminent, particularly against high-value individuals.

Detection & Response

Mobile RCE detection is genuinely hard — the endpoint telemetry available on Android is far thinner than on Windows. The detections below focus on the two highest-signal post-exploitation behaviors: Telegram spawning child processes/shells (via EDR that supports Android, or forensic logcat acquisition) and anomalous network egress correlated with Telegram call activity. Tune aggressively for your environment; drop what doesn't fit rather than diluting the logic.

---
title: Telegram Android Process Spawning Shell or Interpreter
tid: 6f1a2b3c-8d4e-4f5a-9b6c-7d8e9f0a1b2c
status: experimental
description: Detects the Telegram Android app spawning a shell, interpreter, or package installer — consistent with post-exploitation staging after a client-side RCE such as the NebuSec-disclosed voice-call flaw fixed in 12.10.4.
references:
  - https://thehackernews.com/2026/10/telegram-android-flaw-lets-attackers.html
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/10/30
tags:
  - attack.execution
  - attack.t1203
  - attack.t1059
logsource:
  category: process_creation
  product: android
detection:
  selection_parent:
    ParentImage|contains:
      - 'org.telegram.messenger'
      - 'org.telegram'
  selection_child:
    Image|endswith:
      - '/system/bin/sh'
      - '/system/bin/su'
      - '/system/bin/pm'
      - '/system/bin/am'
      - 'sh'
      - 'bash'
      - 'python'
      - 'curl'
      - 'wget'
  condition: selection_parent and selection_child
falsepositives:
  - Rare; Telegram does not legitimately spawn shells or download tools in normal operation
level: critical
---
title: Suspicious Child Process or Dropped Payload in Telegram App Sandbox
tid: 9c8b7a6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects executable or script content written to or executed from Telegram's Android app data directories — a staging pattern for second-stage payloads delivered after messenger client exploitation.
references:
  - https://thehackernews.com/2026/10/telegram-android-flaw-lets-attackers.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/30
tags:
  - attack.persistence
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: android
detection:
  selection_path:
    Image|contains:
      - '/data/data/org.telegram.messenger/'
      - '/data/user/0/org.telegram.messenger/'
      - '/sdcard/Android/data/org.telegram.messenger/'
  selection_exec:
    Image|endswith:
      - '.so'
      - '.sh'
      - '.elf'
      - '.bin'
      - 'sh'
  condition: selection_path and selection_exec
falsepositives:
  - Legitimate native library loading by Telegram itself (loaded via the runtime, not spawned as processes) — correlate with parent process
level: high

A note on scope: Sigma's Android process-creation logsource only works if you're shipping logcat/EDR telemetry from managed devices into your pipeline. If your Android fleet is BYOD and unmanaged, the Sigma rules above won't fire — which is itself the finding: you have no visibility, and the remediation section below becomes your primary control.

For organizations ingesting Microsoft Defender for Endpoint (which supports Android) or mobile EDR telemetry into Sentinel, the following hunt correlates Telegram process anomalies and call-timed network egress:

// Hunt: Telegram on Android spawning child processes or making anomalous egress
// Requires MDE for Android or equivalent mobile EDR telemetry in Sentinel
let Lookback = 14d;
let SuspiciousChildren = dynamic(["sh", "su", "bash", "curl", "wget", "pm", "am", "python"]);
union isfuzzy=true
(DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFolderPath has "telegram" or InitiatingProcessFileName has "telegram"
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName, DeviceId
| extend AlertType = "Telegram child process execution"),
(DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFolderPath has "telegram" or InitiatingProcessFileName has "telegram"
| where RemoteIPType == "Public"
// Exclude known Telegram CDN ranges in production after validating your baseline
| summarize Connections = count(), DistinctRemoteIPs = dcount(RemoteIP), RemoteIPs = make_set(RemoteIP, 20) by DeviceName, InitiatingProcessFileName, bin(TimeGenerated, 1h)
| where DistinctRemoteIPs > 15  // burst of new destinations consistent with staging/exfil
| extend AlertType = "Telegram anomalous egress burst")
| order by TimeGenerated desc

Tune the Telegram CDN exclusion and the egress threshold against your own baseline before alerting on the network branch — the process-spawn branch is the higher-fidelity signal.

Velociraptor does not deploy natively to Android handsets, but it is a legitimate acquisition vehicle in this scenario: during an IR engagement, analysts commonly pull Android devices via ADB from an examiner workstation. This artifact runs on the Velociraptor server/endpoint side and enumerates the Telegram package version and recent child processes on ADB-connected devices to identify unpatched clients and post-exploitation artifacts:

-- Hunt artifact: enumerate Telegram version and suspicious child processes
-- on Android devices connected via ADB to the Velociraptor endpoint.
-- Run on examiner workstations with ADB access during IR or proactive sweeps.

LET telegram_version = SELECT * FROM execve(
  argv=['adb', 'shell', 'dumpsys', 'package', 'org.telegram.messenger'],
  length=200000)

LET suspicious_procs = SELECT * FROM execve(
  argv=['adb', 'shell', 'ps', '-A', '-o',
        'PID,PPID,NAME,ARGS'],
  length=200000)

SELECT * FROM telegram_version
UNION ALL
SELECT * FROM suspicious_procs
WHERE Stdout =~ 'org.telegram|/system/bin/sh|su|curl|wget'

Review the versionName field in the dumpsys output — anything below 12.10.4 is unpatched and should be flagged for immediate update.

Triage Script: Verify Telegram Patch Level Across ADB-Accessible Devices

For MDM-less environments, IR teams, or executive-protection details, this Bash script checks the installed Telegram version on any ADB-connected Android device and flags vulnerable builds:

#!/bin/bash
# Telegram Android RCE (fixed in 12.10.4) — patch verification via ADB
# Usage: ./check_telegram_patch.sh
# Requires: adb, device with USB debugging authorized

set -euo pipefail

FIXED_MAJOR=12; FIXED_MINOR=10; FIXED_PATCH=4

echo "[*] Enumerating connected devices..."
adb devices | awk 'NR>1 && $2=="device" {print $1}' | while read -r DEV; do
  echo "=== Device: $DEV ==="

  PKG=$(adb -s "$DEV" shell pm list packages 2>/dev/null | grep -i 'org.telegram' || true)
  if [ -z "$PKG" ]; then
    echo "[+] Telegram not installed — not vulnerable to this flaw."
    continue
  fi

  VER=$(adb -s "$DEV" shell dumpsys package org.telegram.messenger 2>/dev/null \
        | grep -m1 'versionName' | cut -d'=' -f2 | tr -d '[:space:]')
  echo "[*] Installed Telegram version: $VER"

  IFS='.' read -r MA MI PA <<< "$VER"
  MA=${MA:-0}; MI=${MI:-0}; PA=${PA:-0}

  if [ "$MA" -gt "$FIXED_MAJOR" ] || \
     { [ "$MA" -eq "$FIXED_MAJOR" ] && [ "$MI" -gt "$FIXED_MINOR" ]; } || \
     { [ "$MA" -eq "$FIXED_MAJOR" ] && [ "$MI" -eq "$FIXED_MINOR" ] && [ "$PA" -ge "$FIXED_PATCH" ]; }; then
    echo "[+] PATCHED (>= 12.10.4)"
  else
    echo "[!] VULNERABLE — Telegram $VER is below 12.10.4. Update via Play Store immediately."
    echo "[!] Recommend: pull logcat and call history for IR review (answered calls from unknown contacts)."
  fi
done

Remediation

1. Patch immediately — this is the only complete fix. Update Telegram for Android to version 12.10.4 or later via Google Play. Do not rely on sideloaded APKs; verify the installed build with the script above or via MDM application inventory. Given that every prior version is triggerable, "we updated recently" is not assurance — verify the exact version string.

2. Enforce via MDM where you can. Push a minimum-app-version compliance policy (Telegram ≥ 12.10.4) through Intune, Workspace ONE, or your Android Enterprise platform, and gate corporate resource access (Conditional Access / VPN profile) on compliance. For BYOD, communicate directly to users with a hard deadline.

3. Reduce the attack surface for high-risk users. Executives, journalists, and staff in sensitive regions should restrict who can call them: Telegram Settings → Privacy and Security → Calls → set to "My Contacts" (or "Nobody" for the highest-risk individuals). An attacker needed only an ordinary account to place the call — contact-restriction removes the delivery vector even on an unpatched client as a defense-in-depth measure, though it is not a substitute for patching.

4. Hunt retroactively on high-value devices. For any device that was below 12.10.4 after late September, review: answered Telegram voice calls from unknown or newly created accounts; Telegram process spawning children (per detections above); and unexpected outbound connections from the device. Mobile messenger exploits of this class are deployed selectively — prioritize devices belonging to likely targets.

5. Monitor for follow-on intelligence. No CVE has been published in the source reporting; track Telegram's official channels, NebuSec's technical write-up, and the CISA KEV catalog. If KEV listing occurs, CISA remediation deadlines (typically 21 days for federal civilian agencies, and a strong benchmark for everyone else) apply.

6. Institutionalize the lesson. Messenger call stacks are a proven, recurring RCE surface across the industry. Ensure mobile applications are inside your vulnerability-management scope with defined SLAs — messenger RCEs should carry the same urgency as browser and VPN concentrator bugs, because for your highest-value users, the phone is the endpoint.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub