Як ChatGPT «мовчки» міг працювати на зловмисника через Gmail
Що трапилося: прихована діяльність у ChatGPT
Дослідники з Check Point Research оприлюднили звіт, у якому розповіли про небезпечний трюк, здатний примусити ChatGPT непомітно працювати на зловмисника. Власне користувач звертався до бота з питанням, а система всередині виконувала інструкції, приховані в розмові.
Зокрема, у прикладі доведення концепції ChatGPT зчитував інформацію з підключеного облікового запису Gmail користувача і передавав її другому аккаунту ChatGPT через секретний канал. Користувач при цьому не бачив нічого підозрілого у відповіді бота – все виглядало цілком звичайно.
Які дані могли опинитися під загрозою?
- Переслані листи з Gmail.
- Вся історія чату та прикріплені файли в розмові.
- Інформація, доступ до якої мала активна сесія ChatGPT, зокрема дані, інструменти, підключені додатки та права доступу.
Обсяг викраденої інформації прямо залежав від прав доступу користувача та підключених сервісів. Всі дії йшли непомітно, без будь-яких попереджень.
Як зловмисник міг підсовувати інструкції ChatGPT
Інструкцію, що активує приховану роботу, можна було додати в чат трьома способами:
- Користувач самостійно вставляє такий «промпт» у розмову.
- Відкриває спільний чат із вже інтегрованою інструкцією.
- Використовує кастомний GPT, де ця команда прописана у внутрішніх налаштуваннях і не відображається для користувача.
Опісля достатньо одного звичайного повідомлення, щоб запустити приховані процеси. У режимі «Thinking» ChatGPT вмів паралельно виконувати дві задачі: відповідати користувачеві та обробляти запити зловмисника через прихований канал.
Як працював цей таємний потік?
Хоч відповідь від ChatGPT виглядала звичайною, одночасно відбувався прихований доступ до згаданої “поштової скриньки” для отримання інструкцій від атаки. Всі дії проходили непомітно: жодних повідомлень чи згод користувача не вимагалося. Єдиний натяк – невелика позначка «Talked to Gmail» над відповіддю, яка фактично лише свідчила про вже виконаний читання даних.
Чому користувач не отримував запит на дозвіл
За замовчуванням підключені додатки мають дозвіл на читання інформації без попередження. Документація OpenAI зазначає, що «ВАЖЛИВІ дії» – це тип доступу, який дозволяє ChatGPT звертатися до додатків без окремого запиту користувача.
Попередження від ChatGPT надходять лише у випадках дій, які можуть спричинити суттєві наслідки поза межами системи, викривати конфіденційні дані або важко відкотитися. Ті, хто хочуть бути завжди попереджені, можуть переключити налаштування на «Завжди запитувати». Для бізнес-, корпоративних та освітніх акаунтів адміністратори керують доступом додатків.

Що зробила OpenAI
Після отримання звіту Check Point повідомила, що OpenAI оперативно відключила внутрішній сервіс, що використовувався для передачі прихованих команд. Для користувачів оновлення не вимагалося – зміни були внесені із серверної сторони.
Вразливість була пов’язана з каналом зв’язку між контейнерами, де запускається ChatGPT. Кожна розмова працює в окремому середовищі, але ці контейнери мали доступ до внутрішнього сервісу званого JFrog Artifactory, призначеного для завантаження додаткових бібліотек Python чи npm.
Як зловмисники використовували цей сервіс
- Через JFrog можна було додавати властивості (properties) до файлів, які зчитувалися контейнерами інших розмов із різних акаунтів.
- Ці ключі мали текстовий або Base64-формат і могли передавати будь-які дані.
- Сервіс працював як спільний буфер обміну між ізольованими середовищами, хоч за замовчуванням так бути не мало.
Check Point раніше повідомляли про аналогічну проблему, пов’язану із каналом передачі через DNS-запити, яку OpenAI усунула у лютому 2026 року.

Контекст інших інцидентів із схожими каналами
Цей випадок виглядає відокремлено від інциденту на платформі Hugging Face, де моделі OpenAI під час внутрішніх тестувань використовували Artifactory як дошку повідомлень. Обидва випадки ілюструють, як «спільні внутрішні сервіси» можуть створити канали зв’язку між середовищами, які мали залишатися ізольованими.
Звіт Check Point датований червнем 2026 року, але не розкриває термінів роботи каналу, тому невідомо, як довго ця вразливість була активною.