В конце марта 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 - внутренний трекинг-номер Zero Day Initiative, подразделения Trend Micro, которое занимается скупкой и координированным раскрытием уязвимостей. Исследователь Майкл Деплант (Michael Deplante) из Trend Micro Zero Day Initiative нашёл критическую уязвимость Telegram и сообщил о ней через стандартный ZDI-процесс.
Хронология событий, восстановленная по открытым источникам:
ДатаСобытиеМарт 2026ZDI публикует advisory с оценкой CVSS 9.827 марта 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 не присвоен, реальные параметры могут отличаться. Единственный CVSS 3.1-вектор, который математически даёт ровно 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)Низкая сложностьНе нужны условия гонки, специфическая конфигурация или MITMPR: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 атаки через стикеры выглядит так:
- Атакующий создаёт стикер с модифицированным заголовком или телом файла, вызывающим ошибку парсинга (heap overflow, integer overflow, use-after-free)
- Файл отправляется в личные сообщения, групповой чат или канал
- Клиент Telegram получает push-уведомление, загружает файл и передаёт его в парсер для рендеринга превью - автоматически, в фоне
- Некорректные данные вызывают повреждение памяти
- Атакующий получает выполнение произвольного кода с привилегиями процесса Telegram
Это не спекуляция - стандартная kill chain для zero-click media parsing bugs, задокументированная в десятках CVE от FORCEDENTRY (iMessage) до CVE-2023-4863 (libwebp). Вектор атаки Telegram через стикеры вписывается в ту же модель.
Поверхность атаки по платформам
Telegram имеет независимые клиенты для разных платформ, и уязвимость может затрагивать их по-разному:
ПлатформаПарсинг медиаSandboxРиск при RCETelegram Desktop (Windows)Нативный, без sandboxНетПолный доступ к файловой системе пользователяTelegram Desktop (macOS)Нативный, ограниченный sandboxЧастичныйДоступ к данным приложения, потенциальный escapeTelegram 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:
Код:
Telegram.exe
Telegram.exe
Updater.exe
Telegram
.exe
Telegram
.dll
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 -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 == && tls.record.length > 16000
Немедленные меры защиты
Пока патч Telegram уязвимости не подтверждён, рекомендации для организаций:
- Обновите клиент до последней версии - если баг тихо исправлен, вы уже защищены
- Отключите автозагрузку медиа: Настройки -> Данные и диск -> Автозагрузка медиа -> Отключить всё
- Разверните мониторинг - Sysmon-конфигурация выше займёт 10 минут
- Изолируйте Telegram - на рабочих станциях с чувствительными данными запускайте в sandbox (Sandboxie, Windows Sandbox, Firejail на Linux)
- Используйте 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) может затрагивать все платформы одновременно. Именно это произошло с CVE-2023-4863 в libwebp (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 с техникой Exploitation for Client Execution (T1203) - клиент автоматически обрабатывает входящее сообщение, что приводит к выполнению кода. Для этапа 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++ код, автоматический парсинг без пользовательского действия. Закиньте бинарник в дизассемблер, найдите вызовы
и
Код:
rlottie::Animation::render
, пофаззите их - и, вполне возможно, следующий ZDI-CAN будет вашим. Методология поиска подобных
zero-day уязвимостей в мессенджерах подробно описана в отдельном материале - там же разобраны инструменты и подходы для охоты на баги такого класса.
Древовидный вид