ИИ-агенты нашли уязвимость в ImageMagick и взломали OpenAI: во что превращается баг-хантинг с Opus 5

Как ИИ-агенты нашли уязвимость в ImageMagick и взломали OpenAI

Летом 2026 года ИИ-агенты на базе Claude Opus 5 нашли переполнение кучи в libheif 1.19.7 (CVE-2026-32882, 8.8 из 10 по критичности) и за несколько часов собрали из него рабочий эксплойт. Дальше цепочка: заражённая HEIC-картинка на форуме OpenAI - RCE на сервере форума - общий SSO "Войти через OpenAI" - захват рабочих аккаунтов сотрудников - доступ к внутреннему репозиторию.

Собрали эксплойт исследователи из фирмы Hacktron, которые скормили Opus 5 образ Discourse с установленным libheif и попросили поискать дыры в обработке картинок - там, где до этого несколько сессий подряд буксовал Opus 4.8.

Ключевая деталь, из-за которой всё это вообще сработало: Discourse не умеет сам разбирать HEIC и HEIF (это форматы Apple), поэтому для превью картинок он дергает утилиту magick из ImageMagick, а та под капотом отдаёт разбор файла нативной библиотеке libheif. Между "я просто загрузил фото профиля" и "исполнение кода на сервере" там всего одна непропатченная зависимость, о которой никто на форуме и не думал.

Что не смог Opus 4.8 и что сделал Opus 5 за 3 часа

Сначала команда пробовала Opus 4.8. С включенной ASLR-защитой (это когда адреса в памяти рандомизируются, чтобы эксплойт не мог просто прыгнуть по известному смещению) модель несколько сессий подряд не могла довести уязвимость до рабочего кода - находила краш, но не превращала его в управляемое выполнение.

Вечером 24 июля 2026 вышел Opus 5. Исследователи открыли новую сессию с той же задачей - и получили рабочий ARM64-эксплойт для локального Mac за 3 часа. Дальше эксплойт адаптировали под x86-64 и под окружение Discourse. Хронология по UTC получилась такая:

Почему ASLR вообще должна была остановить атаку: это защита, которая на каждом запуске программы случайно двигает адреса в памяти, чтобы эксплойт не мог просто прыгнуть по заранее известному смещению и исполнить свой код. Обходить её вручную - муторная работа: нужно найти утечку адреса из самой уязвимости и склеить её с переполнением в рабочий примитив чтения-записи. Именно это не давалось Opus 4.8 несколько сессий подряд, а Opus 5 собрал за один вечер.

На всю операцию, от первой сессии с Opus 4.8 до захвата аккаунтов, ушло несколько дней работы модели и, по словам исследователей, "just a few hours of human time" - несколько часов человеческого времени. Для сравнения: более широкий проект Hacktron, HEIF Heist (та же уязвимость на Slack, Meta и ещё нескольких сервисах), занял у трёх исследователей два месяца и обошёлся меньше чем в 3 000 долларов токенов.

Как дыра в библиотеке для картинок довела до внутреннего репозитория OpenAI

Самое неприятное в этой истории не RCE сама по себе, а то, куда она вывела. У форума community.openai.com есть кнопка "Войти через OpenAI" - тот же SSO, которым сотрудники пользуются во внутренних сервисах. Захватив сервер форума, исследователи получили доступ к сессиям тех сотрудников OpenAI, которые заходили на форум под своим рабочим логином - и вместе с ними к их аккаунтам в ChatGPT и Codex.

Дальше сработала уже не уязвимость, а обычная избыточность прав: у части этих аккаунтов Codex был подключен к GitHub с доступом к внутренним репозиториям. Исследователи довели цепочку до конца и открыли PR #1186742 в закрытом монорепо openai/openai - не чтобы что-то сломать, а как доказательство, что дошли досюда.

Итог: дыра в библиотеке для декодирования фотографий, о которой почти никто не думает при выборе стека, обернулась доступом к закрытому исходному коду одной из крупнейших ИИ-компаний. Причём не единственный такой случай для OpenAI - я разбирал же ранее постмортем, как агенты OpenAI сами взломали HuggingFace во время собственной тренировки - там дыру создал сам агент, тут агент дыру нашёл и воспользовался ей, но итог тот же: слепая зона у крупной компании оказывается там, где никто специально не смотрел.

Что получили исследователи и как отреагировал OpenAI

OpenAI подтвердила фикс через 14 часов после отчёта - для критичной RCE с доступом к закрытому коду это быстро. Discourse ответила уже на выходных 26 июля, к 27 июля подготовила патч, а 28 июля опубликовала официальный advisory GHSA-vhm9-85gw-x335.

С деньгами вышло скромнее: 1 сентября 2026 OpenAI выплатила 6 500 долларов - и то только за находку на своей стороне (SSO и захват аккаунтов), потому что тестирование самого форума community.openai.com формально было вне правил bug bounty программы. Часть самой дорогой по последствиям работы - собственно RCE в чужой библиотеке - в программу не попадала вообще.

Отдельно стоит подчеркнуть: уязвимая версия libheif 1.19.7 стояла на форуме, хотя патч в 1.22.0 вышел ещё в мае 2026 - за два месяца до атаки. Патч не был громко анонсирован как критичный и не получил вовремя собственного CVE, поэтому обычный скан зависимостей по бюллетеням его бы и не поймал.

Что это значит для твоего кода, если в нём есть библиотеки для картинок

У меня в пайплайне для этого блога тоже есть код, который работает с картинками - scripts/covers.py, генерит обложки черновиков через внешний API и заливает их в Telegram на утверждение. Полез проверить: функция _download там просто пишет байты из ответа на диск, ext = Path(url.split("?")[0]).suffix or ".jpg" - и всё, никакого Pillow, никакого локального разбора формата в этом файле нет вообще, в requirements никакой imagemagick-обвязки тоже не завозил. Заодно проверил D&D-бота: там тоже Pillow 10.2.0, но он рисует карточку персонажа с нуля, чужие картинки не декодирует - той же дыры тут нет.

И вот тут мой вывод, до которого доходишь только когда сам лезешь проверять: дело не в том, стоит ли у тебя в зависимостях Pillow или ImageMagick по имени - грепом по requirements.txt эту дыру не найдёшь. Дело в том, декодирует ли твой код (или фреймворк под капотом) байты картинки, которую прислал кто-то снаружи. Если сервис только скачивает уже готовый файл от доверенного API и отдаёт его как есть - он не в зоне риска именно этой уязвимости. Если он принимает загрузку от пользователей и что-то с картинкой делает - ресайзит превью, конвертирует формат, генерит миниатюру - там ровно та же засада, что была у Discourse: удобная библиотека тянет за собой нативный декодер тремя слоями ниже, который никто целенаправленно не выбирал и не обновлял.

Из разборов инцидента вытекает практический вывод в два пункта. Если проект принимает HEIC/HEIF/AVIF - обновить декодер до актуальной версии и держать обработку картинок в песочнице отдельно от остального кода. И смотреть не на прямые зависимости в requirements.txt, а на всё дерево транзитивных - патч на libheif вышел тихо, без анонса критичности, за два месяца до атаки, и обычный скан по CVE-бюллетеням его бы не поймал. На агрегаторе вакансий как раз гонял npm audit по транзитивным: нашёл 22 уязвимости в dev-зависимостях (vitest, esbuild), audit fix снизил до 10 - остаток требует мажорных обновлений и висит с 10 сентября 2026, руки пока не дошли.

Библиотека, которая тебя подведёт, почти никогда не та, что указана в requirements.txt явно. У Node это обычно sharp, который сам тянет native-биндинги под капотом; у PHP - GD или Imagick, тот же ImageMagick, только с другой стороны; у Python - Pillow, у которой тоже случались собственные CVE на разбор форматов. Ты выбираешь фреймворк для загрузки аватарок, а получаешь в довесок C-код, разбирающий десяток бинарных форматов, который никто в команде ни разу не читал.

Баг-хантинг с ИИ: дешевле, быстрее и не заканчивается на этом кейсе

Разница между Opus 4.8 и Opus 5 на одной и той же задаче с интервалом в один вечер - это, пожалуй, главный сигнал из всей истории. Работа, для которой раньше нужна была команда с профильной экспертизой и месяцы, сжалась до нескольких часов человеческого времени плюс несколько дней машинного. Anthropic в своём разборе реальных атак на ИИ-агентов уже писала про три реальных кибератаки, которые провели сами агенты - и это тоже не разовая аномалия, а тенденция, которая идёт с обеих сторон: агенты одновременно и находят дыры, и создают новые, пока их гоняют без присмотра.

Я сам гонял похожий аудит на своём проде: в июле 2026 прогнал D&D-бота (бот + мини-апп) через Claude Security - набор агентов для security-аудита кода, 12 research-агентов на скоуп. Из 19 кандидатов подтвердились 7: 1 HIGH, 3 MEDIUM, 3 LOW. HIGH - продовый пароль от БД, годами провисевший в QA-скрипте в истории git; бот живой, 500+ игроков, так что чинили не откладывая. Из MEDIUM - два IDOR в API мини-аппа (ростер любого чата без проверки членства и перезапись участника чата чужим юзером) и вебхук, который открывался при пустом секрете. Из LOW - неатомарный check-then-increment на недельном лимите экспорта, Markdown-инъекция через first_name в статистике бросков и TOCTOU на начислении реферального бонуса без UNIQUE-индекса. Все 7 закрыл в тот же день, 23 июля: миграция на проде, полный сьют из 4743 тестов зелёный. Детали разбирал отдельно, и там же писал, что это удобно ровно до тех пор, пока ты понимаешь, что показывает агент, а что он придумал. Тут ситуация зеркальная: агент нашёл настоящую дыру, довёл её до конца и ни разу не придумал несуществующую RCE - просто потому что цепочку проверяли живые люди на каждом шаге. Кстати да, у меня после переезда пайплайна на Opus 5 половина скиллов сломалась - модель ощутимо мощнее в возможностях, но и ведёт себя иначе, не факт что предсказуемо в твою пользу.

Если у тебя в проекте есть хоть один кусок кода, который трогает байты картинки от чужого источника - это тот случай, когда "потом обновлю зависимость" стоит подвинуть повыше в списке дел. Дыра сидела в проде два месяца после выхода патча. У тебя, возможно, сидит прямо сейчас.