Lovable: el parche de una redirección abierta tras el login se salta con «/..//» en el parámetro redirect

Resumen

Lovable ya había corregido una redirección abierta en la ruta posterior al inicio de sesión de lovable.dev (reporte #3581815). Ese parche funcionaba como una lista de valores prohibidos: rechazaba los payloads con /\ o con su forma codificada /%5C, pero nada más.

El investigador encontró otra forma de llegar al mismo sitio. La dirección que lo demuestra es:

https://lovable.dev/auth/post-login?redirect=/..//google.com

El valor /..//google.com no contiene barras invertidas, así que el filtro no lo detecta. Después, al normalizar la ruta, el servidor resuelve el /../ y lo que queda, //google.com, se interpreta como una URL relativa al protocolo, es decir, como https://google.com. El resultado es que el usuario sale de lovable.dev hacia un dominio que elige el atacante.

El fallo de fondo es que el parche anterior bloqueaba casos concretos en lugar de validar el destino con una lista de valores permitidos o con un parser de URLs.

El reporte se envió el 12 de marzo de 2026 y se divulgó ese mismo día, ya resuelto. HackerOne lo clasifica como Open Redirect de severidad media.

Pasos de reproducción

1. Crear una cuenta en lovable.dev o entrar con una que ya exista.
2. Con la sesión iniciada, abrir esta dirección:

`` https://lovable.dev/auth/post-login?redirect=/..//google.com ``

1. Comprobar que el navegador termina en https://google.com, un dominio externo.

Variantes que ya bloqueaba el parche del reporte #3581815, frente al payload nuevo:

- /\
- /%5C
+ /..//google.com

Impacto

Un atacante puede repartir un enlace que empieza por https://lovable.dev, un dominio en el que la víctima confía, y que la acaba llevando a una web suya. Como la redirección ocurre justo después del inicio de sesión, la víctima ya está autenticada en Lovable y no tiene motivos para sospechar de la página siguiente. Eso hace mucho más creíble una campaña de phishing dirigida: el destino puede ser una copia de Lovable que pida otra vez las credenciales o intente robar tokens de sesión.

Qué aprender de este caso

• Cuando un programa ya ha corregido una redirección abierta, prueba el mismo parámetro con variantes que el parche quizá no contemple: aquí bastó con combinar /../ con una doble barra para que, tras normalizar, apareciese //dominio.
• Revisa el orden de las operaciones en el servidor: si el filtro mira el valor antes de normalizar la ruta, lo que se valida no es lo que luego se usa como destino.
• Para un parámetro como redirect tras el login, lo seguro es resolver el valor con un parser de URLs y aceptar solo destinos cuyo origen sea el propio sitio (o una lista cerrada de rutas internas), en vez de ir añadiendo prefijos prohibidos como /\ o /%5C.