Материал

Lovable security incident: какие уроки для команд, которые выкатывают AI-built apps

Обновлено: 15 мая 2026 Время чтения: 16 мин

Когда «работает» ≠ «безопасно»: разбор трёх инцидентов одной платформы

Введение: почему кейс Lovable важен для каждой команды

В феврале 2025 года Андрей Карпатий ввёл термин «vibe coding» — подход, при котором разработчик описывает намерение, а AI строит приложение без необходимости читать или проверять каждую строку [1]. Collins English Dictionary назвал его словом 2025 года. К апрелю 2026-го отрасль получила три крупных инцидента за одну неделю, экспоненциальный рост AI-сгенерированных CVE и вредоносное ПО, специально нацеленное на учётные данные AI-инструментов [2].

Lovable — платформа стоимостью $6,6 млрд с восемью миллионами пользователей — оказалась в центре этой истории не потому, что она исключительно уязвима. Она репрезентативна [3]. Разбор её инцидентов даёт точную карту рисков, с которыми сталкивается любая команда, выкатывающая AI-built приложения в продакшен.

Материал адресован CTO, VP Engineering, Tech Lead и AppSec-специалистам, которые уже работают с AI-инструментами или планируют это делать.

Хронология: три инцидента за три месяца

Инцидент 1. CVE-2025-48757: Row Level Security отключён по умолчанию (май 2025 — март 2026)

В марте 2025 года разработчик Мэтт Палмер обнаружил критическую проблему: Lovable генерировала Supabase-схемы без включённых политик Row Level Security (RLS). Все приложения, построенные на платформе, используют Supabase как бэкенд — PostgreSQL, аутентификацию и файловое хранилище. Когда разработчик (в данном случае AI) не реализует RLS явно, публичный anon_key, встроенный в клиентский код, позволяет любому неаутентифицированному пользователю делать прямые запросы к базе данных [4].

Палмер сообщил об уязвимости 21 марта 2025 года. Спустя два месяца без публичного признания он опубликовал детальный разбор и CVE-запись. Сканирование показало: 303 эндпоинта в 170 проектах не имели корректных RLS-политик [4]. Извлекаемые данные включали полные пользовательские записи, платёжные данные, API-ключи — без какой-либо аутентификации.

Уязвимость стала системной по природе: один инсекьюрный дефолт платформы размножился на сотни живых приложений. Когда платформа встраивает небезопасные значения по умолчанию, каждое приложение, построенное на ней, наследует уязвимость [4].

Инцидент 2. Инвертированная логика аутентификации: 18 697 пользователей (февраль 2026)

27 февраля 2026 года технический предприниматель Таймур Хан опубликовал результаты аудита одного приложения, представленного на Discover-странице Lovable — оно набрало более 100 000 просмотров и ~400 апвотов [5]. За несколько часов тестирования он обнаружил 16 уязвимостей, шесть из которых критические.

Самая показательная: AI-сгенерированный код содержал инвертированную логику аутентификации.

IF auth.role() = 'authenticated' THEN
  RAISE EXCEPTION 'Access denied';
END IF;

Логика блокировала аутентифицированных пользователей и пропускала анонимных. Результат — полный доступ без логина ко всем 18 697 записям пользователей, включая 4 538 студентов UC Berkeley и UC Davis, с большой вероятностью несовершеннолетних [3]. Любой желающий мог просматривать данные, удалять аккаунты, изменять оценки, рассылать массовые email и получать доступ к курсам без входа в систему [5].

Этот тип ошибки — то, что Хан назвал «vibe hacking» — предсказуем: злоумышленник знает, что RLS, вероятно, неправильно настроен, логика аутентификации, возможно, инвертирована, а anon_key точно лежит в клиентском коде [6]. Сообщение Хана через канал поддержки Lovable было закрыто без ответа [3].

Инцидент 3. BOLA-регрессия: чаты публичных проектов доступны 48 дней (апрель 2026)

Апрельский инцидент затронул другой уровень — не сгенерированные приложения, а саму платформу Lovable. Исследователь под ником @weezerOSINT опубликовал на X: создав бесплатный аккаунт Lovable, он получил доступ к исходному коду другого пользователя, учётным данным базы данных, истории AI-чатов и пользовательским данным [7].

Механика: до марта 2025 года история чатов в публичных проектах была доступна по дизайну — как функция community и discovery. В процессе 2025 года Lovable постепенно закрывала этот доступ. В феврале 2026 года при унификации permission в бэкенде произошла регрессия — доступ к чатам публичных проектов был случайно восстановлен [8].

Исследователи отправили валидные репорты через Responsible Disclosure Program на HackerOne. Репорты были закрыты без эскалации, потому что команда HackerOne считала видимость чатов публичных проектов намеренным поведением — согласно устаревшей внутренней документации Lovable [8]. Уязвимость оставалась открытой 48 дней.

Из чатов публичных проектов можно было извлечь: API-ключи и учётные данные, вставленные пользователями при дебаггинге; секреты и конфигурационные данные, переданные AI для построения приложения; полный исходный код и историю изменений. Исследователь конкретно показал: он скачал исходный код admin-панели датской НКО, извлёк учётные данные базы данных из кода и получил реальные данные — имена, компании, LinkedIn-профили — реальных людей, которые не подозревали об утечке [7].

Анатомия провала: что именно пошло не так

Дефолты решают всё

Главная системная проблема кейса Lovable: платформа оптимизировала дефолты под discovery и community, а не под безопасность. Публичность была включена по умолчанию для ранних free-tier пользователей; enterprise-клиенты получили возможность создавать публичные проекты, не осознавая полных последствий; «public» для нетехнического пользователя означало «мое приложение видно», а не «мой исходный код, история чата и учётные данные открыты» [8].

Secure-by-default — не маркетинг, а архитектурный выбор. Lovable переключилась на private-by-default только в декабре 2025 года — после полутора лет работы в режиме public-by-default [8]. Bolt.new по-прежнему шипит с отключённым RLS по умолчанию [3].

«Функционально работает» ≠ «безопасно для продакшена»

AI-генератор кода оптимизирует результат на функциональность: код должен работать, тесты должны проходить. Безопасность — другой критерий оптимизации, который AI систематически недооценивает. Инвертированная логика аутентификации в EdTech-приложении — буквальный пример: код работал, тесты проходили, приложение отвечало на запросы. Дефект был в семантике, а не в синтаксисе [5].

Исследование CodeRabbit показало, что AI-написанный код содержит уязвимости в 2,74 раза чаще, чем человеческий — на выборке 470 GitHub pull requests [3]. Veracode зафиксировала, что 45% AI-сгенерированного кода содержит OWASP-уязвимости [9]. Оценка более 200 vibe-coded приложений в Q1 2026 обнаружила, что 91,5% содержат хотя бы одну уязвимость, связанную с AI-галлюцинацией [3].

IEEE-ISTAS провела контролируемый эксперимент и измерила рост критических уязвимостей на 37,6% после всего пяти раундов AI-assisted рефинирования кода [2]. Чем больше вы итерируете с AI — тем больше дыр.

BOLA: старейшая уязвимость в новой упаковке

BOLA (Broken Object Level Authorization) занимает первое место в OWASP API Security Top 10 с 2019 года и остаётся там в редакции 2023 года [10]. Механика: API доверяет object ID из пользовательского запроса и не проверяет, имеет ли пользователь право на доступ к конкретному объекту. Для эксплойта не нужны сложные инструменты — достаточно изменить ID в URL или теле запроса [11].

Апрельский инцидент Lovable — именно BOLA: отсутствовала проверка ownership в API-эндпоинтах платформы. Любой залогиненный пользователь мог получить данные проекта, которые ему не принадлежат, просто изменив несколько параметров API-запроса [7]. В отчёте Wallarm за Q2 2025 большинство эксплуатируемых API KEV — это BOLA-уязвимости [12].

Bug bounty без эскалации — это не bug bounty

Закрытие валидного репорта без эскалации — провал процесса, а не случайность. Lovable предоставила HackerOne устаревшую внутреннюю документацию, по которой доступность чатов публичных проектов выглядела как intentional behavior [8]. Результат: 48 дней открытой уязвимости после корректного responsible disclosure.

Публичная реакция: учебник по тому, как не надо

Ответ Lovable прошёл четыре стадии, каждая из которых усугубляла ситуацию [7]:

Отрицание: «Мы не пережили утечку данных».
Перекладывание на документацию: «Наша документация о том, что означает 'публичный', была неясной».
Перекладывание на HackerOne: «Репорты были закрыты без эскалации, потому что наши партнёры HackerOne считали видимость чатов намеренным поведением».
Частичные извинения: «Мы понимаем, что указания на проблемы с документацией было недостаточно».

Cybernews озаглавил свой материал: «Lovable отправляется в эго-трип, отрицая уязвимость, а затем обвиняет других за неё» [7]. Сам Lovable признал в официальном ответе: «Наша первая публичная реакция не попала в цель и создала больше путаницы. Нам следовало начать с того, что произошло, кто пострадал и что мы делаем для исправления» [8].

Для команд урок простой: disclosure требует чёткой структуры ответа — факты, масштаб, действия. Цикл отрицание → перекладывание ответственности → извинения разрушает доверие радикально быстрее, чем сам инцидент.

Secrets sprawl: параллельная эпидемия

Lovable — не изолированный случай. GitGuardian опубликовал State of Secrets Sprawl 2026 в марте 2026 года: 28,65 млн новых захардкоженных секретов добавлено в публичные GitHub-коммиты в 2025 году — рост 34% год к году, крупнейший за всю историю наблюдений [13].

AI-assisted коммиты дают скорость утечки секретов 3,2% против 1,5% базового уровня по всему публичному GitHub — примерно вдвое выше [13]. Причин несколько: AI-инструменты читают контекст кодовой базы, включая .env-файлы и конфигурации с учётными данными; автодополнение может воспроизводить паттерны секретов из обучающих данных; скорость генерации обгоняет скорость проверки.

Отдельная категория — MCP (Model Context Protocol). GitGuardian обнаружил 24 008 уникальных секретов, встроенных в MCP-конфигурационные файлы на GitHub: официальные quickstart-гайды рекомендуют передавать API-ключи напрямую в CLI-аргументы или JSON-конфигурации, нормализуя небезопасные паттерны [13].

Проблема не только в утечке — в неротации. 64% секретов, идентифицированных как действительные в 2022 году, оставались нероатированными к 2026 году [13]. Каждый залитый в публичный репозиторий секрет следует считать скомпрометированным немедленно: скреперы забирают новые коммиты в течение минут.

Что это означает для команд, выкатывающих AI-built apps

Слой 1. Архитектура: secure-by-default, не secure-by-documentation

Главный вывод из CVE-2025-48757 — дефолты имеют экспоненциальный масштаб. Один небезопасный дефолт платформы размножается на все приложения, построенные на ней. Команды, строящие на Supabase (через Lovable, Bolt или напрямую), должны включать RLS явно для каждой таблицы до первого деплоя [4]. Это не опция и не «best practice» — это базовый контроль, без которого любой anon_key в клиентском коде превращается в прямой доступ к базе данных.

Принцип least privilege должен быть зашит в первый коммит, а не добавлен после. OWASP рекомендует: всегда проверять авторизацию на уровне объекта на серверной стороне, не полагаться на клиентскую логику; использовать non-guessable object IDs (UUID вместо последовательных ID); встраивать авторизационные проверки на уровне доступа к данным, не только на уровне API-эндпоинта [10].

Слой 2. Кодовый ревью: AI-генерированный PR нельзя мёрджить без проверки авторизационной логики

Инвертированная логика аутентификации в EdTech-приложении — это ошибка, которую code reviewer поймает за секунды. AI-генератор её пропустил, потому что оптимизирует по другому критерию. Хан прямо написал: «Этот баг мог проскользнуть через AI-генерацию кода без надлежащего ревью» [5].

Команды должны выстраивать ревью AI-генерированного кода с особым вниманием к нескольким классам изменений:

логика аутентификации и авторизации (кто имеет право на доступ к объекту?);
конфигурации базы данных (RLS, политики доступа, service role key vs anon key);
API-эндпоинты, возвращающие данные других пользователей;
visibility-настройки (что означает «публичный» в данном контексте?);
.gitignore и CI/CD-конфиги (не попадают ли в них секреты?).

Важно: AI self-review систематически пропускает инфраструктурные и контекст-специфические проблемы. Пентестер, проверявший AI-отревьюированное приложение, нашёл в нём оставшиеся уязвимости [14].

Слой 3. Секреты: ротация и сканирование до мёрджа

GitGuardian рекомендует [13]:

Pre-commit сканирование (ggshield, detect-secrets, trufflehog) — до того, как секрет попадает в репозиторий;
никогда не хардкодить секреты в MCP-конфигурациях и AI-тулинге;
добавить mcp.json, .cursor/ и аналогичные AI-конфиги в .gitignore;
любой закоммиченный секрет — даже в приватный репозиторий — ротировать немедленно;
ротационный SLA по классам секретов: production-ключи, database credentials, третьесторонние SaaS-токены, AI-провайдерские ключи.

Слой 4. Bug bounty и disclosure: процесс, а не формальность

Апрельский инцидент Lovable показал: bug bounty-программа, чьи репорты закрываются без эскалации к внутренней команде, не защищает. Ключевые требования к процессу:

triage-команда должна иметь актуальную документацию о том, что является намеренным поведением;
валидный репорт должен попадать к инженерной команде, а не только к внешнему провайдеру;
регрессии в permission/access control требуют немедленной эскалации;
первый публичный ответ должен содержать факты, масштаб и план действий — не отрицание.

Слой 5. Visibility-настройки: пользователь не понимает, что означает «публичный»

Это системная проблема продукта, но для команд, которые строят инструменты на AI-платформах или сами создают инструменты разработки, она критически важна. Lovable прямо признала: «Многие пользователи думали, что 'публичный' означает только то, что другие могут видеть их опубликованное приложение, а не историю чата неопубликованного проекта» [8].

Если ваш продукт имеет visibility-настройки, которые влияют на доступность кода, данных или истории взаимодействия — интерфейс должен делать последствия явными. Не в документации, а непосредственно в точке выбора.

Чек-лист: минимальный security gate для AI-built apps

Перед мёрджем любого AI-сгенерированного изменения:

Проверить: включён ли RLS для всех таблиц базы данных?
Проверить: логика аутентификации не инвертирована (authenticated = доступ, unauthenticated = отказ)?
Проверить: API-эндпоинты проверяют ownership объекта на серверной стороне?
Проверить: нет ли захардкоженных секретов в коде, конфигах, MCP-файлах?
Проверить: .gitignore покрывает AI-тулинг (.cursor/, mcp.json, .env.*)?
Проверить: anon_key Supabase не открывает доступ к чувствительным таблицам?

Перед релизом:

Проверить: что именно означает visibility-настройка проекта для конечного пользователя?
Проверить: есть ли секреты, которые следует ротировать после деплоя?
Проверить: инфраструктурные конфиги (CI/CD, MCP) не содержат production-секретов?
Проверить: кто получит алерт, если в репозиторий попадёт секрет?

Тренды: куда движется угроза

CVE, напрямую атрибутированные AI-сгенерированному коду, росли с 6 в январе 2026 года до 35 в марте 2026 года [2]. Gartner прогнозирует, что 60% всего нового кода будет AI-генерированным к концу 2026 года [3]. При текущей динамике — 2,74-кратный рост дефектов безопасности в AI-коде плюс экспоненциальный рост объёма — без системного контроля скорость появления уязвимостей будет расти быстрее, чем скорость их исправления.

Параллельно расширяется атакуемая поверхность: AI-агенты получают локальный доступ к редакторам, терминалам и credential stores разработчиков. В исследовании Shai-Hulud 2, которое GitGuardian анализирует в своём отчёте, 59% скомпрометированных машин были CI/CD-раннерами, а не персональными ноутбуками [13]. Секреты из AI-окружения разработчика становятся организационным риском.

EU AI Act начинает применять обязательства для высокорисковых систем с 2 августа 2026 года [15]. Команды, строящие AI-приложения на чувствительных данных (образование, здравоохранение, финансы), уже сейчас должны закладывать соответствующие контроли в архитектуру — задним числом это делать значительно дороже.

HighVibe как слой контроля до merge и релиза

Описанные выше уязвимости объединяет одно: они были в коде (или конфигурации) до мёрджа и до релиза. Инвертированная логика аутентификации существовала в PR. Отключённый RLS — в схеме базы данных, переданной на ревью. Захардкоженный секрет — в diff.

Именно в этой точке работает HighVibe: анализ конкретного изменения — кода, конфигурации, зависимостей, служебных файлов — до того, как оно попадает в main и уходит в релиз. Не ещё один длинный отчёт по всему репозиторию, а короткий, понятный сигнал: можно ли безопасно принять это изменение прямо сейчас, и если нет — что конкретно блокирует.

В мире, где AI генерирует код быстрее, чем команда успевает его дочитать, контроль нужен именно там — в точке изменения.

Заключение: что делать прямо сейчас

Lovable security incidents — это не история об одной платформе. Это история о структурном разрыве между скоростью генерации AI-кода и зрелостью контроля изменений. Разрыв существует во всей категории: Bolt.new шипит с отключённым RLS по умолчанию, Cursor получил несколько CVE, включая bypass с персист-RCE [3].

Три практических шага, которые команда может сделать сегодня:

Провести аудит всех публичных проектов на AI-платформах: что именно открыто под «публичным» — только приложение или исходный код и история чатов?
Включить pre-commit сканирование секретов и добавить AI-конфиги в .gitignore.
Добавить явные проверки RLS и авторизационной логики в чеклист PR-ревью.

«Работает» и «безопасно для продакшена» — разные утверждения. AI сделал первое доступным для всех. Второе по-прежнему требует явного контроля.

Источники

[1] Andrej Karpathy — "There's a new kind of coding I call 'vibe coding'" — https://x.com/karpathy/status/1886192184808149343

[2] State of Surveillance — "Three AI Security Disasters in One Week. The Vibe Coding Reckoning Is Here." — https://stateofsurveillance.org/news/vibe-coding-security-crisis-lovable-vercel-bitwarden-ai-attack-surface-2026/

[3] The Next Web — "Lovable security crisis: 48 days of exposed projects, closed bug reports, & the structural failure of vibe coding security" — https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed

[4] Superblocks — "Lovable Vulnerability Explained: How 170+ Apps Were Exposed" — https://www.superblocks.com/blog/lovable-vulnerabilities

[5] The Register — "AI-built app on Lovable exposed 18K users, researcher claims" — https://www.theregister.com/2026/02/27/lovable_app_vulnerabilities/

[6] Engineers Corner — "Vercel, Lovable and GitHub Copilot Hacked: The AI Security Crisis No One Warned You About (2026)" — https://engineerscorner.in/ai-tools-security-breach-vercel-lovable-2026/

[7] Cybernews — "Lovable goes on ego trip denying vulnerability, then blames others for said vulnerability" — https://cybernews.com/security/lovable-vibe-coding-flaw-apology/

[8] Lovable — "Our response to the April 2026 incident" — https://lovable.dev/blog/our-response-to-the-april-2026-incident

[9] Vibe Coder Blog — "The Security Crisis in AI-Generated Code in 2026" — https://blog.vibecoder.me/security-crisis-ai-generated-code-2026

[10] APIsec — "BOLA Explained: OWASP API Security Principle 1 for Teams" — https://www.apisec.ai/blog/understanding-broken-object-level-authorization-bola-owasp-api-security-principle-1

[11] Wallarm — "API Attack Awareness: Broken Object Level Authorization (BOLA) – Why It Tops the OWASP API Top 10" — https://securityboulevard.com/2025/10/api-attack-awareness-broken-object-level-authorization-bola-why-it-tops-the-owasp-api-top-10/

[12] Halborn — "Lovable Data Leak: BOLA Vulnerability and App Security Risks" — https://www.halborn.com/blog/post/lovable-data-leak-bola-vulnerability-and-app-security-risks

[13] GitGuardian — "The State of Secrets Sprawl 2026" — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/

[14] Vibe Coding App — "AI Generated Code Vulnerabilities: 7 Security Risks in 2026" — https://vibecoding.app/blog/ai-generated-code-security-risks

[15] Mak it Solutions — "Trusted AI Tooling Policy for Developers Template" — https://makitsol.com/trusted-ai-tooling-policy-for-developers-template/