В конце марта 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-процесс.Хронология событий, восстановленная по открытым источникам:
| Дата | Событие |
|---|---|
| Март 2026 | ZDI публикует advisory с оценкой CVSS 9.8 |
| 27 марта 2026 | Информация попадает в публичное поле (SecurityLab, Habr) |
| 28 марта 2026 | Telegram официально отрицает наличие уязвимости |
| На момент публикации | 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
- Собственные форматы - кастомные обёртки для анимаций
Гипотетический механизм эксплуатации
Работая с похожими багами в libwebp и rlottie (а эти парсеры - настоящий зоопарк из C/C++ кода с ручным управлением памятью), типовой вектор zero-click атаки через стикеры выглядит так:- Атакующий создаёт стикер с модифицированным заголовком или телом файла, вызывающим ошибку парсинга (heap overflow, integer overflow, use-after-free)
- Файл отправляется в личные сообщения, групповой чат или канал
- Клиент Telegram получает push-уведомление, загружает файл и передаёт его в парсер для рендеринга превью - автоматически, в фоне
- Некорректные данные вызывают повреждение памяти
- Атакующий получает выполнение произвольного кода с привилегиями процесса 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
}
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 уязвимости не подтверждён, рекомендации для организаций:- Обновите клиент до последней версии - если баг тихо исправлен, вы уже защищены
- Отключите автозагрузку медиа: Настройки -> Данные и диск -> Автозагрузка медиа -> Отключить всё
- Разверните мониторинг - Sysmon-конфигурация выше займёт 10 минут
- Изолируйте Telegram - на рабочих станциях с чувствительными данными запускайте в sandbox (Sandboxie, Windows Sandbox, Firejail на Linux)
- Используйте Telegram Web вместо Desktop-клиента - браузерная версия работает в sandbox браузера и имеет иную поверхность атаки
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: обновление клиента (если патч существует), изоляция приложения, мониторинг
Что дальше
Ситуация с 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 уязвимостей в мессенджерах подробно описана в отдельном материале - там же разобраны инструменты и подходы для охоты на баги такого класса.