Взлом OpenAI

Введение

25 июля 2026 года была скомбинирована цепь из двух критических уязвимостей, позволившая скомпрометировать ChatGPT-аккаунты сотрудников OpenAI. Получив доступ к этим аккаунтам, исследователи смогли получить доступ к внутренним репозиториям OpenAI и потенциально многим другим сервисам.

Для подтверждения полученного доступа без риска увидеть чувствительную информацию, была использована Codex-интеграция сотрудника, чтобы создать pull request #1186742 во внутреннем монорепо OpenAI openai/openai.

До двух месяцев назад любой пользователь или сотрудник OpenAI, авторизировавшийся на форуме поддержки (community.openai.com), мог потерять контроль над своими аккаунтами ChatGPT и Codex. Поскольку люди могут подключать различные сервисы к Codex и ChatGPT, масштаб потенциального доступа был огромным — GitHub, Slack, электронная почта и многое другое.

Вся процедура от начального обнаружения до получения доступа к репо OpenAI заняла менее 72 часов.

О первой уязвимости было немедленно сообщено в OpenAI и Discourse. Обе компании скоординировали выпуск патча. OpenAI также выплатила $6 500 за отчёт.

Полная временная шкала процесса раскрытия представлена ниже. Остальная часть материала описывает, как были обнаружены две уязвимости, как использовались модели Claude и основные выводы из этого опыта.

Предыстория

Несколько месяцев назад команда Hacktron под руководством Harsh Jaiswal, в составе которой были Mohan Pedhapati и Rahul Maini, начала исследовать frontier AI-компании в поиске уязвимостей безопасности. Это привело к обнаружению ошибки конфигурации SSO в инфраструктуре идентификации OpenAI и RCE в libheif на форуме сообщества OpenAI.

С тех пор исследование расширилось в проект HEIF Heist — многомесячное расследование, отследившее libheif через Slack, Meta, GitHub Enterprise, Ruby on Rails и фреймворки Node.js, такие как Next.js, Astro и Gatsby. Удивительное количество широко используемого программного обеспечения зависит от этой одной библиотеки обработки изображений.

Если приложение обрабатывает контролируемые пользователем изображения и принимает файлы .heic/.heif/.avif, велика вероятность того, что оно затронуто. Свяжитесь с hello@hacktron.ai, если потребуется любая помощь.

Взлом community.openai.com

OpenAI использует Discourse для своего форума и предоставляет вход через auth.openai.com. После изучения сервисов и инфраструктуры OpenAI была гипотеза, что компрометация форума может создать путь во внутренние сервисы OpenAI через этот поток идентификации. Для проверки этой гипотезы сначала требовалось получить удалённое выполнение кода на сервисе OpenAI, как форум Discourse.

Хотя само приложение Discourse на самом деле не легкая мишень (исследователи изучали его ранее), была идея атаковать зависимость.

Переполнение буфера в libheif

23 июля был начат анализ конвейера загрузки изображений Discourse, и обнаружилось, что файлы HEIC и HEIF следуют необычным путём. Discourse обычно использовал FastImage для проверки изображений, но поскольку FastImage не поддерживал HEIF, эти файлы передавались в команду ImageMagick magick для конвертации. Это открывало нижележащий парсер libheif напрямую контролируемым пользователем файлам.

Была запущена сессия Opus 4.8 с образом Docker Discourse, и ему предложено проинспектировать установленный пакет libheif на предмет проблем безопасности. Со временем он обнаружил, что некоторые исправления безопасности не были перенесены в пакет libheif. Это позволило переполнение буфера с выходом за границы при чтении/записи (OOB R/W) во время декодирования HEIC.

Интересно, что уязвимый код был изменён upstream год назад, но коммит не был задокументирован как исправление безопасности и не получил CVE. Это может быть причиной того, что Debian 12 и 13 не получили релевантные для безопасности обратные порты вовремя. Поскольку образ Docker Discourse базировался на Debian 12, он установил уязвимую версию libheif 1.19.7. Даже Debian 13 по-прежнему поставлялась с уязвимой версией 1.19.8 на то время. С тех пор Debian опубликовала обновление безопасности для Debian 13 8 августа 2026 года.

24 июля была использована Opus 4.8 для разработки рабочего эксплуата RCE ImageMagick/libheif с отключённым ASLR. Затем было запущено несколько отдельных сессий, чтобы сделать его надёжным против конфигурации Discourse по умолчанию с включённым ASLR, что не дало результатов.

Выпуск Opus 5

Вечером Anthropic выпустила Claude Opus 5. Была запущена новая сессия, которая в течение 3 часов произвела рабочий эксплуат для ARM64 на локальном Mac. Затем ей было предложено перенести эксплуат на окружение x86-64 и конфигурацию jemalloc, используемую Discourse.

К 6:00 25 июля было подтверждено локальное RCE через загрузку изображения. Затем Claude была помещена в автономный цикл /goal против собственного облачного экземпляра Discourse, проксированного через rce.ee/ctf-forum, чтобы выглядеть как CTF-мишень (Opus отказывалась писать эксплуат для удалённых экземпляров).

При проверке в 10:00 агент достиг RCE на Discourse Cloud и продемонстрировал доступ, прочитав /etc/hosts. Используя сгенерированный скрипт эксплуата, удалось получить RCE на экземпляре OpenAI.

После подтверждения гипотезы о возможности перехвата аккаунтов ChatGPT/Codex активных членов форума, был немедленно отправлен отчёт в OpenAI. Затем был перехвачен аккаунт сотрудника OpenAI, чей Codex был подключён к организации GitHub OpenAI. Для демонстрации воздействия без фактического доступа к внутреннему коду ему было отправлено приглашение использовать Codex этого сотрудника для создания PR во внутреннем монорепо OpenAI. Затем все дальнейшие тесты были остановлены.

Отправка на Bugcrowd была обновлена доказательством воздействия, и служба безопасности OpenAI была оповещена. Также был подготовлен отчёт для Discourse и отправлен в их программу HackerOne. Discourse получила отчёт в субботу, ответила в воскресенье и имела патч к понедельнику (спасибо за скорость). Они также немедленно начали изолировать ImageMagick.

Важно подчеркнуть, что уязвимость масштабирования — это не проблема Discourse. Это проблема SSO OpenAI, которая превратила компрометацию форума в доступ к ChatGPT и Codex. Если бы был скомпрометирован любой собственный или сторонний сервис OpenAI, использующий OpenAI SSO, это привело бы к такому же доступу — Discourse был просто одним из способов это доказать.

Стоимость поиска этих уязвимостей

Взлом Discourse и OpenAI занял несколько дней для агента и всего несколько часов человеческого времени. Весь проект исследования HEIF Heist, нацеленный на Slack, Zoom, Meta и прочие, занял два месяца, стоил менее $3 000 в токенах и был проведён тремя исследователями. Адаптация эксплуата для каждой новой компании обычно занимала только день или два.

Было заметно, что каждая новая модель становится всё более способной, что очевидно из эксплуата Discourse, представленного в этом материале. Opus 4.8 боролась в нескольких сессиях, чтобы произвести рабочий эксплуат с включённым ASLR. В течение часов после выпуска Opus 5 ей была предоставлена та же задача, и она преуспела. На более широкой кампании был виден ещё один чистый скачок от Opus 5 к GPT-5.6 Sol, когда потребовалось использовать уязвимость без знания чего-либо о целевой системе, кроме того, что она уязвима.

Для каждой цели тестирование начиналось с загрузки изображения. Оттуда была превращена коррупция памяти в надёжную утечку памяти или оболочку, обычно без знания точной версии libheif, версии libc или окружения развёртывания. ИИ стартовал почти вслепую и адаптировал эксплуат для каждой компании в течение дня или двух. Не известно ни об одной компании, которая обнаружила активность, кроме Shopify, даже после отправки тысяч изображений и неоднократного сбоя их процессоров изображений.

Когда выполнение кода приземлялось внутри песочницы или ограниченного окружения, модели также помогали с повышением привилегий, боковым движением и обходом существующих защит. Это было не полностью автономным взломом, и опытное человеческое руководство оставалось важным, но объём работы, который может выполнить небольшая команда, резко увеличился.

Эпилог

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

Это никогда не была настоящая граница безопасности, но на практике она защищала обычные компании от уязвимостей программного обеспечения. ИИ удаляет эту защиту, превращая больше этого редкого опыта в вычисления. Работа, которая когда-то требовала хорошо оснащённой команды и месяцев усилий, теперь может быть сжата в дни.

Предположения о безопасности должны соответствовать возможностям злоумышленников. Реалистичная модель угроз должна учитывать экономику эксплуатации сегодня, вместо того чтобы полагаться на устаревшие предположения о том, кто может провести сложные атаки.

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

Затронутые версии и патчи

HEIF Heist не привязан к одной версии. Он нацелен на всю экосистему уязвимостей на нескольких семействах выпусков (например 1.19.x, 1.20.x, 1.22.x, 1.23.x). Любое развёртывание без последних upstream-патчей безопасности потенциально уязвимо.

• Обновите upstream. Установите последние пакеты libheif и libde265 с исправлениями безопасности через канал безопасности вашего дистрибутива или upstream-выпуск. По состоянию на 14 сентября 2026 года последний upstream-выпуск libheif с исправлениями безопасности — v1.23.4; v1.23.2 был заменен дополнительными исправлениями безопасности. Пакеты дистрибутива могут содержать обратные порты исправлений под более старый номер upstream-версии, поэтому проверьте также бюллетень безопасности пакета.
• Защита в глубину. Учитывая сложность формата ISO base media file и темп обновлений декодера, вероятны будущие проблемы с безопасностью памяти. Production-архитектуры должны отключать декодирование недоверенных HEIF/AVIF, где оно не требуется, или изолировать конвейеры обработки изображений внутри усиленных, эфемерных песочниц. Политика безопасности ImageMagick поддерживает ограничение принимаемых форматов и использования ресурсов.

Благодарности

Спасибо Sudanshu Rajbhar за техническую помощь, и Zayne Zhang, Fabian Faessler, Robert Chen и Jessica Ruan за корректуру, рецензирование черновиков и обратную связь, которая улучшила этот материал.

Ссылки