Vulnerabilidad BOLA en Lovable expone chats y código: la startup niega “brecha” y apunta a HackerOne

La Vulnerabilidad BOLA en Lovable se ha convertido en el foco de una nueva controversia de seguridad en el ecosistema de “vibe coding”: un investigador afirma que, creando una cuenta gratuita, pudo acceder a información sensible de otros usuarios —incluyendo historial de chats, código fuente y credenciales embebidas— mediante llamadas a la API. Lovable, la startup detrás del servicio, sostiene que “no sufrió una brecha de datos”, pero ha ido matizando su relato y, en una segunda comunicación pública, atribuye parte del fallo de respuesta a su programa de divulgación de vulnerabilidades operado con HackerOne.

Vulnerabilidad BOLA en Lovable: qué se denuncia y por qué importa

Según la denuncia pública del investigador (@weezerOSINT), el problema afectaría a proyectos creados antes de noviembre de 2025 y permitiría leer datos de terceros desde una cuenta “free tier”. La gravedad potencial no está solo en el acceso al código: el investigador asegura que de ese material fue posible extraer credenciales de bases de datos y observar información personal en chats, un escenario que puede encadenar riesgos de data exposure, credential compromise y movimientos laterales si esas credenciales se reutilizan en otros entornos.

En términos técnicos, el caso se enmarca en un patrón conocido: Broken Object Level Authorization (BOLA), considerado una de las principales clases de fallos en seguridad de APIs por su impacto y frecuencia en servicios modernos. BOLA ocurre cuando el backend no valida correctamente la “propiedad” del recurso solicitado (por ejemplo, un proyecto o chat) y permite que un usuario acceda a objetos de otros usuarios simplemente manipulando identificadores o rutas.

Referencia técnica de alto nivel: OWASP documenta esta categoría en su guía de seguridad de APIs, donde BOLA aparece como riesgo crítico por su capacidad de exponer datos a escala cuando un endpoint carece de controles de autorización a nivel de objeto. Fuente: OWASP API Security Top 10 (BOLA).

El vector: API calls desde una cuenta gratuita

El investigador sostiene que no fue necesario “hacking ofensivo” complejo: afirma que con un conjunto reducido de peticiones a la API desde una cuenta gratuita obtuvo acceso al perfil de otro usuario, a proyectos y a código fuente, y que posteriormente extrajo credenciales desde ese código. Si se confirma, el caso refuerza una tendencia en plataformas de desarrollo asistido por AI: la seguridad real depende tanto del model layer como de la arquitectura de permisos, el diseño de endpoints y la coherencia de reglas de visibilidad en el backend.

Lovable niega una brecha y cambia el encuadre del incidente

En una primera respuesta pública, Lovable indicó que había sido informada de “preocupaciones” sobre la visibilidad de chats y código en proyectos con ajustes de visibilidad pública, pero subrayó: “To be clear: We did not suffer a data breach”. A continuación, la compañía apuntó a problemas de documentación sobre el significado de “public”, reconociendo que su explicación previa de lo que implicaba ese estado era confusa.

Sin embargo, el mensaje más discutido fue la afirmación de que la visibilidad del código en proyectos públicos era un “comportamiento intencional” (“intentional behavior”), sugiriendo que el acceso al historial de construcción o al código estaba “por diseño” en proyectos con visibilidad pública. Este encuadre chocó con la acusación central: que una cuenta gratuita podía ver información sensible de otros usuarios (incluidos chats con datos personales y posibles secretos), lo que para muchos equipos de seguridad entra en la definición práctica de exposición no autorizada, independientemente de cómo se etiquete públicamente.

La rectificación: “no abordamos bien nuestro error”

Más tarde, Lovable publicó una segunda declaración en la que pidió disculpas por no haber abordado adecuadamente el problema y explicó la evolución de sus opciones de visibilidad. Según la empresa, durante una etapa un “public project” implicaba que el proyecto completo (chat y código) era público; con el tiempo detectaron que muchos usuarios interpretaban “public” como “publicar la app”, no necesariamente exponer chats o historial asociado a un proyecto no publicado.

Lovable afirma que: (1) en mayo de 2025 habilitó la creación de proyectos privados para usuarios gratuitos; (2) deshabilitó para clientes enterprise la opción de hacer públicos proyectos nuevos; (3) en diciembre de 2025 cambió el comportamiento para que los proyectos fueran privados por defecto; y (4) “retroactivamente” parcheó la API para que los chats de proyectos públicos no fueran accesibles. No obstante, añade que en febrero, durante una unificación de permisos en el backend, se rehabilitó accidentalmente el acceso a chats en proyectos públicos, lo que habría reabierto la exposición.

Vulnerabilidad BOLA en Lovable y el papel de HackerOne en la escalada

El investigador sostiene que reportó el problema semanas antes y que el caso fue etiquetado como “duplicate submission” en el flujo del programa. Lovable, por su parte, afirma que los reportes fueron cerrados sin escalarse a su equipo interno porque se interpretó que ver chats de proyectos públicos era “intended behavior”, dado el comportamiento histórico del producto. En esa línea, la empresa terminó señalando explícitamente a su “HackerOne partner” como factor en la falta de escalada.

HackerOne declinó comentar en detalle mientras revisaba el caso, indicando que por la naturaleza de programas de clientes necesita verificar información antes de hacer declaraciones. Fuente corporativa: HackerOne (sitio oficial).

Qué queda por aclarar

El punto crítico de la Vulnerabilidad BOLA en Lovable no es semántico (“breach” vs “public”), sino de control de acceso efectivo: si usuarios no autorizados pudieron consultar objetos de terceros a través de endpoints sin validación de pertenencia, el incidente entra en la categoría de fallo de autorización y posible exposición de datos. También queda por determinar el alcance real: cuántos proyectos estaban en estado “public”, qué datos exactos podían consultarse, durante cuánto tiempo estuvo activo el acceso y si existieron lecturas masivas o automatizadas.

Contexto: una startup de AI con adopción empresarial

El caso adquiere relevancia adicional por el posicionamiento de Lovable en el mercado y por su base de clientes citada en comunicaciones recientes de financiación. Cuando herramientas de AI para desarrollo se integran en flujos empresariales, cualquier inconsistencia entre UI/UX de visibilidad, documentación y permisos de backend puede transformarse rápidamente en un riesgo sistémico: código y secretos expuestos son un vector directo hacia entornos de datos y cadenas de suministro de software.

Cierre

A falta de un informe técnico independiente, la Vulnerabilidad BOLA en Lovable deja dos lecturas claras para la industria: la seguridad de plataformas de AI no puede apoyarse en “intended behavior” si el control de acceso a nivel de objeto falla, y la coordinación entre programas de divulgación y equipos internos debe minimizar ambigüedades de producto para evitar cierres prematuros. Lovable asegura que los chats de proyectos públicos “ya no son visibles para nadie” y que actuó en cuanto tuvo constancia del problema; el debate ahora se centra en el alcance y en cómo se gestionó la exposición antes de la corrección.