El fallo de un solo campo que dejó expuestas miles de webs hechas con IA (caso Lovable)

En abril de 2026 se destapó que cualquiera con una cuenta gratuita en Lovable —una plataforma de “vibe coding” valorada en 6.600 millones de dólares, usada para crear apps sin escribir código a mano— podía leer el código fuente, las credenciales de base de datos y el historial de chat con la IA de miles de proyectos ajenos. Bastaban cinco llamadas a una API. El fallo llevaba 48 días reportado antes de hacerse público.

Qué pasó exactamente

Un investigador de seguridad identificado como @weezerOSINT reportó la vulnerabilidad al programa de recompensas de Lovable el 3 de marzo de 2026. Era un fallo de tipo BOLA (Broken Object Level Authorization): la aplicación comprobaba que el usuario había iniciado sesión, pero no comprobaba si tenía permiso para ver ESE proyecto en concreto. Cambiando un identificador en la petición, cualquier cuenta gratuita podía acceder a proyectos de otros usuarios: código, credenciales de Supabase escritas directamente en el código, conversaciones con la IA y datos de clientes incluidos.

El fallo afectaba a todos los proyectos creados antes de noviembre de 2025 — miles de aplicaciones. Un caso relacionado, descubierto en febrero de 2026 por otro investigador, había expuesto 18.697 registros de usuarios de una sola app hecha con la plataforma, incluyendo cuentas de estudiantes de universidades como UC Berkeley y UC Davis.

Cuando se hizo público el 20 de abril de 2026, la respuesta inicial de Lovable fue negar que hubiera habido una filtración de datos, atribuirlo a “comportamiento intencionado” y culpar a documentación poco clara. Más tarde pidieron disculpas. El fallo se corrigió para proyectos nuevos, pero no para los que ya existían antes del cambio.

Desarrollador escribiendo código en varias pantallas de noche

Por qué esto le puede pasar a una pyme europea

El error no estaba en la idea de generar código con IA — estaba en un control de permisos que nadie verificó de forma independiente antes de lanzar. Esto es exactamente lo que ocurre cuando una pyme (o la agencia que le monta la web o app) usa herramientas de IA para construir algo rápido — un formulario, un panel de clientes, una pequeña app interna— y lo publica sin que nadie revise si los permisos funcionan como deberían.

La pregunta que hay que hacerse no es “¿la IA escribió código seguro?” sino algo más simple: ¿alguien comprobó, probando con una cuenta sin privilegios, que no se puede acceder a datos que no le corresponden? Esa comprobación —cambiar un ID en la URL o en una petición y ver qué pasa— la puede hacer cualquier persona sin ser experto en seguridad, y habría detectado este fallo en Lovable antes de que afectara a nadie.

Qué hacer si tu web o app usa código generado con IA

  • Prueba los permisos manualmente: con una cuenta de prueba sin privilegios, intenta acceder a datos de “otro usuario” cambiando IDs en la URL.
  • Nunca dejes credenciales o claves en el código que genera la IA — es uno de los fallos más repetidos en apps hechas así (lo vimos también en el caso Moltbook).
  • Pide una revisión externa antes de lanzar algo que maneje datos de clientes, aunque lo haya “escrito” una IA en un fin de semana.
  • Mantén el sitio revisado periódicamente, no solo en el lanzamiento — los permisos pueden romperse en una actualización posterior, como pasó aquí.

Si no sabes por dónde empezar, aquí explicamos qué es el vibe coding y los riesgos básicos que hay que vigilar, y con WP Shield revisamos y mantenemos vigilada tu web de forma continua, no solo el día que se publica.

Preguntas frecuentes

¿Qué es un fallo BOLA en palabras simples?

Es cuando una aplicación comprueba que has iniciado sesión, pero no comprueba si tienes permiso para ver el dato concreto que estás pidiendo. Es uno de los fallos de seguridad más comunes en aplicaciones web, generadas con IA o no.

¿Esto significa que no debería usar herramientas de IA para crear webs o apps?

No — significa que lo que genera la IA necesita la misma revisión de seguridad básica que cualquier otro código antes de manejar datos reales de clientes. El problema no es la herramienta, es publicar sin verificar.

¿Cómo sé si mi web tiene un fallo parecido?

Una revisión básica prueba precisamente esto: acceder con una cuenta sin privilegios e intentar ver datos que no le corresponden. Si nunca se ha hecho esa prueba en tu web, es el primer paso a dar.

Fuentes: The Register, Halborn.