Vite dev servers expuestos: cómo evitar el robo de secretos cloud

Un dev server no es una máquina de desarrollo, es una puertaDurante años hemos asumido que el servidor de desarrollo vive en un limbo seguro: solo lo...

Un dev server no es una máquina de desarrollo, es una puerta

Durante años hemos asumido que el servidor de desarrollo vive en un limbo seguro: solo lo ve el equipo, solo lo toca el equipo. Esa suposición se rompe en cuanto alguien lanza el proceso con --host, ajusta server.host en la configuración o mapea el puerto 5173 desde un contenedor Docker hacia el exterior. A partir de ese momento, la máquina deja de ser un entorno de pruebas y pasa a ser un servicio más expuesto a Internet, con la particularidad de que suele tener acceso a ficheros que jamás deberían salir de la red interna.

La campaña detectada recientemente contra servidores Vite no es un ataque dirigido ni sofisticado: es un barrido industrial. Miles de peticiones repetitivas buscando el endpoint /@fs/ con combinaciones de parámetros como ?raw e ?import, aprovechando un fallo que permite leer ficheros sin autenticación al sortear los controles de server.fs.deny. Cuando la cosa funciona, la respuesta llega con un HTTP 200 y el contenido del archivo tal cual. Sin drama, sin exploit complejo, sin ruido.

Qué buscan realmente: no es tu código

El atacante no está interesado en tu componente de React ni en tu CSS. Lo que busca es todo aquello que el host pueda leer y que abra una puerta mayor:

Ficheros .env con claves de API, cadenas de conexión y tokens de servicio.
Credenciales de AWS y tokens de Microsoft Azure.
Ficheros de infraestructura como código, por ejemplo terraform.tfstate, que suelen contener endpoints internos, identificadores de recursos y secretos en texto claro.

La lógica es sencilla: el coste real de un incidente así no está en el acceso al servidor de desarrollo, sino en el salto posterior al entorno cloud. Con esas claves, un atacante no necesita vulnerar tu producción, entra por la puerta que tú mismo dejaste abierta y con permisos legítimos.

El patrón técnico que conviene conocer

Las versiones afectadas incluyen ramas de Vite 7.x anteriores a la revisión parcheada y ramas 8.x anteriores a su corrección correspondiente. La campaña combina enumeración de rutas conocidas con técnicas de path traversal y doble codificación, pensadas para colarse por diferencias de normalización entre proxies inversos y WAF. Parte del tráfico se apoya en infraestructura cloud pública, lo que dificulta el bloqueo por reputación de IP sin afectar a servicios legítimos.

Un detalle importante: no te fíes del User-Agent. Las listas blancas de bots y los filtros por cabecera se falsifican en segundos. La mitigación tiene que estar en el control de acceso real, no en la cosmética del tráfico.

Medidas inmediatas si tienes Vite en producción o en staging

El orden importa. Primero cierra la puerta, después limpia:

Actualiza a las versiones corregidas de Vite y mantén las ramas antiguas en revisiones parcheadas si no puedes migrar.
Ata el dev server a localhost. Si necesitas acceso remoto, hazlo por túnel autenticado, nunca publicando el puerto.
Revisa Kubernetes, Ingress y security groups. Un mapeo olvidado en un despliegue antiguo puede seguir vivo meses después.
Bloquea el puerto 5173 en el perímetro y deniega peticiones a /@fs/ desde fuera de la red interna.
Rota todos los secretos que el host pudiera haber leído: valores de .env, credenciales de AWS, tokens de Azure y cualquier fichero de estado de Terraform.

La rotación no es opcional. Si el servidor estuvo expuesto, asume que los secretos ya no son secretos y actúa en consecuencia.

El problema de fondo: cada servidor se defiende solo

Aquí llegamos al punto que muchas pymes y proveedores de hosting pasan por alto. Aunque apliques las medidas anteriores, tu infraestructura sigue siendo un conjunto de máquinas que toman decisiones de seguridad de forma aislada. Una IP maliciosa golpea el servidor A, es bloqueada, y cinco minutos después prueba suerte contra el servidor B, que no sabe nada de lo ocurrido. Ese desfase es exactamente lo que las campañas automatizadas explotan.

Centralizar la protección cambia el juego. Con un enfoque como Abuse Shield de ALMC, el bloqueo de IPs maliciosas se aplica de forma automática y coordinada, fail2ban se gestiona de manera unificada en múltiples máquinas y un feed de reputación compartido propaga lo aprendido en un servidor al resto de la flota. Si una IP empieza a escanear el puerto 5173 en una máquina de Lleida, el resto de tus servidores en Barcelona, Tarragona o Girona ya la conocen antes de que llegue.

Esto encaja especialmente bien en empresas de hosting y pymes con servidores propios, donde no hay un SOC dedicado ni un equipo de guardia 24/7. No se trata de sustituir el criterio humano, sino de que la respuesta automática sea coherente en toda la infraestructura y no dependa de que alguien recuerde replicar reglas a mano.

Una rutina mínima que marca la diferencia

Más allá de este incidente concreto, conviene interiorizar tres hábitos: tratar cualquier servicio que escuche en una interfaz pública como si fuera producción, revisar periódicamente qué puertos están realmente abiertos y asumir que la seguridad perimetral de una sola máquina es insuficiente. La reputación de IP compartida entre servidores, el bloqueo de IPs automatizado y la gestión centralizada de fail2ban no son lujos: son la diferencia entre enterarte de un barrido cuando ya ha pasado o frenarlo en la primera petición.

La ciberseguridad de servidores ya no va de tener un firewall bien configurado en cada máquina. Va de que toda tu infraestructura reaccione como un solo organismo, cumpla con las exigencias del RGPD y la LOPDGDD en materia de protección de datos, y no dependa de que nadie se acuerde de actualizar una regla un viernes por la tarde.

Relacionado

¿Tus servidores bajo ataque constante?

Centraliza fail2ban y la reputación de IPs en todos tus servidores. Descubre Abuse Shield de ALMC. Contáctanos para una demo personalizada.

Resultados sin salir de la página.