Команда дослідників безпеки Hacktron AI розповіла, як менш ніж за 72 години вони пройшли шлях від першої знайденої вразливості до повного доступу до внутрішніх репозиторіїв OpenAI. Ключову роль у пошуку та експлуатації вразливості відіграла велика мовна модель (LLM) Claude — зокрема, щойно випущена на той момент версія Claude Opus 5.
Ланцюжок з двох вразливостей
25 липня 2026 року дослідники Гарш Джайсвал, Мохан Педхапаті та Рахул Майні з Hacktron поєднали дві критичні вразливості, щоб отримати контроль над обліковими записами ChatGPT кількох співробітників OpenAI. Маючи такий доступ, команда змогла дістатися внутрішніх репозиторіїв компанії й потенційно — багатьох інших підключених сервісів.
Щоб довести факт доступу, не читаючи при цьому жодної конфіденційної інформації, дослідники скористалися обліковим записом Codex одного зі співробітників, щоб той відкрив pull request у внутрішньому монорепозиторії OpenAI.
Атака ґрунтувалася на двох окремих проблемах:
- Переповнення буфера купи (heap buffer overflow) у бібліотеці libheif, яка використовується для обробки зображень формату HEIC/HEIF;
- Помилка конфігурації single sign-on (SSO) OpenAI, через яку компрометація форуму компанії відкривала шлях до облікових записів ChatGPT і Codex.
За словами дослідників, до моменту виправлення будь-який користувач чи співробітник OpenAI, який заходив на власний довідковий форум компанії (community.openai.com), потенційно міг втратити контроль над своїми обліковими записами ChatGPT і Codex — а разом із ними й над підключеними сервісами на кшталт GitHub, Slack та поштою.
Форум на Discourse як точка входу
OpenAI використовує для свого форуму движок Discourse і дозволяє авторизацію через «Sign in with OpenAI» на базі auth.openai.com. Дослідники припустили, що злам форуму може відкрити шлях до ширшої інфраструктури компанії саме через цей механізм автентифікації.
23 липня команда почала вивчати пайплайн завантаження зображень у Discourse і виявила нетиповий шлях обробки файлів HEIC/HEIF. Оскільки штатний інструмент перевірки зображень FastImage не підтримує HEIF, такі файли передавалися на конвертацію команді magick з ImageMagick — а це напряму відкривало доступ до парсера libheif.
Далі фахівці запустили сесію моделі Opus 4.8 разом із Docker-образом Discourse і попросили перевірити встановлену версію libheif на вразливості. Модель виявила, що частину важливих виправлень безпеки не було перенесено (backport) у пакет — це і призводило до переповнення буфера купи під час декодування HEIC-файлів.
Показово, що відповідний код у верхньому репозиторії бібліотеки змінили ще роком раніше, але коміт не був позначений як пов’язаний із безпекою і не отримав ідентифікатора CVE — тож Debian 12 і 13 не встигли отримати відповідне виправлення вчасно.
Момент, коли з’явився Opus 5
24 липня дослідники за допомогою Opus 4.8 створили робочий експлойт для ImageMagick/libheif — але лише за вимкненого ASLR (механізму рандомізації адресного простору, що ускладнює експлуатацію). Кілька окремих сесій із увімкненим ASLR результату не дали.
Того ж вечора Anthropic випустила Claude Opus 5. У новій сесії модель усього за три години створила робочий експлойт для локальної машини на ARM64, а потім дослідники попросили портувати його під конфігурацію x86-64 і jemalloc, яку використовує Discourse.
До шостої ранку 25 липня команда підтвердила локальне виконання довільного коду (RCE) через завантаження зображення. Після цього Claude запустили в автономному циклі проти власного тестового інстансу Discourse Cloud, замаскованого під CTF-завдання, — модель відмовлялася писати експлойт проти реальних чужих систем напряму.
Коли дослідники перевірили результат о 10 ранку, агент уже отримав RCE на Discourse Cloud і підтвердив це, прочитавши файл /etc/hosts. Використавши згенерований скрипт, команда домоглася виконання коду вже на самому інстансі OpenAI.
Від зламаного форуму — до внутрішнього репозиторію
Підтвердивши гіпотезу про можливість захоплення облікових записів ChatGPT/Codex без взаємодії з користувачем, фахівці одразу повідомили про це OpenAI. Далі вони отримали доступ до облікового запису одного зі співробітників, чий Codex був підключений до GitHub-організації OpenAI. Щоб продемонструвати вплив, не читаючи внутрішній код, вони надіслали промпт до Codex цього співробітника з проханням відкрити pull request у внутрішньому монорепозиторії — після чого одразу припинили будь-яке подальше тестування.
Дослідники підкреслюють: сама вразливість ескалації прав не є специфічною для Discourse. Це проблема на рівні SSO OpenAI, яка перетворювала злам форуму на доступ до ChatGPT і Codex, — форум був лише одним із можливих шляхів це продемонструвати.
Реакція компаній і винагорода
Команда одразу повідомила про вразливість OpenAI та Discourse і координувала з ними процес виправлення:
| Дата (2026) | Подія |
|---|---|
| 25 липня, 05:00–06:00 UTC | Отримано RCE та адміністративний доступ до Discourse-інстансу community.openai.com |
| 25 липня, 08:00–10:00 UTC | Подано звіт через програму Bug Bounty OpenAI на Bugcrowd |
| 25 липня, 13:30–15:30 UTC | Створено демонстраційний PR у внутрішньому репозиторії OpenAI; тестування припинено |
| 25 липня, 22:49 UTC | OpenAI підтвердила, що проблему усунуто — приблизно через 14 годин після подання звіту |
| 25 липня | Звіт подано до Discourse через HackerOne |
| 28 липня | Discourse опублікувала офіційний бюлетень безпеки з патчем |
| 1 вересня | OpenAI виплатила винагороду $6500 і закрила звіт |
OpenAI уточнила, що тестування безпосередньо проти community.openai.com формально не входило до програми bug bounty компанії, тож винагорода стосується саме знахідки на боці OpenAI, а не дій проти Discourse.
Ширший проєкт: «HEIF Heist»
Знахідка стала частиною більшого багатомісячного дослідження під назвою HEIF Heist, у якому команда простежила поширення вразливої бібліотеки libheif у Slack, Meta, GitHub Enterprise, Ruby on Rails, а також у фреймворках на кшталт Next.js, Astro та Gatsby.
За словами представників Hacktron, злам Discourse та OpenAI зайняв в агента кілька днів роботи, але лише кілька годин людського часу. Увесь проєкт HEIF Heist тривав два місяці, коштував менш ніж $3000 у токенах і виконувався трьома дослідниками — адаптація експлойту під кожну нову компанію зазвичай займала один-два дні.
Автори також відзначають різницю у можливостях між поколіннями моделей: там, де Opus 4.8 не міг подолати захист ASLR протягом кількох сесій, Opus 5 впорався за кілька годин після релізу. А коли справа доходила до атак «наосліп» — без жодної інформації про ціль, окрім факту її вразливості — команда бачила подібний стрибок від Opus 5 до GPT-5.6 Sol.
Жодна з атакованих компаній, за винятком Shopify, не помітила активність — навіть попри тисячі надісланих зображень, які регулярно призводили до аварійного завершення роботи обробників зображень.
Автори звіту наголошують: раніше програмне забезпечення певною мірою захищала «безпека через складність» — навіть публічно відома вразливість вимагала рідкісної експертизи, часу й глибокого знання цільового середовища, щоб перетворитися на робочий експлойт. ШІ прибирає цей бар’єр, перетворюючи дефіцитну експертизу на обчислювальні ресурси: те, що раніше вимагало команди фахівців і місяців роботи, тепер можна стиснути до кількох днів.
Нагадаємо, кілька тижнів тому Claude Opus 5 за один запит зібрав повноцінний шутер у стилі Call of Duty.