Un atacante obtuvo información interna; la empresa empezó de inmediato a cambiar claves y credenciales.

Un error en la configuración abrió a terceros el acceso a la infraestructura interna de Surfshark. El proveedor de VPN confirmó la intrusión en un servidor de prueba que los ingenieros dejaron accidentalmente accesible desde internet. El atacante accedió a configuraciones internas, partes de binarios del sistema y algunos datos relacionados con la compilación de productos.
Los primeros indicios de actividad sospechosa los detectó Surfshark el 31 de agosto. Como la señal provino de un entorno de pruebas aislado sin información de usuarios ni otra información sensible, el incidente inicialmente recibió prioridad baja. El acceso no autorizado se confirmó el 2 de septiembre, tras lo cual se desconectó el servidor de la red externa y se comenzaron a inspeccionar los sistemas adyacentes.
La empresa determinó que en el entorno comprometido se almacenaban configuraciones internas de servicios individuales y partes de binarios del sistema. Además, algunas credenciales que se usaron en el proceso de compilación del software aparecieron en el historial del código en distintos periodos. Surfshark revisó los registros disponibles y no encontró indicios de uso malicioso, pero revocó o reemplazó todos los secretos hallados.
El atacante también obtuvo acceso a un VPS que Surfshark usaba como proxy para optimizar el acceso a contenido. El servidor no tenía acceso a la identidad de los usuarios, direcciones IP, claves de cifrado ni al historial de navegación. Las credenciales para sistemas con información sensible se almacenan por separado en almacenes seguros.
Según la investigación, la infraestructura de producción de la VPN no resultó afectada. Surfshark afirma que el atacante no obtuvo datos de usuarios, tráfico ni información sobre sitios visitados. Tampoco se modificaron las aplicaciones ni las extensiones de navegador del proveedor, por lo que los clientes no necesitan cambiar la configuración ni realizar otras acciones.
Para el 5 de septiembre Surfshark finalizó las principales tareas de recuperación, verificó los servidores en la misma subred en busca de puertas traseras y continuó reemplazando los secretos potencialmente afectados. La empresa también decidió reforzar el control de acceso, la gestión de credenciales y la monitorización de la infraestructura de pruebas.
La conclusión principal de Surfshark fue la necesidad de proteger los entornos experimentales al mismo nivel que los sistemas de producción. En el informe del incidente publicado, la empresa prometió unificar las medidas de protección y la configuración del sistema operativo para los servidores de pruebas y de producción, además de realizar una auditoría independiente adicional de toda la infraestructura.
El problema de secretos dejados accidentalmente hace tiempo que dejó de ser exclusivo de empresas individuales. En 2026, un análisis de GitGuardian mostró que los desarrolladores filtraron a repositorios públicos de GitHub 28,65 millones de secretos en un año, y que en repositorios internos datos similares se encontraron aproximadamente seis veces con más frecuencia.
La infraestructura de compilación también se está convirtiendo en un objetivo separado de ataques. En junio, los atacantes convirtieron paquetes npm oficiales de Red Hat en una herramienta para el robo de secretos de GitHub Actions, npm, AWS, Azure, GCP, Kubernetes y otros servicios, demostrando lo peligroso que puede ser el acceso a las credenciales de los desarrolladores y a los entornos CI/CD.