Diario de seguridad.

Cerrada la vulnerabilidad del kernel de Linux CVE-2026-98432

Se detectó la vulnerabilidad CVE-2026-98432 en la forma en que el kernel de Linux gestiona las conexiones TCP entrantes. Afecta a los servidores Linux con independencia del servicio que ejecuten.

Los kernels de los servidores de la plataforma y de los servidores VPN activos de los socios con versiones del sistema compatibles se han actualizado a una versión con la corrección.

Límites alineados en el formulario público de soporte

Un informe de Parth Narula mostró que, con otra dirección de correo electrónico, nuestro formulario público de soporte permitía enviar solicitudes adicionales. Alineamos los límites del formulario, de modo que cambiar de dirección ya no permite enviar más solicitudes. Gracias por el informe responsable.

Se restringió el acceso a la interfaz del servicio de soporte

Un investigador externo advirtió que la interfaz del servicio de soporte era accesible desde internet. La interfaz requería autenticación; no se detectaron indicios de acceso no autorizado ni de exposición de datos de usuarios.

Excluimos el servicio de soporte de la superficie pública: el acceso solo se permite desde direcciones de confianza y a través de un canal interno. La configuración de la interfaz se ajustó al dominio que realmente se usa, y la restricción se verificó desde una red externa.

Dirección de retorno limitada a las páginas del panel

Un investigador de seguridad descubrió que la dirección de retorno técnica utilizada tras restaurar una sesión podía ser interpretada por el navegador como una navegación a un sitio externo. El escenario requería una sesión válida y no daba acceso a la cuenta ni a los datos.

Ahora la dirección de retorno se elige de una lista cerrada de páginas internas. Cualquier otro valor lleva a la página principal del panel. La corrección está cubierta por pruebas negativas automatizadas.

Aplicación de DMARC activada

Un investigador de seguridad descubrió que la política DMARC de createyourvpn.com funcionaba únicamente en modo de supervisión y no exigía rechazar los mensajes que no superaban la validación. Activamos p=reject para el dominio principal y sp=reject para sus subdominios que no envían correo. El correo transaccional continúa aislado en subdominios de envío separados con sus propias políticas SPF, DKIM y DMARC.

MTA-STS e informes TLS activados

Un investigador de seguridad descubrió que MTA-STS y los informes TLS no estaban configurados para el correo entrante de createyourvpn.com. Publicamos una política MTA-STS y activamos los informes TLS. Al principio, la política funciona en modo de prueba mientras verificamos la ruta de reenvío de un tercero; activaremos la aplicación después de recibir informes sin errores.

Añadido el control de las sesiones de la cuenta

Un investigador de seguridad descubrió que una copia del token de una sesión de partner podía seguir activa después de cerrar sesión si se había renovado por separado. Migramos las sesiones a una única identidad del lado del servidor: ahora el cierre de sesión revoca toda la sesión actual, mientras que «Cerrar sesión en todas partes» finaliza todas las sesiones activas.

En el panel apareció la sección «Sesiones de la cuenta». En ella se ven los accesos actuales con el dispositivo, la dirección IP, la hora de acceso y la última actividad, así como el historial de intentos de acceso correctos y fallidos de los últimos 90 días. Las sesiones se pueden cerrar de una en una o todas a la vez.

Enabled DNSSEC

A researcher found that DNSSEC was not enabled for createyourvpn.com. We signed the DNS zone, published the DS record in .com, and verified the chain of trust.

Mayor protección para el formulario público de soporte

El investigador de seguridad 0xVicky descubrió que nuestro formulario público de soporte podía utilizarse para enviar un número excesivo de solicitudes. Añadimos límites por visitante y para el tráfico total, protegimos el canal interno de envío del formulario y reforzamos la validación de adjuntos. Gracias por el informe responsable.

Gestión de sesiones y envío de códigos de acceso

A raíz de los informes de un investigador externo, revisamos dos áreas contiguas: el ciclo de vida de una sesión de socio y el recorrido del correo con el código de acceso. Ninguno de los hallazgos daba acceso a cuentas, datos de socios ni tráfico de usuarios.

Encabezados de seguridad en las páginas de las tiendas

Las tiendas de los partners no enviaban los encabezados de seguridad que el panel y la API ya enviaban, entre ellos el que impide a otros sitios mostrar la página en un iframe. Por esta vía no se podían leer datos de cuenta ni sesiones. Ahora el conjunto completo acompaña a cada respuesta de las tiendas, y la afirmación SR-15 nombra cada frontend que alojamos.

Cada usuario puede restablecer su enlace de suscripción

Un enlace de suscripción es un secreto: quien lo tiene obtiene el mismo acceso que su propietario. El usuario puede restablecerlo por su cuenta desde su perfil: el enlace anterior deja de funcionar y las credenciales asociadas se emiten de nuevo. Un enlace cerrado así permanece cerrado, incluso si se restauran datos desde una copia de seguridad.

Las direcciones de correo de los usuarios de las tiendas ya no se guardan

Una persona escribe su correo para entrar en la tienda de un partner, pero la dirección no se queda con nosotros: el correo con el código sale y la dirección se elimina de inmediato. La cuenta se reconoce por una huella irreversible de la que no se puede recuperar la dirección, y el nombre de la cuenta tampoco la contiene.

Se restringió el acceso al panel de gestión de la infraestructura

Un investigador externo informó de que una interfaz administrativa de gestión de la infraestructura respondía desde internet. La interfaz estaba protegida por autenticación y no se encontraron indicios de acceso no autorizado. El informe se aceptó y el acceso se restringió.

Ahora la interfaz solo es accesible desde direcciones autorizadas, se reforzaron los requisitos de autenticación y se actualizaron los componentes implicados. El resultado se verificó desde fuera de nuestra red. Además, revisamos nuestra superficie pública y añadimos una comprobación periódica. La recompensa se pagó en el nivel más alto.

Eliminada una vía de autorización de la API de socios que no se usaba

La API admitía una vía de autorización adicional basada en cookie que la arquitectura server-side actual no necesitaba. No se encontró ningún ataque entre sitios en production, pero la vía adicional ampliaba la superficie para errores futuros. La API ahora usa un único método de autorización definido explícitamente, cubierto por pruebas negativas.

Garantizado el borrado de la clave de gestión tras eliminar un servidor

El borrado de la clave de gestión cifrada se ejecutaba después de operaciones de red en segundo plano y podía no repetirse si esas operaciones fallaban. Desacoplamos el borrado de la clave de la cascada de red y añadimos un reintento garantizado. Los escenarios de servidor inaccesible y de proceso interrumpido están cubiertos por pruebas.

Claves criptográficas de la plataforma separadas por finalidad

Una revisión interna detectó que un mismo secreto se usaba para dos tareas criptográficas distintas. Esto no creaba ninguna elusión directa, pero ampliaba el alcance de una compromisión de la clave. Las dos finalidades se han separado y cada una se rota ahora de forma independiente.

Reducida la superficie pública de la API de production

La documentación técnica interactiva de la API era accesible sin autenticación. No daba acceso a datos protegidos, pero facilitaba el estudio de la estructura interna de la API. En production la documentación ahora está desactivada, y sigue disponible en un entorno aislado para el desarrollo.

Añadida una salvaguarda contra una configuración cross-origin insegura

La configuración de production actual no permitía orígenes arbitrarios, pero el código permitía una combinación peligrosa de parámetros si un operador la configuraba mal. Esa combinación ahora se rechaza en el arranque y está cubierta por una prueba automatizada.

Revisión interna antes del lanzamiento del programa

El 15 de julio de 2026 iniciamos una revisión de seguridad interna de CreateYourVPN. Las correcciones que hemos completado y vuelto a verificar se publican a continuación; seguirán más a medida que se desplieguen y confirmen.