Безопасность vibe coding: 74 CVE за три месяца

За последние восемь месяцев я провёл security-ревью двенадцати репозиториев, где 60–80% кода написано через Cursor, Claude Code и GitHub Copilot. В семи из двенадцати нашёл SQL-инъекции - не экзотические, а банальную конкатенацию строк в ORM-хендлерах. Модель генерировала такой код потому что «так короче». В четырёх проектах - API-ключи от платёжных систем, вшитые прямо в frontend-бандл. Один проект на Lovable/Supabase отдавал всю таблицу пользователей без аутентификации: anon key в клиентском коде и ноль строк Row Level Security.

С точки зрения атакующего, vibe-coded приложение - идеальная мишень. Предсказуемые паттерны уязвимостей, отсутствие кастомных WAF-правил, часто прямой доступ к BaaS с минимальной авторизацией. Монетизация - от кражи API-баланса до массовой выгрузки PII на продажу.

Масштаб проблемы: данные исследований 2025–2026​

Veracode протестировала более 100 LLM на задачах генерации кода в Java, Python, C# и JavaScript по четырём категориям уязвимостей из OWASP Top 10: SQL injection (CWE-89), cross-site scripting (CWE-80), log injection (CWE-117) и слабая криптография (CWE-327). Результат: 45% AI-генерированных образцов содержат уязвимости. Java показала худший результат - 72% failure rate. 86% образцов не защищают от XSS, 88% уязвимы к log injection.

Мартовское обновление Veracode за 2026 год фиксирует: pass rate не сдвинулся (~55%), хотя вендоры наперебой рассказывают про security-aware training. Модели стали лучше писать компилируемый код (90% vs. 20% два года назад), но не более безопасный. Код собирается - и на этом хорошие новости заканчиваются.

На уровне enterprise картина жёстче. По данным Apiiro (анализ десятков тысяч репозиториев в компаниях Fortune 50, декабрь 2024 - июнь 2025): AI-assisted разработчики коммитят в 3–4 раза быстрее, но количество security-находок выросло с ~1 000 до более чем 10 000 в месяц - десятикратный рост за полгода. Синтаксических ошибок стало на 76% меньше, логических багов - на 60%. Разработчики чувствуют себя продуктивнее и увереннее. Но privilege escalation paths выросли на 322%, architectural design flaws - на 153%. Это уязвимости AI-генерированного кода, которые требуют глубокого контекстного анализа - и которые стандартные SAST-сканеры пропускают чаще всего.

По данным проекта Vibe Security Radar (предположительно связан с Georgia Tech; публичная верификация методологии на момент написания недоступна), за три месяца начала 2026 года выявлено порядка 74 CVE, атрибутируемых AI-инструментам через трассировку fixing commit в Git-истории. Значительная часть привязана к Claude Code - он оставляет характерные сигнатуры в commit-сообщениях, по которым легко трассировать. Остальные - GitHub Copilot, Cursor, Devin, Aether. Реальное число уязвимостей, по оценке исследователей, может быть в 5–10 раз выше.

JetBrains на выборке из 24 534 разработчиков в 194 странах: 85% регулярно используют AI-ассистенты программирования, 62% полагаются минимум на один AI-инструмент. По данным Y Combinator, 25% стартапов зимнего батча 2025 имели кодовую базу, на 95%+ сгенерированную AI. Риски генеративного программирования масштабируются пропорционально adoption - тут арифметика простая.

Анатомия уязвимостей AI-генерированного кода​

Инъекции без валидации: CWE-89, CWE-80, CWE-94​

CWE-89 (SQL Injection), CWE-80 (Basic XSS, вариант CWE-79), CWE-94 (Code Injection) - три наиболее частые категории инъекционных уязвимостей в AI-генерированном коде. Veracode тестировала четыре категории (CWE-89, CWE-80, CWE-117, CWE-327), а CWE-94 дополнительно выделяется в данных Kaspersky и MITRE CWE Top 25.

Почему модель строит запросы через конкатенацию строк? Потому что в обучающих данных тысячи таких примеров. Параметризованные запросы модель тоже «знает», но без явного указания в промпте выбирает короткий путь. Ей так проще. А нам - проще ломать.

Характерный паттерн, который встречался в пяти из двенадцати моих ревью:
Другой типичный случай - eval() для математических операций на пользовательском вводе (CWE-94). Модель оптимизирована под кратчайшее решение, а eval() - технически самый короткий путь. Для пентестера это прямой initial access к arbitrary code execution.

По данным Kaspersky со ссылкой на MITRE CWE Top 25, наиболее частые проблемы в AI-коде: CWE-94 (code injection), CWE-78 (OS command injection), CWE-190 (integer overflow), CWE-306 (missing authentication), CWE-434 (unrestricted file upload). Все пять - классика OWASP Top 10 (A03:2021 Injection, A01:2021 Broken Access Control, A05:2021 Security Misconfiguration).

Отдельный риск - деградация безопасности при итеративных правках через follow-up промпты. По данным исследования, цитируемого в блоге Kaspersky (первоисточник и методология публично не верифицированы): после пяти итераций через GPT-4o код содержал на 37% больше критических уязвимостей, чем исходная версия. При промптах на добавление фич - 158 уязвимостей (29 критических). Даже при security-focused промптах - 38 новых, 7 критических. Каждая итерация промпта - потенциальная регрессия безопасности. Код не становится лучше от переспрашивания - он становится хуже.

CVE-2025-48757: открытая база данных Supabase в Lovable​

CVE-2025-48757 - CVSS 9.3 (CRITICAL). Недостаточная политика Row Level Security в приложениях, сгенерированных платформой Lovable, позволяет неаутентифицированному атакующему читать и записывать данные в произвольные таблицы.

Примечание: производитель (Lovable) оспаривает классификацию, утверждая, что ответственность за настройку RLS лежит на клиенте (NOTE в NVD к CVE-2025-48757). Знакомая песня - «это фича, а не баг».

CVSS-вектор: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N - сетевой доступ, низкая сложность атаки, никаких привилегий или взаимодействия пользователя, scope changed с высоким воздействием на конфиденциальность. Корневая причина - CWE-863 (Incorrect Authorization).

Supabase архитектурно предполагает, что anon key и URL базы попадают в клиентский код - при настроенном RLS это безопасно. AI-генератор Lovable создавал схемы без единой строки RLS-политик. Тысячи пользователей публиковали приложения, не подозревая, что anon key фактически открывает полный доступ к базе.

Безопасность Lovable Bolt в этом случае целиком зависела от того, включит ли AI Row Level Security при генерации схемы. Спойлер: не включил. По MITRE ATT&CK это Exploit Public-Facing Application (T1190, Initial Access) → Data from Cloud Storage (T1530, Collection). Для эксплуатации достаточно открыть DevTools, вытащить URL и ключ:
Если ответ содержит данные - RLS не настроен, утечка данных Supabase возможна без единой строки эксплойт-кода. По данным отчёта Escape.tech (точная дата и методология публично не верифицированы), сканирование приложений на Lovable, Base44, Bolt.new и Vibe Studio выявило порядка 2 038 критических уязвимостей, более 400 утечек секретов, 175 случаев раскрытия PII - медицинские записи, финансовые данные, аутентификационные credentials. Всё в продакшене, с реальными пользователями.

Slopsquatting: supply chain через галлюцинации LLM​

Около 20% AI-генерированного кода ссылается на пакеты, которых не существует - данные исследования USENIX Security, приведённые в отчёте Cloud Security Alliance. Модель «помнит» структуру имён пакетов, но придумывает конкретные названия. Галлюцинирует, проще говоря.

Атакующие эксплуатируют это через Compromise Software Dependencies and Development Tools (T1195.001, Initial Access): регистрируют вымышленные имена на PyPI, npm, RubyGems и размещают вредоносный код. Разработчик запускает pip install или npm install по AI-сгенерированному requirements.txt - и получает малварь. В отличие от typosquatting (похожие имена), здесь LLM генерирует несуществующие имена сама, а атакующему остаётся только зарегистрировать их. Красивая атака, если подумать.

Проверка безопасности AI-кода в этом контексте начинается с верификации каждой зависимости: pip index versions <package> или npm view <package> version. Пакет не найден - это галлюцинация или уже supply chain compromise. При AI code security audit я ставлю этот шаг первым, до SAST и ревью логики.

AI-ассистенты программирования как цель атаки​

Поверхность атаки двунаправленная. AI-инструменты не только генерируют уязвимый код - они сами становятся мишенями для supply chain атак.

По данным CSA и Pradeo, в 2025 году раскрыты CVE против трёх крупнейших ассистентов:

Amazon Q Developer - атакующий эксплуатировал неправильно сконфигурированный GitHub-токен для инъекции вредоносного кода в расширение VS Code. Скомпрометированная версия распространялась через VS Code Marketplace несколько дней. Синтаксическая ошибка в payload предотвратила реальную эксплуатацию. Повезло - буквально.

Cursor - уязвимость CurXecute: удалённое выполнение кода через prompt injection из подключённого MCP-сервера. MCPoison - отравление MCP-конфигурации в shared-репозитории: разработчик одобряет легитимную конфигурацию и незаметно получает редирект на вредоносный сервер.

GitHub Copilot - инъекция невидимых Unicode-символов в rule-файлы Copilot и Cursor. Символы заставляли AI вставлять вредоносный код во все генерируемые файлы. Визуально файл выглядел чистым - а внутри сидела закладка.

Это T1195.001 (Compromise Software Dependencies and Development Tools) и T1213.003 (Code Repositories) на уровне самого инструмента разработки. Для уязвимостей no-code платформ риск ещё выше: Lovable и Bolt.new запускают сгенерированный код на собственных серверах. Уязвимость платформы автоматически означает уязвимость всех приложений на ней.

Для пентестера тут открывается интересный вектор: вместо атаки на целевое приложение - атака на AI-инструмент через вредоносный .cursor/rules или .github/copilot-instructions.md в shared-репозитории. Один файл - и потенциально скомпрометированы все проекты, где он подгрузится.

Практический аудит кода написанного AI​

Для полноценного покрытия нужны аналогичные правила под .format() и %-форматирование. На практике я запускаю кастомные правила параллельно со стандартными - это отделяет AI-специфичные находки от обычного технического долга. Для более глубокого анализа потоков данных - CodeQL: он позволяет отслеживать путь tainted data от пользовательского ввода до SQL-запроса через несколько файлов. AI-генерированный код часто размазывает обработку по модулям без единой точки валидации, и data flow analysis тут критичен.

Ещё один шаг при аудите кода написанного AI - проверка Git-истории. Каждая итерация промпта потенциально вносит регрессию. Если в проекте 40+ коммитов с пометками вроде «fix: updated per AI suggestion» - вероятность деградации безопасности высока. На бумаге формула понятна, но масштаб по-настоящему ощущаешь, когда прогоняешь Semgrep по каждому коммиту и видишь, как количество findings растёт от версии к версии. Готовый стенд для отработки этих навыков есть на HackerLab.pro - категории web, crypto, forensics и другие, где подобные паттерны вшиты в условия задач.

Семьдесят четыре подтверждённых CVE за три месяца - нижняя граница. Неудобная правда: многие команды до сих пор относятся к AI-генерированному коду как к собственному. Он прошёл через IDE, попал в PR, тесты зелёные - значит, код «наш». Это ошибка. AI-генерированный код - untrusted input, третья сторона. Уровень доверия к нему должен быть таким же, как к произвольной библиотеке с GitHub, у которой 12 звёзд и один контрибьютор.

Запрещать AI-ассистенты бессмысленно - 85% разработчиков уже ими пользуются. Но подход «сканируем после коммита» не масштабируется при десятикратном росте security-находок. Через год-два индустрия придёт к обязательному двойному контуру: контроль в момент взаимодействия с моделью и усиленный SAST/SCA с правилами под AI-паттерны. Кто этот контур не выстроит - будет разгребать CVE из своих vibe-coded сервисов, как сейчас разгребают Lovable-проекты с открытым Supabase. Если хочешь посмотреть, как типичные инъекции из AI-сгенерированных обработчиков эксплуатируются на живом стенде - на HackerLab есть web-задачи с этими паттернами в условии.