Surfshark confirma una brecha en servidores internos: asegura que los datos de usuarios no fueron afectados
Surfshark confirma acceso no autorizado a servidores internos de pruebas y proxy. La compañía asegura que no se expusieron datos ni tráfico de clientes.
Surfshark ha confirmado un incidente de seguridad en el que un tercero no autorizado consiguió acceder a un servidor interno utilizado por sus equipos de ingeniería. La compañía atribuye la exposición a un error humano de configuración que dejó el sistema de pruebas accesible desde Internet.
El proveedor de VPN sostiene que el incidente quedó limitado a infraestructura interna y que no afectó a los datos de clientes, al tráfico VPN ni a los sistemas de producción. También se produjo acceso a un segundo servidor aislado utilizado como proxy para optimizar la accesibilidad a contenidos, aunque Surfshark afirma que tampoco contenía información identificativa de los usuarios.
Un servidor de pruebas quedó expuesto por una configuración incorrecta
Según el informe de seguridad publicado por Surfshark, el sistema comprometido formaba parte de un entorno interno de ingeniería. Una configuración incorrecta hizo que el servidor pudiera alcanzarse desde Internet y permitió el acceso de una parte no autorizada.
Ese entorno contenía partes de binarios del sistema y configuraciones internas de determinados servicios. La compañía también descubrió que algunas credenciales utilizadas en procesos de compilación habían quedado almacenadas en diferentes momentos dentro del historial de código.
Surfshark asegura que esas credenciales no permitían acceder a los sistemas de producción que prestan el servicio VPN ni a información de los clientes. Aun así, revisó los registros disponibles y decidió revocar, rotar o retirar todos los secretos identificados como medida preventiva.
Los atacantes también accedieron a un servidor proxy aislado
La investigación identificó además acceso a un servidor VPS independiente utilizado para optimización de accesibilidad de contenidos. Este equipo funcionaba como proxy y estaba aislado de la infraestructura que maneja los servicios sensibles de Surfshark.
De acuerdo con la compañía, el servidor no tenía acceso a:
- Identidades de usuarios.
- Direcciones IP de clientes.
- Claves de cifrado.
- Tráfico de navegación.
- Datos personales almacenados en sistemas de producción.
Las credenciales que protegen los sistemas con datos sensibles se mantienen en almacenes separados y, según la investigación interna, no estuvieron expuestas durante el incidente.
Surfshark dice que no se filtraron datos de clientes
Surfshark recalca que el entorno comprometido no almacenaba ni procesaba información de usuarios. También afirma que sus aplicaciones para dispositivos y sus extensiones de navegador no fueron modificadas como consecuencia del acceso no autorizado.
La compañía mantiene una política de no registrar el tráfico VPN ni conservar el historial de navegación de sus clientes. En este incidente, asegura además que los atacantes no alcanzaron la infraestructura de producción desde la que se presta el servicio.
Hasta el momento, Surfshark tampoco ha encontrado indicios de que las credenciales internas expuestas hayan sido utilizadas de forma maliciosa ni de que el compromiso se propagara a otros sistemas.
El primer indicio apareció el 31 de agosto
La cronología publicada por la empresa sitúa el primer evento sospechoso el 31 de agosto de 2026, cuando sus sistemas de monitorización detectaron actividad anómala dentro del entorno de pruebas.
El aviso se trató inicialmente como un evento de menor riesgo porque procedía de una infraestructura aislada que no almacenaba datos personales o información sensible. Surfshark reconoce que este criterio retrasó la clasificación del evento como un incidente de seguridad de mayor prioridad.
El 2 de septiembre, la compañía confirmó que se había producido un acceso no autorizado. Ese mismo día desconectó la exposición externa, tomó una copia del servidor para su investigación y examinó otros equipos situados en la misma subred.
Surfshark también revocó o rotó los secretos que podían haberse visto afectados. La fase principal de remediación se dio por completada el 5 de septiembre, aunque las tareas de refuerzo de infraestructura continúan.
La empresa reforzará también sus entornos de pruebas
Una de las conclusiones del incidente es que los sistemas de desarrollo y experimentación deben recibir controles comparables a los de la infraestructura de producción. Surfshark afirma que elevará los estándares de seguridad aplicados a estos entornos.
Entre las medidas anunciadas se encuentran mejoras en los controles de acceso y en la gestión de credenciales durante los procesos de compilación, una monitorización más estricta para detectar servidores de pruebas expuestos accidentalmente a Internet y un mayor endurecimiento de los sistemas operativos y servicios utilizados internamente.
La compañía también ha anunciado una auditoría de seguridad independiente adicional para revisar el estado de su infraestructura más amplia.
Los usuarios de Surfshark no necesitan cambiar sus credenciales por este incidente
Con la información disponible actualmente, Surfshark afirma que los clientes no necesitan realizar ninguna acción específica. No hay evidencia publicada de acceso a cuentas, contraseñas de usuarios, tráfico VPN, claves de cifrado o información personal.
El incidente sí expuso material técnico interno y determinadas credenciales relacionadas con procesos de desarrollo, lo que obligó a la empresa a realizar una revisión y rotación preventiva. Sin embargo, la investigación de Surfshark sitúa esos elementos fuera de la infraestructura que almacena o procesa información sensible de los clientes.
La compañía ha indicado que actualizará su informe si la investigación posterior descubre información relevante que cambie el alcance conocido del incidente.
