Низкий порог входа, высокий риск — как уязвимость в Lovable открыла данные тысяч пользователей

Платформа Lovable, позиционируемая как low‑code решение для создания веб-приложений и сайтов, где основное взаимодействие с системой происходит через чат с искусственным интеллектом ^[1], столкнулась с критической уязвимостью, связанной с RLS-политиками. Она позволила получать и изменять данные без аутентификации — сотни проектов оказались под угрозой.

Хронология обнаружения

20 марта 2025 года исследователь безопасности Мэтт Палмер обнаружил критическую брешь на сайте Linkable, созданном на Lovable. С помощью простых запросов он получил полный доступ к таблице users через публичный REST API Supabase.

Официальный идентификатор уязвимости CVE-2025-48757 был опубликован 29 мая 2025 года с критическим рейтингом CVSS 3.1 — 9.3 балла.

Суть уязвимости

Lovable по умолчанию включала Row-Level Security (RLS) политики в базе данных Postgres, однако на практике политики часто выглядели так:

USING (true)

Эта запись не ограничивает доступ к данным никак, открывая их для всех пользователей, включая неавторизованных. В результате:

• Любой мог читать данные из открытых таблиц с помощью запроса типа ?select=*.

• Злоумышленник мог изменять данные, например, переводя платежи в статус «paid» с помощью простого POST-запроса с использованием стандартного ключа анонимного доступа (anon-key).

Масштабы проблемы

Палмер просканировал 1645 проектов на платформе Lovable, обнаружив:

• 303 уязвимых REST-эндпоинта.

• 170 сайтов (около 10% от общего числа) предоставляли доступ к конфиденциальным данным.

Доступ открывался к личной информации пользователей, платежным данным, API-ключам и другим критически важным сведениям.

Реакция Lovable

После публикации информации о проблеме Lovable выпустила версию 2.0 платформы 24 апреля 2025 года, включив инструмент Security Scan, который должен проверять безопасность проектов перед публикацией.

Однако этот сканер лишь подтверждал факт включения RLS-политики, но не проверял её содержимое и корректность. Политика вида USING (true) считалась «защищённой», хотя фактически оставалась небезопасной.

Сообщество и официальный ответ

Разработчик Danial Asaria публично высказался в Twitter, подчеркнув, что пользователи платформы «не осознавали необходимости ручной настройки RLS» и назвал эту проблему архитектурной ошибкой ^[2] самой платформы.

Сам Мэтт Палмер подтвердил серьёзность проблемы и подчеркнул ответственность самой платформы Lovable за её возникновение и распространение.

Почему это важно

Эта ситуация демонстрирует уязвимость подхода low-code платформ, которые ориентированы на простоту и скорость разработки, зачастую жертвуя встроенными механизмами безопасности. Отсутствие строгих проверок и перекладывание ответственности на разработчиков проектов без достаточного опыта ^[3] создаёт риски масштабных утечек данных.

Рекомендации для защиты данных

Если вы используете платформу Lovable, немедленно примите меры:

1. Проверьте RLS-политики во всех таблицах базы данных Supabase.

2. Обязательно используйте строгие условия в RLS, например:

USING (auth.uid() = user_id)

3. Не смешивайте чувствительные и публичные данные в одной таблице.

4. Не доверяйте только Security Scan от Lovable, проверяйте политику вручную.

Итоги и выводы

Случай с CVE-2025-48757 — важный сигнал всей индустрии low-code решений. Без встроенной, автоматической безопасности такие платформы создают риски для конфиденциальности и целостности пользовательских данных.

Разработчикам платформ и проектам на их основе важно понять, что ответственность за безопасность не должна полностью ложиться на плечи конечных пользователей без чётких инструкций и эффективных инструментов контроля.

Защита данных должна стать частью базовых настроек всех платформ, а не дополнительной опцией.

Источники:

• CVE-2025-48757 ^[4]

• Lovable Changelog ^[5]

• Gist технической спецификации уязвимости ^[6]

• Twitter обсуждение Danial Asaria ^[7]

• Официальное заявление Matt Palmer ^[8]