В FFmpeg закрыли уязвимость FFmpeg с собственным именем PixelSmash: багу присвоили CVE-2026-8461 и оценку 8,8 из 10. История не про редкий лабораторный кейс: при определённых условиях ошибка открывала путь к удалённому выполнению кода на Jellyfin, а в более массовом сценарии позволяла уронить приложения и сервисы, которые просто доверяли FFmpeg разбор видеофайлов.
Проблема затрагивает декодер MagicYUV в библиотеке libavcodec, а значит бьёт по длинной цепочке продуктов, сообщает BleepingComputer. Речь не только о медиасерверах, но и о софте, который генерирует превью, сканирует медиатеки или автоматически обрабатывает загруженные ролики. Для русскоязычной IT-аудитории это вполне прикладная новость: если у вас есть self-hosted медиасервисы, файловые хранилища с превью видео, рабочие станции с OBS или просто пайплайны импорта контента, патч лучше не откладывать.
Технически CVE-2026-8461 описывается как heap out-of-bounds write в обработке срезов изображения внутри MagicYUV. Исследователи из JFrog объяснили корень проблемы довольно приземлённо: код по-разному рассчитывал высоту хрома-плоскостей при выделении памяти и при последующем декодировании. В итоге возникает перепись памяти на одну строку буфера. Для атакующего этого достаточно, если он может подсунуть специально подготовленный видеофайл в формате AVI, MKV или MOV. Причём файл необязательно открывать руками: срабатывание возможно и при генерации миниатюр, и при автоматическом сканировании папки, и в любом фоне, где сервис «на всякий случай» читает метаданные.
Самый неприятный сценарий JFrog показала на Jellyfin 10.11.9. Схема атаки выглядит почти буднично: вредоносный AVI попадает в медиатеку, Jellyfin автоматически запускает ffprobe для извлечения метаданных, затем повреждение памяти позволяет перехватить вызов освобождения буфера и свести его к выполнению системной команды от имени пользователя сервиса Jellyfin. Правда, здесь есть важная оговорка, которую нельзя прятать в сноску: для RCE требовалось отключение ASLR либо цепочка с другой уязвимостью, которая позволила бы обойти эту защиту. То есть одна только PixelSmash не ломает современную защиту памяти «из коробки», но в реальной эксплуатации вполне вписывается в составной эксплойт.
Отдельно исследователи описали и сценарий без участия пользователя вообще. Если владелец Jellyfin направляет загрузки, например из торрент-клиента, прямо в папку медиатеки, то достаточно раздать вредоносный файл с правильным названием и форматом. Дальше файловый монитор сервера сам увидит новинку, сам запустит проверку и сам же выполнит всё, что злоумышленник заложил в цепочку атаки. Это как раз тот случай, когда «автоматизация для удобства» внезапно превращается в ускоритель для эксплуатации. Даже если до удалённого выполнения кода дело не дойдёт, уязвимость FFmpeg позволяет достаточно надёжно вызвать отказ в обслуживании.
Список потенциально затронутых приложений получился длинным и неприятно знакомым: Kodi, Emby, Nextcloud, PhotoPrism, OBS Studio, а также генераторы превью в окружениях GNOME, KDE и XFCE. JFrog также предположила, что под ударом могут оказаться Slack, Discord, Telegram и WhatsApp, поскольку они используют FFmpeg для серверной генерации превью видео, но эти продукты в исследовании отдельно не тестировались. Здесь важно не перепутать «может быть уязвим» и «подтверждённо уязвим»: для первой группы есть техническая вероятность по архитектуре, для второй уже были практические проверки.
На этом фоне интересно смотрится Plex. По данным исследователей, популярный медиасервер использует собственную сборку FFmpeg с урезанным набором декодеров и минимальным allowlist, что фактически снизило риск PixelSmash. Это хороший пример инженерной гигиены, о которой обычно вспоминают после инцидента, а не до него. FFmpeg уже выпустила исправление в версии 8.1.2, релиз вышел 17 июня 2026 года. Jellyfin также обновила встроенную версию FFmpeg, PhotoPrism занялась добавлением блоклиста форматов, а команда Nextcloud, получив отчёт через HackerOne, отказалась исправлять проблему у себя, сославшись на то, что корень бага находится вне продукта. Формально логика понятна, операционно для администраторов от этого не легче.
Отдельный сюжет здесь не в одной ошибке, а в масштабе доверия к медиабиблиотекам как к «безопасной инфраструктуре». FFmpeg встроена в сотни проектов, и разработчики часто относятся к ней как к готовому щиту: мол, библиотека зрелая, входные данные пережуёт сама. PixelSmash показывает обратное. Как только один декодер в широко используемой зависимости ошибается в расчёте памяти, уязвимость мгновенно становится проблемой цепочки поставок: от настольного приложения с превью до self-hosted сервера, который молча индексирует папку с файлами. Поэтому главный вопрос здесь уже не в том, сколько команд срочно обновят FFmpeg до 8.1.2, а в том, сколько продуктов вообще знают, какие декодеры у них включены и какие из них работают с недоверенным контентом.