Están buscando secretos en servidores Vite: parchear puede no ser suficiente

El 17 de septiembre de 2026, la Agencia de Ciberseguridad de Singapur alertó de explotación activa contra servidores de desarrollo Vite. La alerta de la CSA señala que atacantes remotos sin autenticar pueden recuperar por HTTP archivos que deberían estar bloqueados y sitúa entre las versiones afectadas Vite 7.1.0–7.3.1, Vite 8.0.0–8.0.4 y Vite-plus 0.1.15 o anteriores.

La advertencia llegó después de una campaña automatizada observada en agosto que buscaba credenciales y archivos de infraestructura en servidores expuestos. La telemetría de F5 Labs contabilizó 807 ataques agrupados por sesión y unos 32.000 eventos sin procesar, con peticiones dirigidas a archivos .env, credenciales de AWS, tokens de Azure y estados de Terraform. Instalar el parche bloquea nuevas lecturas mediante esta vulnerabilidad, pero no invalida los secretos que ya pudieran haberse copiado.

La versión vulnerable no basta para demostrar exposición

La vulnerabilidad elude server.fs.deny, pero solo afecta a aplicaciones que reúnen condiciones concretas. El aviso de seguridad de Vite exige que el servidor de desarrollo se haya expuesto a la red mediante --host o server.host, que el archivo esté dentro de un directorio admitido por server.fs.allow y que una regla de server.fs.deny coincida con ese archivo.

En esas circunstancias, parámetros como ?raw, ?import&raw o ?import&url&inline pueden hacer que el servidor devuelva con HTTP 200 un archivo que normalmente debería rechazar. Las ramas afectadas de Vite son 7.1.0–7.3.1 y 8.0.0–8.0.4; las primeras versiones corregidas son 7.3.2 y 8.0.5. Para Vite-plus 0.1.15 o anterior, la recomendación pública es actualizar a la versión más reciente.

Vite enlaza por defecto el servidor a localhost. Por tanto, encontrar el paquete vulnerable en una dependencia no demuestra que fuera alcanzable desde internet. La exposición histórica puede proceder de --host, de un puerto de contenedor publicado, de un proxy inverso, de un ingreso de Kubernetes o de una regla de red que haya abierto el entorno de desarrollo o preproducción.

El árbol de decisión empieza por la exposición de agosto

El estado actual del servidor no responde por sí solo a la pregunta principal: si un tercero pudo leer archivos antes de la actualización. La investigación debe reconstruir la configuración existente durante agosto de 2026 y separar cuatro decisiones:

1. ¿Se ejecutó una versión afectada? Comprobar Vite 7.1.0–7.3.1, Vite 8.0.0–8.0.4 o Vite-plus 0.1.15 o anterior, incluyendo imágenes de contenedor y despliegues efímeros ya retirados.
2. ¿El servidor fue accesible desde una red no confiable? Revisar el historial de puertos, balanceadores, proxies, túneles, reglas de firewall, grupos de seguridad e ingresos. Que el puerto esté cerrado ahora no prueba que lo estuviera en agosto.
3. ¿Coincidían las condiciones de lectura? Identificar los directorios permitidos por server.fs.allow y los archivos protegidos mediante server.fs.deny. Solo los archivos alcanzables bajo esa combinación forman el conjunto potencialmente expuesto por este fallo.
4. ¿Hay registros suficientes para descartar una lectura? Buscar solicitudes a /@fs/, parámetros de consulta de lectura sin procesar, recorridos de directorios codificados y peticiones a nombres de archivos sensibles. Si faltan registros o no conservan la consulta y la respuesta, la incertidumbre debe influir en la decisión de rotar.

La actualización debe realizarse aunque todavía no haya terminado la reconstrucción. Para Vite, eso significa instalar como mínimo 7.3.2 o 8.0.5 en las ramas afectadas —o una versión posterior compatible— y retirar el servidor de desarrollo de interfaces públicas. El parche corta la vía conocida; el análisis posterior determina el posible alcance anterior.

Escaneo, explotación y compromiso no significan lo mismo

Una petición dirigida a una ruta inexistente o rechazada demuestra actividad de escaneo, no que se haya leído un secreto. Una respuesta HTTP 200 a una solicitud de evasión, especialmente si el tamaño transferido es compatible con el archivo pedido, aporta indicios de explotación satisfactoria. Para valorar cada caso hacen falta los registros del servidor y, cuando existan, los del proxy, el balanceador o el WAF.

El compromiso confirmado requiere evidencia adicional: una respuesta que entregó contenido sensible, el uso posterior de una credencial, sesiones desconocidas, cambios en recursos cloud o acciones atribuidas a la identidad afectada. La ausencia de estos rastros no descarta una lectura cuando los registros se rotaron, no guardaban los parámetros de consulta o solo cubren una parte de la ruta de red.

Tampoco conviene atribuir las peticiones por el nombre declarado por el cliente. La campaña observada utilizó agentes de usuario que imitaban rastreadores conocidos e introdujo valores falsificados en X-Forwarded-For y X-Real-IP. Esos encabezados sirven como indicadores para buscar, pero no como prueba fiable del origen.

Qué secretos deben rotarse después del parche

Si una versión afectada estuvo accesible desde redes externas durante agosto y los registros no permiten descartar la lectura, deben considerarse potencialmente expuestos los secretos situados en los directorios alcanzables. El conjunto puede incluir variables .env, claves API, contraseñas de bases de datos, credenciales de AWS, tokens de Azure, claves privadas y copias de respaldo con los mismos valores.

Los archivos terraform.tfstate necesitan una revisión por contenido. No se rota “Terraform”: se sustituyen y revocan las contraseñas, claves o tokens almacenados en el estado o recuperables a partir de él. También deben actualizarse los almacenes de secretos y los despliegues dependientes, evitando que una copia antigua siga aceptada por el proveedor.

La prioridad depende de la capacidad de cada credencial. Primero corresponden las claves administrativas y las que permiten crear identidades, emitir tokens o modificar infraestructura; después, las credenciales de escritura, despliegue y bases de datos; por último, los accesos de solo lectura y menor alcance. Rotar implica revocar el valor anterior, no limitarse a generar uno nuevo.

El parche resuelve el fallo, no la incertidumbre histórica

La explotación activa y la búsqueda masiva de archivos sensibles están documentadas, pero la telemetría no demuestra que todos los servidores sondeados entregaran información ni que cada organización objetivo sufriera una toma de control. El resultado para una instalación concreta depende de su versión, sus reglas de acceso a archivos, su exposición de red y la evidencia conservada.

Para un servidor que nunca fue alcanzable desde una red no confiable, la evaluación es distinta de la de una instancia pública sin registros completos. En este último caso, cerrar el puerto y actualizar son medidas necesarias, pero insuficientes: todavía hay que delimitar qué archivos pudieron leerse, revocar los secretos asociados y revisar su uso posterior.

Lee también:

• Tu empresa puede vigilar el correo, pero debe explicar por qué lo hace
• La IA no puede ser autora: el trabajo humano decide qué se protege
• JetBrains dejó Cadence sin parchear: ahora toca rotar todos sus secretos