Широке використання ChatGPT та інших ІІ‑платформ у бізнес‑процесах перетворює їх на критичні точки ризику. Нещодавні дослідження компаній Check Point та BeyondTrust Phantom Labs показали, що навіть сервіси провідних вендорів можуть містити небезпечні вразливості, здатні призвести до непомітного витоку даних і компрометації розробницької інфраструктури.
Прихований DNS-канал у ChatGPT: новий вектор витоку конфіденційних даних
Фахівці Check Point виявили раніше невідому уразливість ChatGPT, яка дозволяла зловмиснику тихо виводити з сесії користувача повідомлення, завантажені файли та інший чутливий контент. Ключовий ризик полягав у тому, що ексфільтрація відбувалася без будь-яких попереджень або згоди користувача, а діалог фактично перетворювався на прихований канал передачі даних назовні.
Проблема крилася в побічному каналі в Linux‑середовищі, де агент ШІ виконує код та обробляє дані. Хоча архітектура ChatGPT за замовчуванням обмежує прямий мережевий доступ, дослідникам вдалося показати, що ці обмеження можна обійти через системний DNS‑механізм, використавши його як прихований транспортний канал.
Як працював прихований DNS-канал ChatGPT
Сутність атаки полягала в тому, що чутлива інформація кодувалася безпосередньо в DNS‑запитах, які генерувалися з Linux‑контейнера. Для самої моделі це виглядало як внутрішня технічна операція, а не передача даних до Інтернету, тому вбудовані механізми захисту не класифікували це як витік. У результаті:
• не спрацьовували тригери, які мали би зупиняти вихід даних за межі діалогу;
• користувач не бачив жодних запитів на додаткове підтвердження;
• канал ексфільтрації залишався майже повністю невидимим з точки зору користувача.
За оцінкою Check Point, той самий механізм можна було розширити до віддаленого доступу до Linux‑середовища (remote shell) з можливістю виконання довільних команд, що підвищує критичність уразливості з витоку даних до потенційного повного компрометування середовища виконання.
Prompt injection і шкідливі кастомні GPT як інструмент атаки
Практична реалізація атаки спиралася на техніку prompt injection у поєднанні з соціальною інженерією. Зловмисник може подати шкідливий промпт як «прихований режим підвищення якості відповідей» або «безкоштовне розблокування преміум‑можливостей», стимулюючи користувача вставити цей текст у чат.
Ризики зростають із поширенням кастомних та корпоративних GPT. В такому сценарії шкідлива логіка закладається безпосередньо в налаштування агента, і жертві вже не потрібно вводити підозрілий текст вручну — достатньо почати працювати з скомпрометованою моделлю. Це робить контроль джерела кастомних GPT критично важливим для компаній.
За даними Check Point, уразливість було усунено OpenAI 20 лютого 2026 року після відповідального розкриття. Відомостей про її використання у реальних атаках на момент публікації немає, однак сам факт існування такого каналу демонструє новий клас загроз для ІІ‑платформ.
Розширення браузера та витік діалогів з AI у корпоративному середовищі
Паралельно дослідники відзначають зростання кількості шкідливих або сумнівних розширень браузера, які перехоплюють переписку користувачів з AI‑чатботами. Такі плагіни можуть від початку проєктуватися як шпигунські або перетворюватися на них після «оновлення», починаючи непомітно пересилати історію діалогів на віддалені сервери.
Для бізнесу це означає ризик крадіжки особистості, таргетованого фішингу, витоку комерційної таємниці та даних клієнтів. Співробітники часто копіюють у ChatGPT фрагменти коду, договорів, технічної документації. Якщо паралельно встановлено неконтрольоване розширення, уся ця інформація може опинитися поза межами корпоративного периметра без відома користувача та служби безпеки.
OpenAI Codex і командна інʼєкція через GitHub: загроза для DevOps-ланцюга
Команда BeyondTrust Phantom Labs виявила критичну уразливість OpenAI Codex — хмарного агента для розробників. Недостатня фільтрація вхідних даних при обробці назв гілок у GitHub дозволяла здійснити command injection на стороні сервера.
Уразливість знаходилася в HTTP‑запиті на створення завдання: зловмисник міг впровадити довільні системні команди у параметр, що відповідав за ім’я гілки. Під час опрацювання такого запиту контейнер агента виконував ці команди, що відкривало шлях до викрадення GitHub User Access Token — токена, який Codex використовує для автентифікації в GitHub.
Маючи цей токен, атакувальник отримував можливість читати й змінювати весь репозиторій, а також рухатися вглиб інфраструктури (латеральне переміщення). За даними BeyondTrust, аналогічний підхід міг бути використаний для крадіжки GitHub Installation Access Token та запуску bash‑команд при кожному зверненні до @codex у коментарях до pull request.
OpenAI ліквідувала уразливість 5 лютого 2026 року, після повідомлення дослідників 16 грудня 2025 року. Під ризиком перебували інтерфейс ChatGPT, Codex CLI, SDK та IDE‑плагіни, що підкреслює глибину інтеграції ІІ‑агентів у розробницькі процеси.
Безпека ІІ-платформ: чому компаніям потрібен додатковий захисний шар
Інциденти з ChatGPT та OpenAI Codex демонструють, що ІІ‑сервіси не можна вважати «безпечними за замовчуванням», навіть якщо йдеться про великі технологічні компанії. Коли AI‑агенти отримують доступ до коду, внутрішніх документів та персональних даних, вони стають високопривабливою ціллю для атак.
Організаціям варто вибудовувати власний захисний контур поверх зовнішніх ІІ‑рішень. Практичні кроки включають:
• проксування всіх запитів до ІІ через контрольований шлюз із журналюванням і можливістю блокування;
• політики, що обмежують завантаження конфіденційних даних у публічні моделі;
• аналіз і фільтрацію промптів на наявність prompt injection та прихованих інструкцій;
• жорсткий контроль над розширеннями браузера та плагінами, які взаємодіють з AI‑чатботами;
• регулярний аудит прав доступу, токенів та інтеграцій з GitHub та іншими DevOps‑системами.
Розвиток ІІ невідворотно розширює атакувану поверхню, і традиційні засоби захисту вже не покривають усі нові вектори. Щоб безпечно використовувати ChatGPT, Codex та інші AI‑інструменти, компаніям варто вже зараз переглянути архітектуру кібербезпеки: впроваджувати багаторівневий захист для ІІ‑агентів, відстежувати поведінку контейнерів, мінімізувати обсяг чутливих даних у промптах і системно керувати ризиками інтеграцій. Чим раніше ці підходи стануть стандартом, тим нижчою буде ймовірність наступного витоку даних через ІІ‑платформи.
