Reports
MEDIA[LÓGICA DE NEGOCIO]#3370430

Lovable: crear proyectos con visibilidad de pago sin suscripción editando el cuerpo de la petición

La API de Lovable aceptaba el valor de visibilidad enviado al crear un proyecto sin comprobar el plan: cambiarlo a Personal o Workspace bastaba para usar una función reservada a suscripciones superiores.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Lovable reserva a los planes superiores la posibilidad de elegir la visibilidad de un proyecto. Esa restricción, sin embargo, se podía esquivar en la creación: el endpoint que da de alta el proyecto admitía el campo visibility tal como llegaba del cliente, sin que la comprobación de suscripción lo frenase.

El fallo es un control de acceso defectuoso (Improper Access Control) en esta ruta de la API:

https://lovable-api.com/workspaces/{YOUR-WORKSPACE-ID}/projects

Lo reportó el investigador hossam25 al programa de divulgación de vulnerabilidades de Lovable el 4 de octubre de 2025, con severidad media. Se marcó como resuelto y se hizo público el 9 de marzo de 2026.

Pasos de reproducción

Basta una cuenta sin la suscripción necesaria y un proxy de interceptación; el investigador usó Burp.

  1. Activa la interceptación en Burp.
  2. En Lovable, escribe cualquier texto para generar un proyecto.
  3. Pulsa en crear y, en Burp, localiza la petición dirigida a https://lovable-api.com/workspaces/{YOUR-WORKSPACE-ID}/projects.
  4. En el cuerpo de esa petición, pon en visibility el valor Personal o Workspace, ambos de pago. El ejemplo del reporte queda así:
{"description":"landing view","visibility":"Personal","initial_message":{"id":"umsg_01k6qkw83ze07t9f7m9p3jabs9","message":"landing view","files":[],"optimisticImageUrls":[],"chat_only":false,"agent_mode_enabled":false,"ai_message_id":"aimsg_01k6qkw841e07t9f7ytpghd6bs"}}
  1. Envía la petición. El servidor responde 201 Created y el proyecto queda con la visibilidad elegida, sin ninguna restricción.

Impacto

Quien explotase el fallo obtenía gratis una función por la que otros clientes pagan: podía crear proyectos con visibilidad Personal o Workspace sin tener el plan que los incluye. El reporte lo resume en dos consecuencias: acceso a funciones y contenido no pagados, y pérdida directa de ingresos para la empresa.

Qué aprender de este caso

  • Al auditar una aplicación con planes de pago, captura la petición de cada acción limitada y prueba a enviar directamente el valor premium. Si una opción solo aparece bloqueada en la interfaz, el campo correspondiente de la API (aquí, visibility) es el primer sitio donde mirar.
  • No revises solo la pantalla de ajustes: los endpoints de creación, como este de proyectos, suelen aceptar los mismos atributos que los de edición y pueden quedarse sin la comprobación del plan.
  • Para evitarlo, decide en el servidor qué valores de visibility permite el plan del espacio de trabajo antes de crear el recurso, y rechaza los demás en lugar de confiar en lo que ofrece el formulario.