Base44: почему уязвимость в одной vibe coding платформе — это проблема всей индустрии

Один app_id, ноль аутентификации, полный доступ к корпоративным данным. История уязвимости Base44 — и то, что она говорит о безопасности AI-разработки в целом

Демократизация разработки — и её цена

Когда в феврале 2025 года Андрей Карпатий ввёл термин «vibe coding» в оборот — описав подход, при котором разработчик полностью доверяет AI генерировать код, не вникая в детали реализации, — никто особо не думал о безопасности [1]. Думали о скорости, доступности, о том, что любой теперь может собрать работающее приложение за часы. Словарь Collins English Dictionary назвал «vibe coding» словом года 2025 [32]. Lovable вышла на $1,8 млрд оценки за несколько месяцев. Base44 достигла 20 000 пользователей.

А потом началась другая история.

Июль 2025 года: исследователи Wiz обнаруживают, что любой желающий может получить полный доступ к любому приватному корпоративному приложению, собранному на Base44, — просто зная публичный идентификатор приложения. Август 2025-го: отчёт фиксирует, что 45% AI-сгенерированного кода содержит уязвимости [8]. Апрель 2026-го: три крупных security-инцидента в vibe coding экосистеме за одну неделю — Lovable, Vercel, Bitwarden [33].

Это не ошибки отдельных разработчиков. Это системная проблема архитектуры и модели угроз новой категории платформ.

Для CTO, VP Engineering, Tech Lead и AppSec-специалистов, которые уже используют или рассматривают vibe coding инструменты для корпоративной разработки, история Base44 — обязательный разбор.

Что такое vibe coding платформа и почему её модель угроз отличается от SaaS

Прежде чем разбирать уязвимость, важно понять архитектурный контекст.

Классические vibe coding платформы — Base44, Lovable, Bolt.new, Replit, Cursor — работают по принципу shared infrastructure: все приложения, созданные пользователями, живут на инфраструктуре одного вендора [12]. Это не просто хостинг. Это означает, что:

• Каждый клиент наследует security posture платформы целиком.
• Единственная уязвимость в платформенном ядре — особенно в критическом компоненте вроде аутентификации — мгновенно ставит под угрозу все приложения, созданные на платформе, одновременно [12].
• Атакующий, нашедший системный изъян, получает не один target, а весь «торговый центр» клиентских данных.

Это принципиально иная модель риска по сравнению с традиционным SaaS, где у каждого клиента изолированный инстанс. Wiz сформулировали это коротко и точно: вместо одной точки отказа у вендора появляется единая точка компрометации для всех клиентов [1].

К этому добавляется второй структурный фактор — демографический сдвиг разработчиков. Vibe coding инструменты сознательно ориентированы на пользователей без глубокой технической экспертизы. Именно в этом их ценностное предложение. Но это означает, что многие приложения создаются людьми, которые не знают о Row Level Security, открытых API-эндпоинтах или принципе least privilege. AI генерирует код, который работает — но «работает» не равно «безопасно» [3].

Base44: анатомия уязвимости

Хронология

• 9 июля 2025 — исследователи Wiz Research обнаруживают критическую уязвимость и немедленно направляют отчёт в Wix и Base44 [1].
• 10 июля 2025 — исследователи верифицируют патч: внешние пользователи больше не могут регистрироваться в приватных приложениях [1].
• 13 июля 2025 — Wix официально подтверждает полное устранение проблемы и отсутствие следов злоупотреблений [1].

Время от обнаружения до патча — менее 24 часов. Это лучшая практика ответственного disclosure. Но сама механика уязвимости требует детального разбора.

Техническая суть

Base44 — low-code платформа, позволяющая собирать функциональные приложения из natural language описаний. Каждое созданное приложение получает уникальный app_id, который виден в URI приложения и в его manifest.json — то есть публично доступен любому, кто знает, где смотреть [6].

Исследователи Wiz обнаружили два API-эндпоинта, которые по умолчанию должны были быть закрытыми, но оказались доступны без какой-либо аутентификации [4]:

• api/apps/{app_id}/auth/register — регистрация нового пользователя
• api/apps/{app_id}/auth/verify-otp — верификация по одноразовому паролю

Алгоритм атаки элементарен: берёшь публичный app_id, подставляешь в эти эндпоинты, регистрируешь валидный верифицированный аккаунт — и получаешь доступ к приватному приложению, минуя SSO и любые другие механизмы аутентификации [2]. Никакой специальной технической подготовки не требуется: достаточно базового понимания работы API.

Gal Nagli из Wiz Research описал это так: после подтверждения email можно было просто войти через SSO внутри страницы приложения и полностью обойти аутентификацию [7].

Что было под угрозой

Исследователи подтвердили, что authentication bypass был доступен в нескольких корпоративных приложениях, использующих платформу: внутренние чат-боты, базы знаний, системы с ПДн и HR-операциями [1]. Enterprise-компании доверяли платформе чувствительные корпоративные данные — и все они оказались потенциально уязвимы к неавторизованному доступу со стороны любого, кто нашёл бы нужный app_id.

Важный нюанс: app_id не был секретным. Wiz обнаружили, что идентификаторы приложений легко находятся через публичную разведку — трассировку CNAME-записей и анализ HTML-сигнатур платформы [2]. Низкий порог входа для атакующего при высоком потенциальном ущербе — классическое сочетание для системного риска.

Это не единичный случай: паттерн повторяется

История Base44 заслуживала бы внимания сама по себе — но её реальная ценность в том, что она типична для всей категории.

Lovable: CVE-2025-48757

В марте 2025 года исследователи обнаружили критическую уязвимость в Lovable — одной из самых быстрорастущих vibe coding платформ ($6,6 млрд оценка к декабрю 2025). Проблема: отсутствие или некорректная конфигурация Row Level Security политик в Supabase-базах данных, которые генерировала платформа [38].

CVE-2025-48757 (CVSS 8.26–9.3) позволяла любому неаутентифицированному атакующему читать и записывать произвольные таблицы баз данных приложений, собранных на Lovable [34]. Инженер Palantir Technologies воспроизвёл атаку за 15 строк Python и менее чем за час вытащил из нескольких приложений суммы долгов, домашние адреса и API-ключи [36].

Масштаб: 170 из 1 645 просканированных приложений Lovable Marketplace были уязвимы. 70% приложений платформы имели Row Level Security отключённым целиком [15]. Исследователь Matt Palmer, обнаруживший уязвимость, направил детальный отчёт Lovable 21 марта 2025-го. Ответа с реальными действиями не последовало. 29 мая был опубликован CVE [38].

Характерная деталь: Lovable выпустила security scanner — но он лишь проверяет факт наличия RLS политики, не её корректность. «Политика, разрешающая всем аутентифицированным пользователям видеть все данные, пройдёт сканер — но это всё равно broken access control», отметили в Superblocks [31].

Moltbook, Tea App, Bolt.new

Паттерн воспроизводится в других случаях. Moltbook — vibe-coded социальная сеть — была взломана через три дня после запуска: утекло 1,5 млн токенов API-аутентификации и 35 000 email-адресов через некорректно настроенную Supabase без Row Level Security [35]. Tea App потеряла ~72 000 изображений, включая фото удостоверений личности, из-за Firebase-хранилища с настройками по умолчанию без политик авторизации [20]. Bolt.new — ещё одна популярная vibe coding платформа — по умолчанию поставляется с отключённым Row Level Security [32].

Апрель 2026: три инцидента за неделю

К апрелю 2026 года паттерн оформился в системный кризис. За одну неделю: Lovable пережила третий major security инцидент — BOLA (Broken Object Level Authorization, #1 OWASP API Security Top 10) открывал исходный код, учётные данные баз данных и историю AI-чатов любого пользователя; через Context.ai атакующие получили доступ к внутренним системам Vercel; в Bitwarden CLI обнаружили supply chain атаку, целенаправленно охотящуюся за credentials к Claude, Cursor и Codex CLI [33].

Структурные причины: почему vibe coding расширяет attack surface

Анализируя конкретные инциденты, можно выделить несколько системных факторов, превращающих vibe coding платформы в расширенную поверхность атаки.

1. Shared infrastructure как force multiplier для атакующего

Когда все клиентские приложения живут на общей инфраструктуре вендора, одна уязвимость в платформенном ядре масштабируется до всей клиентской базы мгновенно [12]. Это фундаментально отличается от традиционной корпоративной разработки, где каждое приложение имеет собственный периметр.

2. AI-сгенерированный код оптимизирован не под безопасность

Veracode в своём отчёте 2025 года протестировала более 100 LLM на 80 сценариях разработки и зафиксировала: 45% AI-сгенерированного кода содержит уязвимости [47]. Java показал наихудший результат — более 70% случаев с дефектами; Python, C# и JavaScript — от 38% до 45%. При этом функциональные показатели моделей росли, а security pass rates — нет [47]. Модели оптимизируются под то, чтобы код компилировался и работал, а не под то, чтобы он был безопасен.

Независимые исследования NYU и BaxBench подтвердили диапазон в 40–62% AI-сгенерированного кода с security дефектами [11].

3. Исчезновение security gates при vibe coding

Традиционный SDLC предполагает итерации с code review, статический анализ, threat modeling. Философия vibe coding — «полностью довериться AI» — системно обходит эти практики [11]. Разработчики не дочитывают сгенерированный код до конца. Новые зависимости появляются незаметно. Internal tools, конфиги и миграции проходят ещё меньший контроль.

4. Shadow IT на новом масштабе

Vibe coding делает разработку доступной для людей без технического образования. По данным Contrast Security, это масштабирует Shadow IT до корпоративных размеров: приложения с чувствительными данными создаются и деплоятся полностью за периметром IT и security команд [11]. SecOps вынуждены защищать растущий портфель production-приложений, о которых они могут не знать.

5. Платформа как точка в supply chain

CVE-2025-48757 иллюстрирует ещё один вектор: платформа-провайдер становится точкой в software supply chain. Небезопасные defaults, которые вендор закладывает в генерируемые проекты, наследуют все downstream приложения [34]. Это supply chain риск нового типа — не зловредный пакет в npm, а системный дизайн платформы.

6. Инструменты разработчика как вектор атаки

Параллельно с рисками генерируемого кода существует риск самих AI-инструментов как attack surface. CVE-2025-54135 (CurXecute) в Cursor позволял удалённо выполнять код на машине разработчика через MCP-сервер без какого-либо взаимодействия со стороны пользователя [16]. CVE-2025-53109 позволял читать и записывать произвольные файлы через MCP-сервер Anthropic [10]. Уязвимость в Claude Code (CVE-2025-55284) позволяла эксфильтровать данные через DNS-запросы [10]. Атака начинается не в приложении, которое разработчик строит, — она начинается в инструменте, которым он его строит.

Классификация уязвимостей: что именно ломается

Анализируя задокументированные инциденты 2025–2026 годов, можно выделить несколько классов проблем.

Broken Authentication и Broken Access Control (OWASP A01, A07)

Base44 — чистый пример: отсутствие проверки аутентификации на критических эндпоинтах. Lovable CVE-2025-48757 — Broken Access Control через некорректные RLS политики. BOLA в апреле 2026-го — #1 OWASP API Security Top 10: платформа проверяла наличие валидного логина, но не проверяла, владеет ли пользователь запрашиваемым ресурсом [33].

Эти уязвимости — не новые. Они перечислены в OWASP Top 10 ещё с 2003 года. Но в контексте vibe coding они воспроизводятся системно: AI не знает о security requirements по умолчанию, если они не указаны явно в промпте [11].

Security Misconfiguration (OWASP A02)

Firebase без политик авторизации, Supabase без Row Level Security, публично доступные Swagger UI — это не баги кода, это defaults. Платформы, которые «вайбируют» инфраструктуру за пользователя, закладывают misconfiguration на уровне шаблона [8].

Hardcoded Secrets

AI-assisted commits экспонируют секреты более чем в два раза чаще, чем human-only commits — 3,2% против 1,5% [47]. Публичный GitHub зафиксировал рост hardcoded credentials на 34% год к году. API-ключи, database credentials, tokens — AI генерирует работающий код с секретами прямо в исходнике.

Package Hallucinations и Supply Chain

Исследование Socket.dev выявило более 205 000 уникальных hallucinated package names в 576 000 code samples [46]. Пакеты, которые AI придумывает, но которых не существует, — готовая почва для typosquatting атак. В августе 2025 злоумышленники опубликовали пять typosquatted пакетов, нацеленных на Bittensor, в течение 25 минут [20].

Prompt Injection на уровне платформы

OWASP LLM Top 10 2025 выделяет prompt injection как ключевой вектор для LLM-приложений [41]. В контексте vibe coding инструментов это означает: вредоносные инструкции, встроенные в конфигурационные файлы, readme.md или Jira-задачи, могут быть исполнены AI-агентом без ведома разработчика.

Что это означает для команд: risk assessment

Прежде чем переходить к рекомендациям, важно честно оценить ситуацию. Речь не о том, что vibe coding нужно запретить — это нереалистично и контрпродуктивно. Речь о том, что adoption без осознанного контроля создаёт долг, который предъявляют счёт в самый неподходящий момент.

Оценивайте риск по трём осям:

Первая ось — что конкретно строится. Внутренний инструмент для команды из пяти человек без доступа к production-данным и корпоративный HR-портал, обрабатывающий ПДн тысяч сотрудников, — не одинаковые риски, даже если оба собраны на одной платформе.

Вторая ось — кто строит. Опытный backend-инженер, проверяющий каждый сгенерированный блок, и non-technical citizen developer, принимающий всё на веру, дают принципиально разные профили риска.

Третья ось — где живёт приложение. Shared-infrastructure vibe coding платформа означает, что security posture в том числе зависит от вендора. Enterprise с isolated deployment контролирует значительно больше переменных.

Практические рекомендации: что проверять до merge и релиза

Governance и политика

Первый шаг — не технический, а организационный. Infosecurity Magazine и CSA рекомендуют CISOs [42]:

• Ввести separation of duties: AI-агенты работают только в dev/test окружениях, прямой доступ к production исключён.
• Обязательный human-in-the-loop review для всех PR, особенно от non-developers.
• Инвентаризация всех AI-инструментов, IDE-плагинов и MCP-серверов, используемых командой.
• Политика allow-list: только явно одобренные платформы и инструменты.

Технические контроли: что проверять в каждом PR

Cloud Security Alliance в Secure Vibe Coding Guide [41] и практика Aikido [45] дают следующий набор проверок:

Аутентификация и авторизация:

• Все non-public эндпоинты требуют аутентификации — без исключений.
• Authorization checks проверяют не только «залогинен ли пользователь», но и «имеет ли он право на этот конкретный ресурс» (BOLA prevention).
• Row Level Security включён и корректно настроен на уровне базы данных — не только на уровне application logic.
• SSO и OAuth флоу не обходятся через вспомогательные эндпоинты (уязвимость Base44).

Secrets management:

• Нет hardcoded credentials в исходном коде — ни API-ключей, ни database connection strings, ни токенов.
• Секреты хранятся в secrets management системах (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) [13].
• Регулярная ротация ключей.

Dependencies:

• Все новые зависимости проверяются — особенно транзитивные.
• Lock-файлы фиксируются в репозитории.
• Сканирование на known vulnerabilities через advisories и SCA-инструменты.
• Проверка на typosquatting и hallucinated package names.

API design:

• Документированные эндпоинты не разошлись с фактической реализацией (Swagger UI не выставлен наружу в production).
• Rate limiting на всех публичных эндпоинтах.
• CORS настроен restrictively, а не широко.

Infrastructure defaults:

• Firebase, Supabase и другие BaaS-сервисы настроены с явными политиками авторизации — не defaults.
• Debug-режимы и verbose error messages отключены в production.

Что проверять перед релизом

• Изменения в конфигурационных файлах, CI/CD-пайплайнах, IaC — требуют отдельного внимания: AI генерирует их хуже всего с точки зрения security.
• Новые или обновлённые зависимости — проверка advisories перед каждым релизом.
• Поведенческое тестирование: проверка не «существует ли RLS политика», а «действительно ли пользователь A не видит данные пользователя B».
• Проверка, что аутентифицированный и неаутентифицированный запросы к одному ресурсу дают разный результат.

Выбор vibe coding платформы: на что смотреть

При оценке платформы для корпоративного использования стоит задавать конкретные вопросы:

• Какова модель данных: shared infrastructure или isolated per-tenant?
• Какой security posture у вендора: есть ли bug bounty, responsible disclosure policy, время реакции на критические уязвимости?
• Какие defaults генерирует платформа: RLS включён по умолчанию? Есть ли security-focused шаблоны?
• Как платформа обрабатывает Swagger UI и другие инфраструктурные компоненты — публично или приватно?
• Какой аудит доступен: логи регистраций, аномальных обращений, изменений в user base?

Ошибки, которые совершают команды

«Платформа сама всё обеспечит»

Base44 и Lovable наглядно показали: платформа может предоставить инфраструктуру, но security-модель — зона совместной ответственности. Вендор отвечает за платформенный уровень; команда-пользователь отвечает за то, что строит поверх него.

«Мы используем SAST — значит, защищены»

SAST-сканеры ищут известные паттерны в коде. Они не обнаружат инвертированную логику авторизации (как в CVE-2025-48757, где AI заблокировал аутентифицированных пользователей и открыл доступ анонимам [35]), не проверят корректность RLS-политики, не поймут бизнес-логику authorization на уровне объектов. Поведенческие уязвимости требуют поведенческого тестирования [16].

«PR небольшой, смотреть некогда»

Данные показывают обратное: именно в небольших, «невинных» изменениях — новая зависимость, обновлённый конфигурационный файл, правка в auth-модуле — чаще всего прячутся риски, которые не замечают при беглом review.

«Security scanner нашёл нуль проблем»

Ложное чувство безопасности опаснее отсутствия сканера. Если инструмент проверяет только факт наличия контроля, но не его корректность — результат «чисто» не означает «безопасно».

Контрольный слой для AI-разработки

Wiz Research, завершая разбор Base44, сформулировали ключевой вывод точно: фундаментальные контроли — правильная аутентификация и secure API design — являются первичными [3]. Они не должны быть afterthought. Но именно afterthought они и становятся, когда скорость delivery превышает скорость роста контроля изменений.

Здесь важна честность: AI уже ускорил разработку. Это факт, который не изменится. Но рабочий pull request не обязательно безопасен. Дифы дочитывают не до конца. Новая зависимость появляется тихо. Конфиги и internal tools читают хуже всего. А перед релизом нужен короткий ответ «что действительно блокирует выпуск» — а не ещё один длинный отчёт, который некому читать.

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

Тренды: что будет дальше

Несколько тенденций, подтверждённых исследованиями и публичными заявлениями:

По данным DX Research (февраль 2026), 92,6% разработчиков используют AI-ассистент хотя бы раз в месяц, около 75% — еженедельно [42]. Gartner прогнозирует, что 60% всего нового кода к концу 2026 года будет AI-сгенерированным [32]. Enterprise adoption vibe coding вырос на 340% год к году; non-technical user adoption — на 520% [32]. 87% компаний из Fortune 500 уже используют хотя бы одну vibe coding платформу [32].

По данным Georgia Tech SSLab, только в марте 2026 года было задокументировано не менее 35 новых CVE, являющихся прямым следствием AI-сгенерированного кода [14]. Количество MCP-серверов, доступных в интернете без аутентификации, к середине 2025 достигло 1 862 [7].

Глава NCSC Великобритании на RSA Conference 2026 заявил, что индустрия должна использовать возможности vibe coding для создания инструментов, обеспечивающих «secure by design» — и что это должно стать приоритетом [14].

Регуляторный контекст добавляет давления: EU AI Act высокорисковые обязательства вступают в силу с 2 августа 2026 года [15]. Платформы, используемые в HR, критической инфраструктуре или здравоохранении, могут автоматически попасть в high-risk категорию с соответствующими требованиями к документации и oversight [5].

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

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

Три вывода, которые стоит унести из этого разбора:

Во-первых, shared-infrastructure vibe coding платформы создают принципиально новую модель риска. Один дефект вендора = потенциальная компрометация всей клиентской базы. Это нужно учитывать при выборе платформ для корпоративных кейсов с чувствительными данными.

Во-вторых, «работает» и «безопасно» — разные утверждения. AI оптимизирует код под первое. Security команда отвечает за второе. Это не меняется с ростом возможностей моделей — показатель уязвимостей остаётся стабильным при растущей функциональности.

В-третьих, классический AppSec-стек недостаточен для новой поверхности атаки. Поведенческие уязвимости требуют поведенческого тестирования. Конфигурационные риски требуют проверки defaults. Зависимости требуют проверки при каждом изменении. И всё это — до merge и релиза, не после.

Скорость AI-разработки — это конкурентное преимущество. Но только если контроль изменений успевает за ней.

Источники

[1] Wiz Blog — "Critical Vulnerability in AI Vibe Coding Platform Base44" — https://www.wiz.io/blog/critical-vulnerability-base44

[2] Infosecurity Magazine — "Critical Authentication Flaw Identified in Base44 Vibe Coding Platform" — https://www.infosecurity-magazine.com/news/authentication-flaw-base44/

[3] Dark Reading — "Critical Flaw in Vibe-Coding Platform Base44 Exposes Apps" — https://www.darkreading.com/application-security/critical-flaw-vibe-coding-base44-exposed-apps

[4] Nudge Security — "Critical Vulnerability Identified in Base44 Vibe Coding Platform" — https://www.nudgesecurity.com/post/critical-vulnerability-identified-in-base44-vibe-coding-platform-allowing-unauthorized-access-to-private-applications

[5] Veracode — "Base44 Vulnerability Sparks Conversations on Securing Vibe Coding" — https://www.veracode.com/blog/base44-vulnerability-sparks-conversations-on-securing-vibe-coding/

[6] SecurityWeek — "Flaw in Vibe Coding Platform Base44 Exposed Private Enterprise Applications" — https://www.securityweek.com/flaw-in-vibe-coding-platform-base44-exposed-private-enterprise-applications/

[7] The Hacker News — "Wiz Uncovers Critical Access Bypass Flaw in AI-Powered Vibe Coding Platform Base44" — https://thehackernews.com/2025/07/wiz-uncovers-critical-access-bypass.html

[8] Wiz Academy — "Vibe Coding Security Fundamentals" — https://www.wiz.io/academy/ai-security/vibe-coding-security

[9] Defakto Security — "Wiz's Base44 Vulnerability Findings Spotlight a Fixable Gap: Non-Human Identity" — https://www.defakto.security/blog/wiz-base44-vulnerability-non-human-identity/

[10] Kaspersky — "Security Risks of Vibe Coding and LLM Assistants for Developers" — https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584/

[11] Contrast Security — "What is Vibe Coding? Impact, Security Risks, and Vulnerabilities" — https://www.contrastsecurity.com/glossary/vibe-coding

[12] Accorian — "Security Impact of Vibe Coding Vulnerabilities & Risks" — https://www.accorian.com/security-impact-of-vibe-coding-deep-dive-part-1-of-2/

[13] Knostic — "Top Vibe Coding Security Risks and How to Fix Them" — https://www.knostic.ai/blog/vibe-coding-security

[14] Infosecurity Magazine — "How Security Leaders Can Safeguard Against Vibe Coding Security Risks" — https://www.infosecurity-magazine.com/news-features/how-safeguard-vibe-coding-security/

[15] 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/

[16] GetAutonoma — "Vibe Coding Security Risks: Why 53% of AI Code Has Security Holes" — https://getautonoma.com/blog/vibe-coding-security-risks

[17] Netlas — "Top Vibe-Coding Security Risks" — https://netlas.io/blog/vibe-coding-security-risks/

[18] OWASP — "OWASP Top 10:2025" — https://owasp.org/Top10/2025/0x00_2025-Introduction/

[19] OWASP — "Top 10 for Large Language Model Applications" — https://owasp.org/www-project-top-10-for-large-language-model-applications/

[20] Cloud Security Alliance — "Secure Vibe Coding Guide" — https://cloudsecurityalliance.org/blog/2025/04/09/secure-vibe-coding-guide

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

[22] The Next Web — "Lovable Security Crisis: 48 Days of Exposed Projects" — https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed

[23] SentinelOne — "CVE-2025-48757: Lovable Information Disclosure Vulnerability" — https://www.sentinelone.com/vulnerability-database/cve-2025-48757/

[24] GetAutonoma — "Vibe Coding Failures: 7 Real Apps That Broke in Production" — https://getautonoma.com/blog/vibe-coding-failures

[25] XDA Developers — "I Keep Finding Vibe Coded Apps That Leak User Data" — https://www.xda-developers.com/keep-finding-vibe-coded-apps-leak-user-data/

[26] Matt Palmer — "Statement on CVE-2025-48757" — https://mattpalmer.io/posts/statement-on-CVE-2025-48757/

[27] Desplega.ai — "Vibe Break Chapter IV: The Lovable Inadvertence" — https://www.desplega.ai/blog/vibe-break-chapter-iv-the-lovable-inadvertence

[28] CSA Labs — "Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[29] SoftwareMill — "Vibe Coding Against OWASP Top 10 2025" — https://softwaremill.com/vibe-coding-against-owasp-top-10-2025/

[30] Aikido — "CISO Vibe Coding Checklist: Securing AI-Built Apps" — https://www.aikido.dev/blog/ciso-vibe-coding-security-checklist