Нещодавно випущені Agentic Workflows від GitHub можна обманом змусити публікувати файли з приватних репозиторіїв. Це продемонстрували дослідники з Noma Labs, показавши, що один публічний коментар до issue може перетворити внутрішнього ШІ-помічника на канал витоку даних.

Ця вразливість є критичною, оскільки вона обходить вбудовані перевірки безпеки GitHub без використання спеціального експлойт-коду; зловмиснику достатньо створити на вигляд невинний issue, який ШІ-агент прочитає та на який відреагує.

Як працює ця вразливість

Agentic Workflows дозволяють ШІ-агенту реагувати на події GitHub — наприклад, нові issue — шляхом виконання команд, визначених у файлі workflow. Noma Labs виявили, що агент не розрізняє легітимні інструкції workflow та текст, вбудований у коментар користувача. Створивши публічний issue, що імітує запит менеджера, і додавши приховану директиву, зловмисник може змусити агента:

  1. Відкрити issue (публічно видимий).
  2. Додати рядок, який виглядає звичайним, але містить приховану команду.
  3. Спровокувати ШІ на отримання файлів із приватного репозиторію, до якого workflow має доступ для читання.
  4. Змусити агента опублікувати отриманий вміст як відповідь у тому самому issue.

Дослідники виявили, що вставки одного лише слова «Additionally,» перед прихованою командою було достатньо, щоб обійти захисні механізми GitHub. Жодних додаткових дозволів, токенів чи спеціального коду не потрібно — лише правильне формулювання.

Чому це більше, ніж просто баг

Проблема має структурний характер. ШІ-агент сприймає будь-який текст, отриманий від події репозиторію, як надійний, що фактично перетворює контент, створений користувачем, на вектор входу, подібний до SQL-ін'єкції у вебдодатку. Якщо workflow надає агенту доступ на читання приватних репозиторіїв та можливість публічно коментувати, така комбінація створює прямий шлях для витоку даних.

Що каже GitHub

GitHub було повідомлено про цю вразливість.

Кроки для пом'якшення наслідків для команд

  • Обмежте дозволи агента: надавайте доступ на читання/запис до приватних репозиторіїв лише тоді, коли це абсолютно необхідно.
  • Заблокуйте публікацію: налаштуйте workflow так, щоб агенти не могли публікувати коментарі або інші артефакти у публічних issue.
  • Ставтеся до всіх зовнішніх вхідних даних як до ненадійних: додайте рівні валідації, які очищують або ігнорують текст, створений користувачем, перш ніж він потрапить до ШІ.
  • Аудитуйте тригери workflow: перевірте, які події (issue, pull requests тощо) викликають агентів, і переконайтеся, що відповідні дозволи відповідають цільовому сценарію використання.

Висновок: ШІ-помічник, який може читати приватний код і публікувати дані публічно, є настільки безпечним, наскільки безпечними є межі, які ви для нього встановлюєте. Без суворих обмежень дозволів та очищення вхідних даних один публічний коментар може перетворити функцію підвищення продуктивності на вектор витоку даних.