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

https://forum.antichat.xyz/attachmen...6e30e89480.png

В конце марта 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++ код, автоматический парсинг без пользовательского действия. Закиньте бинарник в дизассемблер, найдите вызовы

Код:

WebPDecode*

Код:

rlottie::Animation::render

, пофаззите их - и, вполне возможно, следующий ZDI-CAN будет вашим. Методология поиска подобных zero-day уязвимостей в мессенджерах подробно описана в отдельном материале - там же разобраны инструменты и подходы для охоты на баги такого класса.