Un fallo en las políticas de seguridad a nivel de fila expone datos sensibles de miles de usuarios en cientos de aplicaciones creadas con Lovable. La compañía aún no ha corregido el fallo estructural tras semanas de avisos.
La plataforma Lovable, que permite crear aplicaciones con asistencia de inteligencia artificial, se enfrenta a una de las mayores crisis de seguridad de su historia tras la publicación de una vulnerabilidad crítica en la configuración de las políticas de Row Level Security (RLS). El fallo, descubierto el 20 de marzo de 2025, permite a cualquier atacante acceder y manipular información sensible de usuarios, saltándose controles de acceso y ejecutando operaciones maliciosas en la base de datos.
¿En qué consiste la vulnerabilidad?
El origen del problema reside en la gestión inadecuada de las políticas RLS en proyectos desarrollados con Lovable, especialmente aquellos que emplean Supabase como backend. La arquitectura client-driven (dependiente del cliente) de Lovable delega gran parte de la seguridad en el desarrollador de la aplicación, lo que ha derivado en numerosas implementaciones inseguras. Los atacantes pueden modificar peticiones de red desde el frontend y, al eliminar los encabezados de autorización, acceden a datos y funciones restringidas como si fueran usuarios no autenticados.
Esto permite no solo robar información personal y claves API, sino también manipular registros, como marcar pagos como “realizados” y eludir integraciones de pago como Stripe.
Impacto: exposición masiva de datos y riesgo de abuso
Una auditoría realizada por investigadores de seguridad analizó 1.645 proyectos en el escaparate oficial de Lovable, detectando que el 10,3% de las aplicaciones (170 proyectos y 303 endpoints) presentaban una configuración de seguridad insuficiente. Entre los datos expuestos se encuentran:
- Claves API de Google Maps, Gemini y eBay.
- Bases de datos completas de usuarios, transacciones y suscripciones.
- Tokens de autenticación y datos de pago.
- Información confidencial como direcciones, deudas y otros datos personales.
Los endpoints más críticos permiten obtener credenciales de servicios externos, lo que multiplica el riesgo de escaladas de privilegios y abuso en otros sistemas conectados.
La respuesta de Lovable: parches superficiales y falta de transparencia
A pesar de que Lovable recibió la notificación inicial en marzo y una segunda comunicación formal en abril, la empresa no ha proporcionado una solución integral ni ha notificado de forma adecuada a sus usuarios. Tras la presión pública y una divulgación independiente por parte de un ingeniero de Palantir, la compañía lanzó Lovable 2.0 con un “escáner de seguridad” que solo verifica la existencia de políticas RLS, pero no su correcta implementación.
Este parche resulta insuficiente y genera una falsa sensación de seguridad, ya que no detecta la raíz del problema: la falta de alineación entre los controles de frontend y backend.
Ejemplo práctico de explotación
Un ejemplo ilustrativo es el sitio Linkable, creado con Lovable para generar perfiles de LinkedIn. Los investigadores demostraron cómo se podía modificar una petición y acceder a toda la tabla de usuarios sin restricciones. Incluso lograron insertar registros y modificar el estado de pagos, sorteando la lógica de negocio crítica para la aplicación.
Recomendaciones y consecuencias
El incidente resalta la importancia de los principios “secure-by-default” en plataformas de desarrollo asistido por IA, especialmente cuando se manejan datos personales y de alto valor. Los expertos recomiendan:
- Auditar y corregir la configuración de RLS en todos los proyectos desarrollados con Lovable y Supabase.
- No confiar únicamente en herramientas automáticas de chequeo, sino revisar la lógica de acceso y autorización de datos.
- Mantener una estricta separación entre lógica de frontend y backend.
- Solicitar a Lovable información y actualizaciones de seguridad.
Con la publicación de un CVE oficial y la falta de respuesta efectiva, la confianza en la plataforma Lovable queda en entredicho. Usuarios y desarrolladores deben extremar la precaución y replantear el uso de soluciones que no garanticen la protección robusta de la información por defecto.
Referencias: GBHackers On Security y Matt Palmer, Statement on CVE-2025-48757
