---
title: "Ошибка в библиотеке, эксплоит от ИИ, и почему это важно для TYPO3"
canonical: "https://dmitry-dulepov.com/ru/oshibka-v-biblioteke-ehksploit-ot-ii-i-pochemu-ehto-vazhno-dlja-typo3/"
language: "ru-RU"
content_type: article
---

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

Обработанная фотография, библиотека изображений, о которой никто и не подозревал, и ИИ-агент, написавший эксплойт. Цепочка, проникшая внутрь OpenAI, проходит через программное обеспечение, на которое незаметно полагаются и многие сайты на TYPO3.

В сентябре 2026 года компания [Hacktron](https://www.hacktron.ai/blog/hacking-openai), занимающаяся исследованиями в области безопасности, [опубликовала отчет, в котором](https://www.hacktron.ai/blog/hacking-openai) описывалось, как ей удалось добиться удаленного выполнения кода на инфраструктуре, принадлежащей OpenAI. Точка входа оказалась почти банальной: они загрузили изображение на форум. Что делает эту историю достойной внимания — и требующей принятия мер — так это то, *где* именно находилась уязвимость и как её использовали в злонамеренных целях.

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

## Как это произошло

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

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

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

**Сама уязвимость никогда не находилась в ImageMagick. 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

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](https://www.hacktron.ai/blog/hacking-openai)».