El 11 de octubre de 2026, a las 13:18, un ingeniero de nuestro equipo de seguridad consiguió entrar en Luxine News sin conocer ninguna contraseña. No hizo falta ningún método sofisticado, ni programas raros, ni fuerza bruta durante horas: bastó con un fallo en la forma en que la plataforma recuperaba las cuentas de sus usuarios. En cuestión de minutos, lo que parecía una web normal se convirtió en un sistema completamente abierto.
Publicamos este análisis como parte de un ejercicio de divulgación responsable, y lo hacemos con dos objetivos muy claros. El primero, explicar de forma honesta y comprensible qué encontramos y por qué es grave. El segundo, y más importante, dejar constancia de que estamos colaborando directamente con Luxine News para resolver estos problemas de seguridad. Esto no es una celebración ni una lista de trofeos: es un aviso serio sobre algo que podía haber hecho mucho daño y que, afortunadamente, se detectó a tiempo.
Queremos dejar claro desde el principio el espíritu de esta publicación: no difundimos contraseñas, claves privadas ni datos personales, ni explicamos paso a paso cómo repetir el acceso. Describimos el problema a un nivel que cualquiera pueda entender, pero sin convertir esta noticia en un manual de intrusión. El objetivo es señalar el fallo, entender su gravedad y ayudar a corregirlo.
Qué es Luxine News y por qué llegamos hasta aquí
Luxine News es una plataforma de noticias construida sobre tecnologías web modernas. Como tantos proyectos actuales, combina una parte visible —la web que ve cualquier lector— con una parte interna: cuentas de usuario, roles, un panel de administración y una base de datos donde se guarda todo. Es exactamente el tipo de arquitectura que usamos también en SifG22, y precisamente por eso prestamos atención a cómo estaba construida.
Durante una revisión rutinaria, uno de nuestros ingenieros se fijó en un detalle del proceso de inicio de sesión que no encajaba. Lo que empezó como curiosidad técnica terminó revelando un problema de seguridad de primer orden. En lugar de quedarnos callados o, peor aún, aprovecharlo, decidimos documentarlo con rigor y comunicarlo a quien corresponde. Esa es la base de la seguridad informática sana: quien encuentra un fallo tiene la responsabilidad de ayudar a cerrarlo, no de explotarlo.
Por qué publicamos esto: divulgación responsable
En el mundo de la seguridad existe un concepto fundamental: la divulgación responsable. Consiste en que, cuando alguien descubre una vulnerabilidad, avisa primero de forma privada a los responsables del sistema, les da tiempo y ayuda para corregirla, y solo después —cuando ya no hay riesgo inmediato— se cuenta públicamente de manera educativa.
Lo contrario sería la divulgación irresponsable: publicar los detalles exactos para que cualquiera pueda copiarlos, o simplemente guardarse el fallo para usarlo con malas intenciones. Nosotros elegimos el camino responsable. Por eso esta noticia explica el qué y el por qué, pero nunca el cómo operativo. Queremos que la gente entienda los riesgos, no que aprenda a atacar.
Encontrar un fallo no te convierte en dueño del problema. Te convierte en responsable de ayudar a cerrarlo.
La cronología del 11 de octubre
Todo ocurrió en una misma jornada. A primera hora de la tarde, nuestro ingeniero estaba revisando el flujo de autenticación de Luxine News. A las 13:18 confirmó que el fallo era real y que permitía tomar el control de cuentas ajenas. A partir de ahí, y siempre con la cautela de un análisis de seguridad, verificó el alcance: comprobó hasta dónde llegaban los permisos, qué información quedaba visible y qué podía modificarse.
En cuanto el alcance quedó claro —y entendimos que no se trataba de un detalle menor, sino de un acceso con privilegios máximos—, detuvimos la exploración. No tenía sentido seguir indagando: ya sabíamos que el problema era serio. El siguiente paso no fue técnico, sino humano: avisar. Pusimos los hallazgos en conocimiento del responsable de Luxine News lo antes posible, de forma privada y con la información necesaria para que pudieran empezar a corregirlo de inmediato.
El punto de entrada: la recuperación de contraseña
Todo empezó en el panel de inicio de sesión. Dentro de la sección de «¿Olvidaste tu contraseña?» existía un fallo de diseño serio: si conocías el correo electrónico asociado a una cuenta, el sistema permitía cambiar su contraseña sin comprobar de forma suficiente que quien lo solicitaba era realmente el propietario de esa cuenta.
Para entender por qué esto es tan grave, conviene recordar cómo debería funcionar una recuperación de contraseña segura. Lo normal es que, cuando pides recuperar el acceso, el sistema te envíe un enlace o un código a tu propio correo, de modo que solo quien tenga acceso real a esa bandeja de entrada pueda completar el cambio. Ese paso es la prueba de identidad: demuestra que eres tú, porque solo tú puedes leer tus mensajes.
En el caso que encontramos, ese candado estaba, en la práctica, abierto. El proceso daba por hecho que quien introducía un correo era su dueño legítimo, sin exigir una verificación de identidad sólida antes de permitir el cambio de credenciales. Es el equivalente a que el portero de un edificio te deje cambiar la cerradura de cualquier piso con solo decir el número de la puerta, sin pedirte que demuestres que vives allí.
Por qué un correo electrónico no es una identidad
Aquí está el corazón del problema. Un correo electrónico no es un secreto. Circula en mensajes, en listas de contactos, en firmas, en perfiles públicos, en formularios y en filtraciones antiguas de otros servicios. Es, básicamente, un dato público o semipúblico: sirve para identificar a alguien, pero no para demostrar que esa persona eres tú.
Construir la seguridad de una cuenta sobre algo que cualquiera puede conocer es como poner una cerradura cuya llave está pegada con celo en la puerta. Si saber el correo basta para cambiar la contraseña, entonces la contraseña ya no protege nada: cualquiera que averigüe esa dirección —y averiguarla suele ser trivial— puede quedarse con la cuenta. A esto, en seguridad, se le llama toma de control de cuentas (en inglés, account takeover), y es una de las categorías de vulnerabilidad más peligrosas que existen, porque no ataca a la tecnología: ataca a la confianza.
Del acceso al panel de control
Usando ese fallo, accedimos a dos cuentas con permisos de administrador en Luxine News. Y una cuenta de administrador no es una cuenta cualquiera: es la que tiene las llaves de todo. A través de ellas llegamos al panel de control de la aplicación, el lugar desde el que se gestiona el servicio entero.
Conviene detenerse aquí, porque la diferencia entre entrar en una cuenta normal y entrar en una de administrador es enorme. Una cuenta normal te da acceso a tus propios datos. Una cuenta de administrador te da acceso a los datos de todos, además de a los ajustes internos, a la configuración y, a menudo, a los cimientos técnicos sobre los que se apoya la plataforma. Al obtener dos de estas cuentas, no entramos en «una» parte del sistema: entramos en el centro de mando.
Lo que debería haber sido un simple olvido de contraseña se convirtió, por la combinación de este fallo con controles de autorización insuficientes, en un acceso con privilegios máximos. Y esa es la lección más importante de todo el episodio: los fallos rara vez son peligrosos de uno en uno. Lo que los vuelve críticos es cómo se encadenan.
Un fallo en la recuperación de cuentas, combinado con controles de autorización débiles, puede transformar un olvido de contraseña en un acceso total al sistema.
Qué es un panel de control y por qué un administrador lo cambia todo
El panel de control de una aplicación es la «sala de máquinas». Desde ahí se ve y se gestiona lo que el público nunca debería ver: las cuentas registradas, sus datos, los permisos de cada usuario, la configuración del servicio y las conexiones con otras herramientas. Es el sitio donde un equipo legítimo administra su producto, y precisamente por eso debe estar blindado.
Cuando alguien no autorizado llega a ese panel con permisos de administrador, deja de ser un «visitante» de la web para convertirse en alguien que puede leer, modificar y, potencialmente, destruir. La gravedad no está solo en lo que vimos, sino en lo que cualquier persona con malas intenciones podría haber hecho desde esa misma posición. Ese es el escenario que esta divulgación busca evitar.
Qué datos quedaron comprometidos
Una vez dentro del panel de control, el alcance de lo que quedaba expuesto era considerable. Durante el acceso, y siempre con la cautela propia de un análisis de seguridad, pudimos observar o manipular lo siguiente:
- Direcciones IP de usuarios y del propio sistema.
- Correos electrónicos vinculados a las cuentas de la plataforma.
- Archivos secretos del equipo de administración.
- Gestión de roles: era posible cambiar los roles y privilegios de los usuarios.
- A través de la consola de comandos, acceso a la API key pública y secreta de Supabase, la base de datos sobre la que se apoya el servicio.
Vamos a explicar qué significa cada uno de estos puntos, porque no todos tienen el mismo peso y conviene entender por qué.
Las direcciones IP
Una dirección IP es el identificador que tiene un dispositivo cuando se conecta a internet. Por sí sola no revela el nombre de una persona, pero sí da pistas sobre su ubicación aproximada y su proveedor, y puede cruzarse con otros datos para seguir la actividad de alguien. Que las IP de los usuarios quedaran visibles supone un riesgo de privacidad: información que, combinada con el resto, ayuda a perfilar a las personas detrás de las cuentas.
Los correos electrónicos
El acceso a la lista de correos vinculados a las cuentas es delicado por partida doble. Por un lado, es información personal de los usuarios. Por otro, recordemos el fallo original: si conocer un correo bastaba para cambiar su contraseña, entonces tener la lista completa de correos equivalía, en la práctica, a tener una llave maestra sobre el resto de cuentas. Un problema alimentaba al otro.
Los archivos secretos del equipo de administración
Dentro del panel había archivos secretos del equipo de administración. En el contexto de una aplicación, «secretos» es un término técnico: se refiere a datos de configuración que nunca deberían ser públicos, porque son los que permiten que las piezas internas confíen unas en otras. Que estos archivos fueran accesibles significa que la frontera entre «lo interno» y «lo externo» se había difuminado, y esa frontera es justo lo que mantiene a salvo un sistema.
El cambio de roles de usuarios
Un «rol» define lo que cada usuario puede hacer: leer, escribir, moderar, administrar. Poder cambiar los roles desde dentro es especialmente grave, porque ataca a la integridad del sistema. No se trata solo de mirar datos que no deberías ver, sino de reescribir las reglas: convertir a un usuario normal en administrador, retirar permisos a quien debería tenerlos o alterar quién manda sobre qué. Un sistema en el que los permisos se pueden reasignar libremente desde una cuenta comprometida es un sistema sin jerarquía real.
Las claves de Supabase: pública y secreta
Llegamos al hallazgo más serio. A través de la consola de comandos fue posible acceder a las claves de API de Supabase, tanto la pública como la secreta. Supabase es la plataforma que proporciona la base de datos y parte de la lógica de autenticación del servicio; dicho de forma sencilla, es donde vive y se organiza la información.
Para entender la gravedad hay que distinguir dos tipos de clave. La clave pública está pensada para usarse en el navegador, a la vista de todos, y por sí sola no debería dar acceso ilimitado: su seguridad depende de que existan reglas que limiten lo que puede hacer. La clave secreta, en cambio, es harina de otro costal: está diseñada para permanecer oculta en los servidores y permite saltarse esas reglas de protección y operar sobre la base de datos con permisos elevados.
Que una clave secreta quede expuesta es, con diferencia, lo más crítico de todo este caso. Equivale a entregar la llave maestra del almacén entero, no la de una taquilla. Por eso la tratamos con la máxima prioridad, la señalamos como urgente a Luxine News y, por supuesto, no la hemos reproducido ni publicado en ningún momento. En seguridad, una clave secreta comprometida no se discute: se revoca y se rota cuanto antes.
Un apunte sobre las reglas de seguridad (RLS)
Plataformas como Supabase ofrecen un mecanismo llamado seguridad a nivel de fila (en inglés, Row Level Security o RLS). En palabras llanas, son reglas que deciden qué puede ver y tocar cada usuario dentro de la base de datos: por ejemplo, que cada persona solo acceda a sus propios registros y no a los de los demás. Cuando esas reglas están bien puestas, incluso si alguien consigue la clave pública, el daño que puede hacer es limitado.
El problema aparece cuando esas reglas son débiles o inexistentes, o cuando se filtra una clave secreta capaz de ignorarlas. En ese momento, la base de datos deja de distinguir entre un usuario legítimo y un intruso. Reforzar estas reglas es una de las recomendaciones centrales que hemos trasladado a Luxine News.
La lectura del impacto
En seguridad se suele medir el impacto de un incidente con tres grandes preguntas, lo que los profesionales llaman la tríada de confidencialidad, integridad y disponibilidad. Aplicadas a este caso:
- Confidencialidad: quedó en riesgo. Correos, direcciones IP y archivos internos que deberían ser privados resultaban accesibles.
- Integridad: quedó en riesgo. Al poder cambiar roles y operar sobre la base de datos, era posible modificar información y permisos, no solo leerlos.
- Disponibilidad: en manos malintencionadas, un acceso así podría haberse usado para interrumpir o dañar el servicio.
Conviene, eso sí, ser honestos con la lectura de los hallazgos. Haber podido ver una pantalla o acceder a una clave no equivale automáticamente a una extracción masiva de datos. Nosotros no descargamos bases de datos ni copiamos información personal de los usuarios: nuestro objetivo era confirmar el alcance del fallo, no aprovecharlo. Documentamos cada punto con capturas que permanecen bajo nuestra custodia y que compartimos de forma privada con Luxine News, sin publicarlas aquí.
Qué no hicimos: los límites del ejercicio
Tan importante como lo que hicimos es lo que decidimos no hacer. No extrajimos ni almacenamos datos personales de los usuarios. No modificamos ni borramos contenido de la plataforma para «dejar huella». No utilizamos las claves para operar contra la base de datos más allá de confirmar el problema. No compartimos con nadie, ni haremos públicas, las credenciales, las claves ni los datos personales a los que se podía llegar.
Estas líneas rojas no son un detalle menor: son lo que separa una investigación de seguridad responsable de un ataque. La diferencia entre ambas cosas no está en las herramientas ni en los conocimientos, sino en la intención y en los límites que uno se impone. Nuestra intención fue, desde el primer minuto, cerrar la puerta, no cruzarla.
Cómo avisamos y cómo colaboramos ahora
En cuanto fuimos conscientes del alcance de estos fallos, informamos al responsable de Luxine News lo antes posible y pusimos los hallazgos en su conocimiento de forma privada, con la información necesaria para actuar de inmediato. Desde entonces estamos colaborando con su equipo para resolver estos graves problemas de seguridad.
Esta colaboración es, para nosotros, la verdadera noticia. Un fallo encontrado y comunicado a tiempo es una oportunidad; un fallo descubierto por quien no debía es un desastre. Que Luxine News haya estado dispuesto a trabajar codo con codo con nosotros dice mucho de su voluntad de hacer las cosas bien, y queremos reconocerlo públicamente.
Las medidas prioritarias que hemos recomendado
Trasladamos a Luxine News una serie de medidas, ordenadas por urgencia, para cerrar el problema de raíz y no solo tapar el síntoma:
- Recuperación segura: verificar de forma inequívoca la propiedad de una cuenta —mediante un enlace o código enviado al propio correo— antes de permitir cualquier cambio de contraseña.
- Control de acceso en el servidor: no confiar nunca en que el navegador «se porte bien». Toda autorización sensible debe comprobarse en el servidor, donde el usuario no puede manipularla.
- Reglas de seguridad en la base de datos: aplicar y endurecer las reglas de seguridad a nivel de fila en Supabase, de modo que cada usuario solo alcance lo que le corresponde.
- Gestión de claves: inventariar todas las claves de API, revocar y rotar de inmediato cualquier secreto que haya podido quedar expuesto, y no exponer jamás claves secretas en la parte pública de la aplicación.
- Revisión de sesiones: revisar los registros de acceso y cerrar las sesiones que pudieran haber quedado comprometidas.
- Roles bajo llave: impedir que un usuario sin privilegios administrativos pueda crear, editar o concederse roles a sí mismo.
Qué estamos haciendo en SifG22
Un episodio así también es una lección para nosotros. Ver de cerca cómo un detalle aparentemente pequeño puede abrir un sistema entero nos obliga a mirarnos al espejo. En SifG22 estamos tomando medidas para asegurarnos de que algo parecido no pueda ocurrir en nuestros propios servicios.
A lo largo de esta semana reforzaremos la seguridad de SifG Edu, prestando especial atención a los flujos de autenticación y de recuperación de cuentas, que son justamente el tipo de puerta que falló en este caso. Queremos auditar que nuestras propias verificaciones de identidad sean sólidas y que nuestros permisos se comprueben siempre donde deben comprobarse.
Además, actualizaremos los términos de uso de SifG22 antes de que acabe octubre, para reflejar con mayor claridad nuestro compromiso con la seguridad, la privacidad y la divulgación responsable de vulnerabilidades. Creemos que las reglas del juego deben estar escritas y ser transparentes, tanto para nosotros como para quienes confían en nuestras plataformas.
Lecciones para cualquier equipo pequeño
Si algo deja claro este caso es que la seguridad no es un lujo de las grandes empresas. Los proyectos pequeños —los nuestros incluidos— manejan datos reales de personas reales, y eso basta para que valga la pena protegerlos bien. Tres ideas resumen lo aprendido.
La primera: nunca confíes en un dato público como prueba de identidad. Un correo, un nombre de usuario o un número de teléfono sirven para identificar, no para autenticar. La segunda: comprueba los permisos en el servidor, siempre. Lo que ocurre en el navegador se puede manipular; lo que decide el servidor, no. Y la tercera: trata los secretos como lo que son. Una clave secreta expuesta no es un susto pasajero: es una emergencia que se resuelve revocando y rotando sin esperar.
Preguntas frecuentes
¿Habéis publicado datos de los usuarios de Luxine News? No. No hemos publicado ni publicaremos correos, contraseñas, claves ni información personal. Esta noticia es divulgativa y deliberadamente no contiene detalles operativos.
¿Por qué contáis esto si colaboráis con ellos? Precisamente porque colaboramos. La divulgación responsable incluye, en su última fase, explicar públicamente lo aprendido de forma educativa, una vez el riesgo está bajo control. Compartir estos casos ayuda a que otros equipos no tropiecen con la misma piedra.
¿Podría volver a pasar? Cualquier sistema puede tener fallos; lo que marca la diferencia es cómo se detectan, se comunican y se corrigen. Por eso insistimos tanto en los procesos: en avisar a tiempo, en verificar identidades de verdad y en revisar la seguridad de forma continua.
Conclusión
Creemos que la seguridad mejora cuando se comparte con responsabilidad. Señalar un fallo, explicarlo con claridad y ayudar a corregirlo es, para nosotros, la forma más honesta de construir servicios en los que se pueda confiar. Lo ocurrido con Luxine News podría haber terminado muy mal; en cambio, se ha convertido en una oportunidad para reforzar su plataforma, la nuestra y, con un poco de suerte, la de quien lea estas líneas.
Gracias a Luxine News por su disposición a trabajar con nosotros, y gracias a ti por llegar hasta aquí. La seguridad es un esfuerzo colectivo: cuanto mejor la entendamos entre todos, más difícil se lo pondremos a quien quiera hacer daño.