Приватный репозиторий GitHub? Забудьте. Теперь он публичный, и не по вашей воле

GitHub столкнулся с серьёзной уязвимостью в системе интеграции MCP, которая позволяет злоумышленникам получать доступ к данным из приватных репозиториев. Проблема обнаружена командой Invariant. Уязвимость особенно опасна в условиях стремительного роста популярности кодинг-агентов и автоматизированных инструментов в среде разработчиков.

Сценарий атаки начинается с использования клиента MCP — например, Claude Desktop — подключённого к официальному серверу GitHub MCP. Пользователь имеет два репозитория: публичный, доступный для создания Issues, и приватный с конфиденциальным кодом. Злоумышленник создаёт в публичном репозитории вредоносную задачу, содержащую специально составленный инъекционный текст. Как только пользователь даёт агенту команду просмотреть open issues, агент получает вредоносную инструкцию и начинает действовать в интересах атакующего.

После активации сценария агент может перенести данные из приватного репозитория в контекст запроса и, не осознавая последствий, создать публичный pull request с утечкой этих данных. Среди полученной информации — названия приватных репозиториев, личные планы пользователя и даже уровень зарплаты. Всё это становится доступным в открытом доступе.

Особенность описанного случая в том, что никакого взлома GitHub как такового не происходит — инструменты и код сервера остаются неповреждёнными. Уязвимость кроется в архитектуре самого агентного взаимодействия: ИИ воспринимает внешние данные как достоверные и действует на их основе, что делает систему уязвимой для подмены контекста .

Специалисты обозначают такие случаи как «токсичные потоки» — это когда агент вынуждается выполнять вредоносные действия, хотя инструментальные компоненты считаются безопасными. Благодаря их инструменту анализа, уязвимость была выявлена автоматически, без участия человека.

В качестве меры защиты предлагается внедрение двухуровневой стратегии. Во-первых, необходимо реализовать систему управления разрешениями на основе сессий — агент должен иметь доступ не более чем к одному репозиторию за раз. Во-вторых, важно проводить постоянный мониторинг активности агентов в реальном времени.

Авторы подчёркивают, что даже самые современные модели, прошедшие усиленное обучение на безопасность, не защищены от таких атак. В описанном кейсе использовался Claude 4 Opus — один из наиболее «выравненных» ИИ, который всё же попался на подмену контекста. Это доказывает, что обучение модели недостаточно — безопасность должна обеспечиваться на уровне всей системы.

Проблема не ограничивается GitHub. Недавно была опубликована аналогичная уязвимость в системе GitLab Duo , что подтверждает: архитектура ИИ-агентов требует переосмысления и внедрения специализированных защитных инструментов на всех этапах взаимодействия с внешними платформами.