El equipo SifG22 me demostró un fallo en el acceso a cuentas de Luxine

// informe de divulgación responsable · 11-10-2026
[1]  fallo en recuperación de contraseña (F12) → cuenta tomada
[2]  service key de Supabase vía consola (F12)
[3]  clave secreta ... luxine
// fin del método
------------------------------------------------
[fix] login / cuentas / comentarios ... DESACTIVADOS
[fix] nuevas API keys secret ......... REGENERANDO
[fix] refuerzo RLS en SQL ............ EN CURSO
▍

La seguridad digital es uno de esos aspectos del desarrollo que pueden pasar desapercibidos hasta que alguien demuestra que existe un problema. Esta semana me tocó vivirlo de cerca, y quiero contarlo con total transparencia.

Lo primero y más importante, un mensaje para quienes tenéis una cuenta en Luxine: quienes lo hicieron fueron un equipo amigo, el equipo SifG22, con una intención puramente preventiva, y no se difundió ni se utilizó ningún dato personal. Hubo un fallo serio —una clave sensible estaba expuesta— y por eso no quiero quitarle importancia; pero se detectó a tiempo, de forma preventiva, y he actuado de inmediato. Como medida de precaución, mientras lo soluciono he desactivado por completo el inicio de sesión, las cuentas y los comentarios, y he rotado la clave comprometida. Todo volverá en cuanto termine de reforzar la seguridad.

Qué ocurrió

El equipo SifG22, con el que tengo amistad, intervino en Luxine para demostrarme que existía un riesgo que debía corregir antes de que pudiera dar lugar a un problema mayor. No fue un ataque con mala intención: fue un aviso.

Conviene separar bien dos cosas, porque son fallos distintos y al principio yo mismo los mezclé al contarlo.

1. El acceso a la cuenta: un fallo en mi recuperación de contraseña

Aquí está lo importante, y quiero ser honesto: no me hackearon tocando código ni abriendo la consola del navegador. Entraron aprovechando un fallo mío en el flujo de recuperación de contraseña. El propio sistema permitía hacerse con una cuenta sin una comprobación de identidad suficientemente sólida.

Dicho claro: fue un fallo de diseño de mi web, no un truco rebuscado. Bastó con usar una función que yo había dejado demasiado abierta —la de recuperar/cambiar la contraseña— para tomar el control de una cuenta.

2. La clave de Supabase: eso sí salió de la consola (F12)

Lo de la consola del navegador (F12) fue para otra cosa distinta: con ella localizaron una clave de API de Supabase expuesta en el frontend. Y no una cualquiera: según me han confirmado, llegaron a la clave secreta (service role).

Esto es lo más grave del incidente. Una service role key nunca debería viajar al navegador: ignora las políticas de seguridad (RLS) de la base de datos, así que quien la tenga puede leer y escribir prácticamente sin restricciones. Que estuviera accesible desde el frontend es un error serio por mi parte.

Por qué fue posible

Son dos lecciones, una por cada fallo:

• La recuperación de contraseña no verificaba la identidad con la suficiente solidez. Las operaciones sensibles —cambiar una contraseña, asociar un correo— tienen que comprobar inequívocamente que quien las pide es el dueño de la cuenta, y hacerlo en el servidor.
• La clave secreta de Supabase estaba expuesta. Las claves de servicio van solo en el backend, nunca en el código que llega al navegador. En el frontend, como mucho, la clave pública (anon), y siempre respaldada por políticas RLS bien definidas.

Qué he desactivado mientras lo soluciono

No he querido maquillar lo sucedido ni dejarlo correr. He preferido cortar de raíz la superficie afectada y avisar públicamente. En este momento:

• Inicio de sesión y cuentas: desactivados. Las páginas de login y de cuenta están fuera de servicio temporalmente.
• Comentarios y moderación: desactivados, porque la escritura de comentarios dependía del sistema de cuentas.
• Conexión con Supabase: desconectada tanto desde el frontend como desde el backend, para que no se pueda leer ni escribir nada mientras dura la revisión.
• Rutas de administración: retiradas del servicio público.

¿Se filtró información?

Esta pregunta hay que tratarla con cuidado y con honestidad. Se demostraron dos cosas: que se podía tomar una cuenta por el fallo de recuperación, y que había una clave secreta de Supabase al alcance. Esto segundo es serio, porque con esa clave sí sería técnicamente posible acceder a datos de la base.

Ahora bien, tener la clave no prueba por sí solo que se extrajeran datos ni que se publicara nada. El equipo SifG22 tiene amistad conmigo, actuó de forma preventiva y conservó sus capturas como evidencia sin difundir nada. Precisamente por la gravedad de la clave, mi prioridad ha sido rotarla y cortar el acceso de inmediato.

No quiero presentar como confirmada una filtración que no se ha acreditado, pero tampoco minimizarla. Por eso el siguiente paso es revisar los registros y establecer qué pudo ocurrir, antes de afirmar nada en un sentido o en otro.

Qué estoy reforzando

La experiencia deja una lista clara de trabajo, que ya está en marcha:

• Nuevas claves secretas: estamos regenerando nuevas API keys secret de Supabase y revocando las anteriores. La clave comprometida deja de servir por completo.
• Refuerzo con SQL (RLS): vamos a blindar la base de datos con políticas de seguridad a nivel de fila (RLS) escritas en SQL, de modo que, aunque alguien tuviera una clave, no pueda leer ni escribir lo que no le corresponde.
• Claves fuera del frontend: mover cualquier clave secreta al backend y dejar en el navegador, como mucho, la clave pública, respaldada por esas políticas RLS.
• Recuperación segura: rehacer el flujo de recuperación/cambio de contraseña para que verifique inequívocamente la titularidad antes de permitir nada.
• Sesiones: revisar los registros de autenticación y cerrar cualquier sesión que pudiera estar comprometida.

Lo que me llevo de esto

A veces, que alguien de confianza te señale un fallo es la mejor forma de descubrir que tus sistemas necesitan más atención de la que pensabas. Prefiero haberlo sabido así, de forma preventiva, que haberlo descubierto por un incidente real.

La seguridad de una aplicación no se demuestra afirmando que está protegida, sino verificando que sus controles funcionan cuando de verdad importa —y del lado correcto, el del servidor. Gracias por la comprensión mientras lo dejamos todo en orden.