Разная битовая глубина цветовых каналов в libheif приводит к переполнению буфера и выполнению кода

Первого сентября 2026 года вышла libheif 1.23.3. Эта версия закрывает переполнение буфера в куче, найденное за четыре дня до релиза. Уязвимость позволяет записать произвольные данные за границей выделенного блока памяти. Достаточно одного специально собранного HEIC-файла. В худшем случае злоумышленник читает файлы, доступные процессу обработки изображений, либо выполняет код с его правами. Оценка по шкале CVSS составляет 9.8 из 10. Под удар попадают выпуски с 1.18.0 по 1.23.2.

Детали уязвимости

libheif читает изображения форматов HEIC и HEIF в большей части Linux-системы. Формат Apple сделала основным для iPhone в 2017 году: он хранит картинку примерно вдвое компактнее, чем JPEG, при сопоставимом качестве. Такие файлы загружают тысячами и почти не задумываются об их устройстве. Между тем HEIC устроен как контейнер, внутри которого данные могут быть сжаты разными способами. Разбирать его самостоятельно почти никто не берётся, поэтому в основе множества программ лежит одна библиотека.

Механизм ошибки связан с тем, как в файле хранится цвет. Цветная фотография представлена тремя отдельными плоскостями. Одна отвечает за яркость, две другие - за цветовые оттенки. Каждая плоскость объявляет свою разрядность: восемь бит на точку означают один байт памяти, шестнадцать бит - два. Память под каждую плоскость библиотека выделяет по её собственной разрядности, и здесь всё верно. Проблема в цикле, который заполняет две цветовые плоскости сразу, поскольку в файле они лежат вперемешку. Ширину точки цикл запрашивает только у первой из них. Если первым указан канал с шестнадцатью битами, а вторым - с восемью, двухбайтовые значения уходят в оба буфера. Второй буфер рассчитан на один байт на точку. Каждая запись оказывается вдвое шире и уходит вдвое дальше положенного. Строки накладываются друг на друга, а последняя выходит за границу буфера, в чужую память. Содержимое записи берётся из самого файла, поэтому автор файла определяет и байты, и длину выхода за границу. Объём переполнения растёт вместе с заявленными размерами картинки. Примечательно, что этот же участок кода уже правили несколько месяцев назад - тогда речь шла о похожей записи за границу цветовой плоскости.

Нашли уязвимость 28 августа 2026 года во время проверки WordPress 7.1. Исследователи Wordfence работали с Argus, своей системой автоматизированного поиска атакующих воздействий, а проверку вёл Алекс Томас. О находке сообщили разработчику libheif Дирку Фарину через закрытый механизм GitHub. Тридцать первого августа исправление легло в репозиторий, первого сентября вышла версия 1.23.3 вместе с уведомлением о безопасности.

Для тех, кто отвечает за инфраструктуру, важнее другое. Успешная эксплуатация зависит от архитектуры сервера, сборки библиотеки, поведения распределителя памяти и от того, попадёт ли запрос в нужный рабочий процесс. Универсального эксплойта (кода, использующего уязвимость) не существует. И всё же на одном развёртывании WordPress с Debian и glibc исследователи показали полный сценарий: чтение системного файла со списком учётных записей и запуск произвольного кода. Копирование открытого файла изображения в доступное извне место удалось в 29 попытках из 30, когда сервер уже работал и повторно использовал процессы.

WordPress эта история касается косвенно. Платформа сама изображения не разбирает. Загруженный файл она передаёт редактору изображений: расширение PHP Imagick обращается к ImageMagick, а тот направляет HEIC-файл в libheif. В итоге библиотека на C++ разбирает байты, пришедшие из интернета, с правами процесса обработки изображений. Для загрузки медиафайлов хватает учётной записи автора, а это первая роль с таким правом. Если плагин или собственное приложение разрешает загрузку посетителям, возможностей у атакующего становится больше.

Атака целится в конкретную жертву или в группу одинаково собранных серверов. Один и тот же файл вряд ли сработает на всех серверах WordPress в интернете. Однако опыт проекта HEIF Heist показывает, что доработка эксплойта под новую цель занимает день или два. Исследователи Hacktron довели несколько уязвимостей в libheif до работающих атак против реальных сервисов обработки изображений, включая подтверждённое выполнение кода через загрузку картинки в Discourse и через разбор файла AVIF в приложениях на Next.js. Найденная ошибка имеет другую первопричину и исправлена позже, но ставки для владельца сервиса те же.

Ограничивать вопрос одним WordPress неверно. Опасность возникает везде, где библиотека разбирает чужие файлы HEIC или HEIF: в просмотрщиках изображений, домашних медиасерверах, системах генерации эскизов, конвейерах обработки документов и сервисах обмена фотографиями.

Обновление приходит по обычному каналу. Владельцам сайтов стоит установить пакет с исправлением от операционной системы или хостинг-провайдера. После этого нужно перезапустить PHP и веб-службы, иначе они продолжат держать старую библиотеку в памяти. Контейнеры требуют пересборки из обновлённого базового образа, простого перезапуска недостаточно. Если libheif ставили напрямую, нужна версия не ниже 1.23.3, а актуальным релизом считается 1.23.4.

Проверить свою конфигурацию сложнее, чем кажется. Одного номера версии недостаточно. Уязвимый код попадает в сборку лишь тогда, когда при компиляции включили поддержку несжатых изображений. Два дистрибутива могут нести одну и ту же версию библиотеки, и один окажется уязвим, а другой нет. Среди девяти проверенных конфигураций официальный образ WordPress для Docker оказался уязвим из коробки: он собран на Debian, содержит расширение Imagick, заявляет поддержку HEIC и разбирает нужный формат. Список поддерживаемых форматов виден в разделе здоровья сайта, где перечислены возможности ImageMagick. Если HEIC там не значится, этот путь через WordPress закрыт, но другое ПО на сервере всё ещё может использовать библиотеку.

Тем, кто не может обновиться сразу, стоит перестать принимать такие файлы. Если убрать из разрешённых типов загрузки форматы heic, heif, heics и heifs, файл отклонится до того, как дойдёт до библиотеки. Полезно также запретить выполнение PHP в каталоге загрузок. Клиентам управляющего хостинга имеет смысл спросить провайдера, какая версия libheif работает на серверах и включена ли в ней поддержка несжатых изображений.

Библиотека разбора изображений лежит глубоко под прикладным кодом, и мало кто помнит о её существовании. Поэтому исправление редко попадает в первые строки списка задач. Пока на сервер принимают чужие HEIC-файлы, обновление остаётся работой первой очереди, особенно если цель атакующий выбрал заранее.

Детали уязвимости

Ссылки