Статья Zero-Day в Telegram ZDI-CAN-30207: разбор уязвимости Telegram zero-day с оценкой CVSS 9.8

Zero-day уязвимость Telegram ZDI-CAN-30207 CVSS 9.8: zero-click RCE через вредоносные стикеры


В конце марта 2026 года в базе Trend Micro Zero Day Initiative всплыла запись, от которой у инфосек-сообщества коллективно дёрнулся глаз: ZDI-CAN-30207 - уязвимость Telegram zero-day с оценкой CVSS 9.8. Zero-click. По сети. Без привилегий. Удалённое выполнение кода через стикеры. Для исследователя уязвимостей это звучит как идеальный шторм - и одновременно как история, где кто-то врёт. Telegram официально отрицает наличие бага. ZDI настаивает на критическом уровне угрозы. А пока идёт перетягивание каната, потенциально затронуты пользователи уязвимых версий клиента (точный scope не раскрыт).

Ниже - полный технический разбор: от декомпозиции CVSS-вектора до практических правил обнаружения, которые можно внедрить прямо сейчас.

Что такое ZDI-CAN-30207 и как была обнаружена уязвимость​

Идентификатор ZDI-CAN-30207 - внутренний трекинг-номер , подразделения Trend Micro, которое занимается скупкой и координированным раскрытием уязвимостей. Исследователь Майкл Деплант (Michael Deplante) из Trend Micro Zero Day Initiative нашёл критическую уязвимость Telegram и сообщил о ней через стандартный ZDI-процесс.

Хронология событий, восстановленная по открытым источникам:

ДатаСобытие
Март 2026ZDI публикует advisory с оценкой CVSS 9.8
27 марта 2026Информация попадает в публичное поле (SecurityLab, Habr)
28 марта 2026Telegram официально отрицает наличие уязвимости
На момент публикацииCVE-идентификатор не присвоен (pending)

По данным securityaffairs.com, уязвимость позволяет выполнять код на целевых устройствах без какого-либо взаимодействия пользователя. Согласно описанию на securityonline.info, речь идёт о zero-click эксплуатации через механизм стикеров, способной привести к полному захвату системы.

Для ZDI-процесса характерен стандартный таймлайн: после уведомления вендору дают ограниченное время на исправление (обычно 90–120 дней). Если патч не выпущен - детали раскрываются публично. По информации SecurityLab, срок на исправление уже установлен и ограничен.

Декомпозиция CVSS 9.8: почему это критическая уязвимость Telegram​

Оценка CVSS 9.8 - не абстрактное число. Это конкретный набор параметров, каждый из которых имеет техническое обоснование. Разберём по компонентам.

Исходя из заявленных в advisory характеристик - сетевой вектор, zero-click, отсутствие необходимости в привилегиях - ниже реконструкция CVSS-вектора на основе публичного описания ZDI. Официальный вектор не опубликован, CVE не присвоен, реальные параметры могут отличаться. Единственный -вектор, который математически даёт ровно 9.8 при таких условиях:
Код:
AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H
Каждый компонент:

МетрикаЗначениеЧто это значит
AV:N (Attack Vector: Network)СетевойЭксплуатация удалённо, через интернет - достаточно отправить сообщение
AC:L (Attack Complexity: Low)Низкая сложностьНе нужны условия гонки, специфическая конфигурация или MITM
PR:N (Privileges Required: None)Без привилегийАтакующему не нужен доступ к системе жертвы
UI:N (User Interaction: None)Zero-clickЖертве не нужно ничего нажимать, открывать, подтверждать
S:U (Scope: Unchanged)Без смены контекстаКомпрометация в рамках того же компонента (именно поэтому 9.8, а не 10.0)
C:H / I:H / A:HПолный импактКонфиденциальность, целостность, доступность - всё скомпрометировано

Почему 9.8, а не 10.0​

Разница между 9.8 и 10.0 по CVSS 3.1 - параметр Scope. При S:C (Changed) уязвимый и импактируемый компоненты различаются: библиотека компрометирует хост-приложение, гипервизорная уязвимость позволяет выйти из VM, или XSS в веб-приложении пробивает sandbox браузера. Оценка 9.8 с S:U означает, что уязвимый и импактируемый компонент - один и тот же (процесс Telegram), и RCE происходит в его контексте, далее - с правами текущего пользователя ОС. Для десктопных клиентов это обычно полный доступ к пользовательским данным, а на мобильных - доступ в рамках sandbox приложения (хотя sandbox escape - вопрос второго этапа).

Тем не менее Telegram CVSS 9.8 - практически потолок для client-side RCE. Для сравнения: Log4Shell (CVE-2021-44228) получил 10.0 именно благодаря S:C (Scope: Changed) - эксплуатация уязвимости в log4j через JNDI lookup позволяет выполнить произвольный код, воздействуя на ресурсы за пределами security authority уязвимого Java-приложения (импактируемый компонент - ОС/инфраструктура). При этом message lookup substitution была включена по умолчанию в уязвимых версиях, что сделало эксплуатацию массовой.

Zero-click через стикеры: вектор атаки Telegram​

Раскрытие уязвимости ZDI не содержит полных технических деталей - стандартная практика до истечения disclosure timeline. Но из имеющихся данных можно реконструировать поверхность атаки.

Как Telegram обрабатывает стикеры​

Telegram использует несколько форматов для стикеров и анимированных медиа:
  • WebP - растровый формат, обрабатывается libwebp
  • TGS (Telegram Sticker) - по сути сжатый Lottie JSON, рендерится через rlottie
  • WebM - видеостикеры, декодируются через VP9/libvpx
  • Собственные форматы - кастомные обёртки для анимаций
Каждый из этих парсеров - потенциальная точка входа. При получении сообщения со стикером клиент Telegram автоматически загружает и начинает рендерить медиа-файл ещё до того, как пользователь откроет чат. Именно это делает возможной zero-click эксплуатацию: парсинг происходит в фоне, без какого-либо пользовательского действия. Стикер прилетел - код отработал. Жертва даже не знает, что ей что-то пришло.

Гипотетический механизм эксплуатации​

Работая с похожими багами в libwebp и rlottie (а эти парсеры - настоящий зоопарк из C/C++ кода с ручным управлением памятью), типовой вектор zero-click атаки через стикеры выглядит так:
  1. Атакующий создаёт стикер с модифицированным заголовком или телом файла, вызывающим ошибку парсинга (heap overflow, integer overflow, use-after-free)
  2. Файл отправляется в личные сообщения, групповой чат или канал
  3. Клиент Telegram получает push-уведомление, загружает файл и передаёт его в парсер для рендеринга превью - автоматически, в фоне
  4. Некорректные данные вызывают повреждение памяти
  5. Атакующий получает выполнение произвольного кода с привилегиями процесса Telegram
Это не спекуляция - стандартная kill chain для zero-click media parsing bugs, задокументированная в десятках CVE от FORCEDENTRY (iMessage) до CVE-2023-4863 (libwebp). Вектор атаки Telegram через стикеры вписывается в ту же модель.

Поверхность атаки по платформам​

Telegram имеет независимые клиенты для разных платформ, и уязвимость может затрагивать их по-разному:

ПлатформаПарсинг медиаSandboxРиск при RCE
Telegram Desktop (Windows)Нативный, без sandboxНетПолный доступ к файловой системе пользователя
Telegram Desktop (macOS)Нативный, ограниченный sandboxЧастичныйДоступ к данным приложения, потенциальный escape
Telegram Desktop (Linux)Нативный, зависит от дистрибутиваНет (обычно)Полный доступ с правами пользователя
Telegram iOSНативный, iOS sandboxДаОграничен sandbox, но возможна цепочка эксплойтов
Telegram AndroidНативный, Android sandboxДаОграничен permissions приложения

Для пентестеров наибольший интерес - Telegram Desktop на Windows. Отсутствие sandbox означает, что Telegram RCE уязвимость сразу даёт выполнение кода с правами текущего пользователя - а это обычно доступ ко всему рабочему столу, документам, браузерным данным и ключам SSH. Лично я на проектах не раз видел, как Telegram Desktop стоит на тех же машинах, где лежат SSH-ключи от прода. Один стикер - и привет.

Спор ZDI и Telegram: критический zero-day или преувеличение​

Ситуация с ZDI-CAN-30207 уникальна тем, что Telegram официально отрицает наличие уязвимости. Согласно публикации Gazeta.ru, компания опровергла заявления Деплантa. По данным heise.de, Telegram утверждает, что уязвимость не существует.

Возможных объяснений несколько:

Сценарий 1: баг реален, но уже тихо закрыт. Telegram мог исправить его в одном из обновлений, не признавая публично. Не редкость - многие вендоры предпочитают не привлекать внимание к критическим багам. «У нас не было уязвимости» звучит лучше, чем «у нас была уязвимость, но мы её починили».

Сценарий 2: расхождение в интерпретации. ZDI оценил уязвимость как zero-click RCE с CVSS 9.8, а Telegram мог определить, что для реальной эксплуатации нужны дополнительные условия, снижающие severity. Скажем, баг воспроизводится только на определённой версии клиента с определённой конфигурацией.

Сценарий 3: различие в поверхности атаки. Если уязвимость затрагивает только один клиент (например, Telegram Desktop), а Telegram оценивает безопасность мессенджера в целом - позиции могут не совпадать.

Сценарий 4: Telegram действительно прав. ZDI редко, но ошибается. Если PoC не воспроизводится на актуальной версии - оценка может быть пересмотрена.

Позиция ZDI обычно заслуживает доверия: Zero Day Initiative работает по строгой методологии, их advisory проходят внутреннюю верификацию, а Деплант - не неизвестный хактивист, а сотрудник Trend Micro с историей подтверждённых находок. Но до публикации полных технических деталей окончательный вердикт выносить рано. Не будем торопиться с выводами.

Практическое руководство: обнаружение и защита от zero-day мессенджера​

Независимо от того, подтвердится ли ZDI-CAN-30207 в полном объёме, вектор атаки через медиа-парсеры - реальная и актуальная угроза. Ниже - конкретные шаги для обнаружения эксплуатации и защиты от zero-day атак.

Мониторинг процессов Telegram Desktop (Sysmon)​

Первый рубеж обороны - отслеживание аномального поведения процесса Telegram на рабочих станциях. Если zero-click эксплойт отрабатывает, процесс Telegram начнёт порождать дочерние процессы или совершать нетипичные системные вызовы. Telegram.exe, который вдруг спавнит cmd.exe или powershell.exe - это тот алерт, который не хочется пропустить в 3 ночи.

Конфигурация Sysmon для отслеживания child-процессов Telegram (пример для демонстрации концепции):
XML:
<Sysmon schemaversion="4.90">
  <EventFiltering>
    <!-- Event ID 1: Process Create
         Include/exclude в одном RuleGroup для корректной фильтрации -->
    <!-- RuleGroup 1: включаем дочерние процессы Telegram -->
    <RuleGroup name="TelegramChildProcess" groupRelation="or">
      <ProcessCreate onmatch="include">
        <ParentImage condition="end with">Telegram.exe</ParentImage>
      </ProcessCreate>
    </RuleGroup>
    <!-- RuleGroup 2: исключаем легитимные дочерние процессы -->
    <RuleGroup name="TelegramChildExclude" groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="end with">Telegram.exe</Image>
        <Image condition="end with">Updater.exe</Image>
      </ProcessCreate>
    </RuleGroup>
  
    <!-- Event ID 11: File Create
         Оба условия в одном FileCreate для AND-логики -->
    <RuleGroup name="TelegramSuspiciousFiles" groupRelation="or">
      <FileCreate onmatch="include">
        <Image condition="contains">Telegram</Image>
        <TargetFilename condition="end with">.exe</TargetFilename>
      </FileCreate>
      <FileCreate onmatch="include">
        <Image condition="contains">Telegram</Image>
        <TargetFilename condition="end with">.dll</TargetFilename>
      </FileCreate>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

YARA-правило для подозрительных стикеров​

Если эксплуатация Telegram уязвимости происходит через модифицированные стикеры, можно мониторить кеш стикеров на предмет аномальных файлов (пример для демонстрации концепции):
Код:
rule Suspicious_Telegram_Sticker {
    meta:
        description = "Detects potentially malformed sticker files in Telegram cache"
        author = "Codeby Security Research"
        date = "2026-03"
  
    strings:
        // WebP magic bytes
        $webp_magic = { 52 49 46 46 ?? ?? ?? ?? 57 45 42 50 }
        // TGS (gzip-compressed Lottie)
        $tgs_magic = { 1F 8B 08 }
  
    condition:
        // Baseline-правило для ПЕРВИЧНОЙ ФИЛЬТРАЦИИ, не для alerting.
        // Требует тюнинга под конкретную среду - высокий FP rate.
        // Telegram sticker limits: animated ≤64KB, video ≤256KB.
        // Файлы > 256KB в кеше стикеров - кандидаты на ручной анализ.
        // NB: TGS - gzip-сжатый JSON, для глубокого анализа необходима
        // распаковка gzip. WebM видеостикеры легитимно могут быть крупнее -
        // исключите WebM (magic: 1A 45 DF A3) или повысьте порог для них.
        ($webp_magic or $tgs_magic) and
        filesize > 256KB
}
Путь к кешу стикеров Telegram Desktop:
Bash:
# Windows
%APPDATA%\Telegram Desktop\tdata\user_data\cache\

# Linux
~/.local/share/TelegramDesktop/tdata/user_data/cache/

# macOS
~/Library/Application Support/Telegram Desktop/tdata/user_data/cache/

Динамический анализ с Frida​

Для тех, кто хочет самостоятельно покопаться в поверхности атаки - Frida-скрипт для перехвата вызовов парсинга медиа в Telegram Desktop (пример для демонстрации концепции):
JavaScript:
// Frida hook для мониторинга парсинга медиа в Telegram Desktop
// Запуск: frida -p <telegram_pid> -l media_hook.js

// Перехват вызовов WebP decode
// ВАЖНО: стандартные сборки Telegram Desktop статически линкуют libwebp -
// findExportByName вернёт null. Скрипт ниже работает только для нестандартных
// сборок (некоторые Linux-пакеты) с динамической линковкой libwebp.
// Для стандартных сборок требуется реверс-инжиниринг бинарника:
//   1. Найдите адрес WebPDecodeRGBA в Ghidra/IDA
//   2. Используйте: const base = Module.findBaseAddress('Telegram');
//      const webpDecode = base.add(0xOFFSET); // offset из Ghidra/IDA
//      Interceptor.attach(webpDecode, { onEnter: ... });
const webpNames = ["WebPDecodeRGBA", "WebPDecodeARGB", "WebPDecodeRGBInto", "WebPDecode"];
let hooked = false;
for (const name of webpNames) {
    const addr = Module.findExportByName(null, name);
    if (addr) {
        Interceptor.attach(addr, {
            onEnter: function(args) {
                console.log("[WebP] " + name + " called");
                console.log("  Buffer ptr: " + args[0]);
                console.log("  Buffer size: " + args[1].toInt32());
                if (args[1].toInt32() > 10 * 1024 * 1024) {
                    console.log("  [!] SUSPICIOUS: buffer > 10MB for sticker");
                }
            }
        });
        hooked = true;
        break;
    }
}
if (!hooked) {
    console.log("[!] WebP exports not found - libwebp likely statically linked.");
    console.log("    Find function offset via Ghidra/IDA and use Module.findBaseAddress + offset.");
}

// Мониторинг аллокаций для обнаружения heap spray
// NB: реальный heap spray - множество аллокаций одинакового размера,
// а не одна большая. Порог ниже - грубый PoC, для продакшена
// отслеживайте частоту аллокаций одинакового размера.
// ВНИМАНИЕ: перехват malloc замедлит Telegram в 10-100x. Для практического
// использования: (1) ограничьте хук по модулю через Module.enumerateRanges
// и проверяйте this.context.pc, (2) используйте Stalker вместо Interceptor
// для меньшего overhead, или (3) хукайте только конкретные функции парсинга
// (WebPDecode*, rlottie::Animation::render) вместо malloc.
const malloc = Module.findExportByName(null, "malloc");
const allocCounts = {};
Interceptor.attach(malloc, {
    onEnter: function(args) {
        this.size = args[0].toInt32();
    },
    onLeave: function(retval) {
        const s = this.size;
        // Отслеживаем повторяющиеся аллокации одного размера (heap spray паттерн)
        if (s > 4096) {
            allocCounts[s] = (allocCounts[s] || 0) + 1;
            if (allocCounts[s] === 100) {
                console.log("[!] Heap spray pattern: 100x alloc of " + s + " bytes");
                console.log(Thread.backtrace(this.context, Backtracer.ACCURATE)
                    .map(DebugSymbol.fromAddress).join("\n"));
            }
        }
    }
});

Сетевой мониторинг с Wireshark​

Для отслеживания подозрительной активности на сетевом уровне - фильтр Wireshark для анализа трафика Telegram:
Код:
# Фильтрация Telegram API трафика
tls.handshake.extensions_server_name contains "telegram" ||
tls.handshake.extensions_server_name contains "t.me"

# Шаг 1: Определить IP-адреса Telegram серверов по SNI в ClientHello
tls.handshake.extensions_server_name contains "telegram"
# Запишите IP из результатов, или используйте tshark:
# tshark -r capture.pcap -Y 'tls.handshake.extensions_server_name contains "telegram"' -T fields -e ip.dst | sort -u

# Шаг 2: Фильтровать аномально большие TLS records по IP серверов Telegram
# (подставьте IP из шага 1, или используйте AS62041/AS59930)
ip.addr == <telegram_server_ip> && tls.record.length > 16000

Немедленные меры защиты​

Пока патч Telegram уязвимости не подтверждён, рекомендации для организаций:
  1. Обновите клиент до последней версии - если баг тихо исправлен, вы уже защищены
  2. Отключите автозагрузку медиа: Настройки -> Данные и диск -> Автозагрузка медиа -> Отключить всё
  3. Разверните мониторинг - Sysmon-конфигурация выше займёт 10 минут
  4. Изолируйте Telegram - на рабочих станциях с чувствительными данными запускайте в sandbox (Sandboxie, Windows Sandbox, Firejail на Linux)
  5. Используйте Telegram Web вместо Desktop-клиента - браузерная версия работает в sandbox браузера и имеет иную поверхность атаки
Пример запуска Telegram Desktop в Firejail на Linux:
Bash:
# Минимальный профиль изоляции
firejail --private --no3d --nosound \
  --whitelist=~/.local/share/TelegramDesktop \
  /usr/bin/telegram-desktop
# NB: --net=none отключит сеть полностью и Telegram не будет работать.
# Для сетевой изоляции используйте --netfilter с кастомными правилами.

Контекст безопасности Telegram 2025–2026: не первый zero-day​

ZDI-CAN-30207 - не первый случай обнаружения критических уязвимостей в Telegram. Мессенджер с миллиардной аудиторией неизбежно привлекает внимание исследователей, и медиа-парсеры исторически остаются слабым звеном. Парсинг бинарных форматов на C/C++ - это как ходить по минному полю: рано или поздно что-то рванёт.

Характерная черта client-side уязвимостей в мессенджерах - их кросс-платформенность. Один и тот же баг в библиотеке парсинга (скажем, libwebp или rlottie) может затрагивать все платформы одновременно. Именно это произошло с (CVSS 8.8, HIGH, CWE-787 Out-of-bounds Write - heap buffer overflow; UI:R - требует действия пользователя), которая затронула Chrome, Firefox, Thunderbird и кучу приложений, использующих эту библиотеку. CVE-2023-4863 - пример уязвимости в общей библиотеке, а не zero-click эксплуатации; более близкая аналогия zero-click - FORCEDENTRY (CVE-2021-30860), которую NSO Group использовала для атак через iMessage. По NVD эта CVE имеет вектор AV:L/AC:L/PR:N/UI:R и оценку 7.8 (HIGH), то есть классифицирована как локальная уязвимость с участием пользователя. Но в реальной APT-кампании она эксплуатировалась как часть цепочки через iMessage, что де-факто обеспечивало zero-click доставку - классический разрыв между NVD-классификацией и тем, как баг реально используют в поле. Если ZDI-CAN-30207 сидит в аналогичной общей библиотеке - масштаб проблемы может быть шире, чем предполагается.

С точки зрения MITRE ATT&CK, zero-click эксплуатация через мессенджер наиболее точно соответствует тактике Execution с техникой - клиент автоматически обрабатывает входящее сообщение, что приводит к выполнению кода. Для этапа Initial Access релевантна техника T1566.003 (Phishing: Spearphishing via Service) - доставка вредоносного стикера через сторонний сервис (Telegram) жертве. Для APT-группировок - идеальный инструмент: доставка payload через обычное сообщение с минимальным риском обнаружения. Схожие техники атак через мессенджеры подробно разобраны в материале про взлом аккаунтов Signal через QR-фишинг.

Оценка рисков для decision-makers​

Если ZDI-CAN-30207 подтвердится в полном объёме:
  • Impact: удалённое выполнение кода на устройствах сотрудников, использующих затронутые версии Telegram-клиента (конкретные платформы и версии не раскрыты ZDI)
  • Likelihood: высокая - zero-click, эксплуатация тривиальна (AC:L), не требует ни привилегий, ни действий жертвы
  • Blast radius: зависит от затронутых платформ. Если уязвимость в общей библиотеке (libwebp, rlottie) - затронуты все клиенты, но с разным уровнем impact из-за sandbox. Если в платформо-специфичном коде - только конкретная платформа. До раскрытия деталей точный scope неизвестен
  • Remediation: обновление клиента (если патч существует), изоляция приложения, мониторинг
Для организаций, где Telegram используется как рабочий инструмент, стоит провести внеплановый аудит: проверить версии клиентов на всех рабочих станциях, развернуть мониторинг по описанным выше правилам и рассмотреть временный переход на веб-версию до полного прояснения ситуации. Актуальный прогноз киберугроз для российского бизнеса показывает, что подобные векторы атак через корпоративные мессенджеры становятся всё более распространёнными.

Что дальше​

Ситуация с ZDI-CAN-30207 развивается. Полное раскрытие технических деталей уязвимости произойдёт либо после выпуска патча, либо после истечения disclosure deadline Zero Day Initiative. До этого момента подтвердить или опровергнуть эксплуатацию Telegram уязвимости с абсолютной уверенностью невозможно.

Но именно сейчас - лучшее время для подготовки. Критическая уязвимость безопасности с CVSS 9.8 в мессенджере, которым пользуется миллиард людей - не тот случай, когда стоит ждать подтверждения. Внедрите мониторинг, обновите клиенты, изолируйте приложение. Когда ZDI опубликует полный advisory - вы будете готовы к анализу, а не к панике.

Если вы занимаетесь исследованием уязвимостей - присмотритесь к медиа-парсерам Telegram через Ghidra или IDA Pro. Поверхность атаки огромна: десятки форматов, нативный C/C++ код, автоматический парсинг без пользовательского действия. Закиньте бинарник в дизассемблер, найдите вызовы WebPDecode* и rlottie::Animation::render, пофаззите их - и, вполне возможно, следующий ZDI-CAN будет вашим. Методология поиска подобных zero-day уязвимостей в мессенджерах подробно описана в отдельном материале - там же разобраны инструменты и подходы для охоты на баги такого класса.
 
  • Нравится
Реакции: Lampa
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab