Ошибка в библиотеке, эксплоит от ИИ, и почему это важно для TYPO3

В сентябре 2026 года компания Hacktron, занимающаяся исследованиями в области безопасности, опубликовала отчет, в котором описывалось, как ей удалось добиться удаленного выполнения кода на инфраструктуре, принадлежащей OpenAI. Точка входа оказалась почти банальной: они загрузили изображение на форум. Что делает эту историю достойной внимания — и требующей принятия мер — так это то, где именно находилась уязвимость и как её использовали в злонамеренных целях.

Если ваш сайт на TYPO3 поддерживает загрузку изображений и обрабатывает их с помощью ImageMagick или GraphicsMagick, вам грозит аналогичная уязвимость. Ниже рассказывается, что именно произошло, почему привычное представление о том, что «виноват ImageMagick», неверно, и что с этим делать.

OpenAI, как и тысячи других организаций, использует форум сообщества Discourse. Discourse позволяет пользователям загружать изображения. Для считывания размеров изображений обычно используется лёгкая библиотека на Ruby под названием FastImage. Однако FastImage не поддерживает формат фотографий HEIC/HEIF от Apple — поэтому, по словам Hacktron, Discourse передавал эти файлы команде magick из ImageMagick.

В этом и заключается вся история. ImageMagick самостоятельно не декодирует HEIC. Он делегирует эту задачу отдельной библиотеке под названием libheif. А версия libheif, установленная на сервере — взятая из базового образа операционной системы — содержала переполнение буфера кучи, которое можно было вызвать просто путем анализа вредоносного файла HEIC.

Далее следует классическая цепочка повреждения памяти: переполнение буфера, приводящее к операции чтения и записи за пределами допустимого диапазона, шаг за шагом превращается в контроль над процессом. Злоумышленник загружает изображение; сервер пытается создать его миниатюру; изображение выполняет код. Компания Hacktron сообщила, что, используя полученный таким образом плацдарм, ей удалось получить доступ к внутренним репозиториям через взломанные учетные записи сотрудников.

Сама уязвимость никогда не находилась в ImageMagick. ImageMagick был лишь «входной дверью», ведущей к библиотеке с реальной уязвимостью.

Именно в этом многие заблуждаются, поэтому стоит сказать об этом прямо. ImageMagick и GraphicsMagick — это оркестраторы. Для работы с форматами, выходящими за рамки самых простых, они обращаются к специализированным библиотекам — libheif для HEIC/AVIF, Ghostscript для PDF и EPS, рендереру для SVG и так далее. Когда в одной из этих библиотек-посредников обнаруживается ошибка, связанная с безопасностью памяти, инструмент, который её вызвал, полностью наследует эту уязвимость.

Из этого вытекают два следствия, и оба важны для того, как вы можете защитить себя:

• Обновление ImageMagick эту проблему не устраняет. Необходимый патч находится в libheif (и её кодеках), поставляемых через вашу операционную систему, а не в самом инструменте обработки изображений.
• Переход на GraphicsMagick тоже не решает проблему. GraphicsMagick — это форк ImageMagick с той же архитектурой и, в случае с HEIC, с той же базовой библиотекой-делегатом. Он считается более консервативным — по умолчанию в него включено меньше экзотических декодеров, и он избежал печально известных уязвимостей 2016 года «ImageTragick», — но в отношении этого класса ошибок он находится в точно таком же положении. Кроме того, в ней отсутствует файл policy.xml, присутствующий в ImageMagick, поэтому на самом деле сложнее обеспечить безопасность с помощью конфигурации.

Hacktron продолжил отслеживание той же уязвимости libheif в длинном списке известных платформ и фреймворков — это последующее исследование они назвали «HEIF Heist». Дело не в том, что одному форуму не повезло. Дело в том, что одна уязвимая библиотека на языке C незаметно лежит в основе огромного количества программного обеспечения, которое принимает загружаемые пользователями изображения.

А вот и неожиданный поворот, благодаря которому эта история выходит за рамки очередного репортажа о CVE. Hacktron — компания, занимающаяся вопросами безопасности в сфере искусственного интеллекта, и этот эксплойт был разработан с помощью большой языковой модели, выступавшей в роли автономного агента.

По их словам, основной сложностью оказалась ASLR — рандомизация расположения адресного пространства, стандартная защита, которая распределяет данные в памяти таким образом, что злоумышленник не может предсказать, где что находится. Сначала они создали рабочий эксплойт с отключенной ASLR. Сделать его надежным против стандартной конфигурации с включенной ASLR — действительно сложная и кропотливая исследовательская задача. Hacktron сообщила, что одна версия модели не смогла добиться надежного результата, в то время как следующая — выпущенная еще в процессе работы — справилась с задачей за считанные часы.

Относитесь к этому с должной осторожностью: это рассказ поставщика о превосходных возможностях собственных инструментов, а подробные утверждения принадлежат им самим и не прошли независимую проверку. Однако направление развития решений реально и заслуживает внимания. Разработка эксплойтов, направленных на уязвимости, связанные с повреждением памяти, всегда была специализированным и трудоемким ремеслом — именно это не позволяло многим теоретически уязвимым ошибкам превращаться в реальные атаки. Если ИИ-агенты будут продолжать сокращать эти усилия, разрыв между «ошибка существует» и «ошибка используется против вас» станет меньше. Непривлекательная работа по своевременному исправлению уязвимостей перестает быть делом добровольным.

TYPO3 выполняет те же функции, что и Discourse. Он принимает файлы через админскую панель, а на многих сайтах — через формы на пользовательском интерфейсе. Он обрабатывает изображения — изменяет размер, обрезает, создаёт миниатюры — с помощью внешнего процессора, который настраивается в разделе «GFX» системных настроек: для параметра «processor» указывается «ImageMagick» или «GraphicsMagick», а «processor_path» указывает на исполняемый файл. Каждое загруженное изображение, размер которого изменяется, проходит через этот конвейер, использующий те же библиотеки-делегаты.

На то, насколько открыт для внешнего доступа конкретный сайт, влияют несколько факторов:

• Какие форматы вы на самом деле принимаете и обрабатываете. Обычные форматы JPEG/PNG/GIF/WebP проходят через относительно проверенные декодеры. Риск резко возрастает при использовании нестандартных форматов — HEIC/AVIF, JPEG XL, и особенно PDF, EPS и SVG, делегаты которых (Ghostscript, рендереры SVG) давно известны как уязвимые к удалённому выполнению кода.
• Кто может загружать файлы. Если загрузка ограничена доверенными редакторами бэкенда, поверхность атаки узкая. Если анонимная форма на фронтенде принимает изображения — аватары, контактные формы, комментарии — вы оказываетесь в той же ситуации, в которой оказался Discourse.
• Под каким правом запускается рабочий процесс. Если ваш пул PHP-FPM запускается от имени того же пользователя, которому принадлежат файлы сайта и который владеет учетными данными базы данных, выполнение кода в парсере изображений означает полный компромисс этого сайта.

Справедливое замечание. «Из коробки» стандартный сайт на TYPO3 не обязательно будет передавать файлы HEIC своему процессору так же, как это делал Discourse — конкретный вектор уязвимости HEIC зависит от ваших форматов и конфигурации. Но лежащая в основе схема (непроверенный файл → внешний декодер → небезопасная для памяти библиотека C) — это именно то, чем является конвейер обработки изображений TYPO3, а библиотеки-делегаты, на которые он опирается, — те же самые, что и рассматриваемые здесь. Рассматривайте это как класс риска, а не как отдельный CVE.

Исправление довольно простенькое, и это хорошая новость. В приблизительном порядке по степени серьезности:

1. Установите исправления для библиотек-делегатов через канал безопасности вашей ОС — не через ImageMagick. Ошибка была в libheif и её кодеках (libaom, libde265). В Debian/Ubuntu это означает, что нужно оставить включенными автоматические обновления безопасности или своевременно устанавливать их вручную. Проверьте установленную версию с помощью команды dpkg -l | grep libheif.
2. Если вы работаете в Docker, пересоберите образ — не просто перезапускайте его. Именно в этом заключалась фактическая проблема Discourse: уязвимая libheif, застывшая внутри образа контейнера. Простой перезапуск сохраняет старый, кэшированный слой. Пересоберитеобраз с чистой базы, чтобы исправленная библиотека была встроена в него.
3. Ограничьте форматы в файле policy.xml ImageMagick. Отключите то, что вам не нужно — PDF, PS, EPS, MVG, MSL, а также HEIC/AVIF/JXL, если ваш сайт никогда не работает с ними. Это удаляет целые категории делегатов до того, как какой-либо файл, предоставленный злоумышленником, до них дойдет. (Пользователи GraphicsMagick: у вас нет этого рычага, поэтому уделяйте больше внимания следующим двум пунктам.)
4. Ограничьте круг лиц, имеющих право на загрузку, и проверяйте подлинность типов файлов — по фактической MIME-сигнатуре, а не по расширению — особенно на любых путях загрузки, доступных анонимным пользователям.
5. Изолируйте процесс обработки. Запускайте каждый сайт под собственным пользователем без привилегий и в собственном пуле PHP-FPM, чтобы выполнение кода в парсере изображений одного сайта не могло затронуть другой сайт или привести к эскалации прав до root. Это превращает ситуацию «одна уязвимость = весь сервер» в «одна уязвимость = один сайт» — это самая ценная структурная мера защиты, которую вы можете применить.

Ни одна из этих мер не является разовой задачей. В течение всего 2026 года продолжали появляться новые уязвимости libheif; только за лето было выпущено несколько обновлений безопасности. Реалистичная цель — не «постоянное исправление уязвимостей», а «быстрое исправление и локализация угрозы, когда появляется новая уязвимость раньше, чем выходит исправление». Оперативные обновления закрывают известные дыры; изоляция ограничивает радиус воздействия тех уязвимостей, которые ещё никто не обнаружил.

Я управляю веб-сервером, и у каждого сайта есть свой собственный пользователь Linux без привилегий с отдельным пулом PHP-FPM. На практике именно в этом заключается изоляция: если специально сформированный образ когда-либо запустит код в конвейере обработки одного сайта, он будет выполняться от имени пользователя этого сайта и никого больше. Оно может разрушить этот единственный сайт — его файлы, учетные данные базы данных — но не сможет добраться до соседнего сайта или подняться до прав root без второй, отдельной уязвимости. «Одна уязвимость = один сайт», а не «одна уязвимость = весь сервер».

Для установки исправлений я полагаюсь на автоматические обновления безопасности, ограниченные только каталогом -security, с отключенной функцией автоматической перезагрузки. Обычные обновления функций я по-прежнему устанавливаю вручную после беглого просмотра, но исправления безопасности — те, которые важны именно для этой угрозы — устанавливаются сами по себе в течение ночи. Когда я проверял журналы во время написания этой статьи, оказалось, что всего за несколько дней до этого система автоматически установила libaom — кодек AV1, который libheif использует для декодирования AVIF. Система незаметно исправила именно ту цепочку декодирования изображений, о которой идет речь в этой статье, и мне не пришлось вмешиваться.

Автором оригинального исследования является Hacktron: «Взлом OpenAI».