Fly.io alerta del riesgo crítico del agente SSH de VSCode

El agente SSH de VSCode se comporta como un rootkit ligero

Cada vez que un desarrollador conecta VSCode a un servidor remoto con la extensión Remote SSH, el editor no se limita a abrir una sesión de shell: descarga un fragmento Bash que, a su vez, instala un agente completo —incluido un binario de Node.js— en la máquina de destino. Ese agente abre una conexión WebSocket tunelizada sobre el puerto SSH hacia el frontend de VSCode en la laptop, y a través de ese canal puede recorrer el sistema de archivos, editar archivos arbitrarios, lanzar sus propios procesos shell (PTY) y persistir más allá de la sesión. El equipo de Fly.io, en un post reciente firmado por su fundador Kurt Mackey, lo describe como de otro mundo (bananas) y advierte de las implicaciones.

Por qué Fly.io lo califica como un riesgo crítico

En seguridad, existe un nombre para las herramientas que combinan todas esas capacidades —acceso a filesystem, ejecución arbitraria, persistencia— y el autor del post reconoce no pronunciarlo por no ser justo con VSCode, aunque insinúa que empieza por m y termina en d. El problema, argumenta, escala con el entorno:

En una máquina de desarrollo personal, es incómodo.
Durante una incidencia en producción, es directamente peligroso: un agente iterativo ejecutando comandos sobre infraestructura real es exactamente el tipo de herramienta que un atacante querría tener a su disposición.

Cuando además el bucle lo cierra un modelo de lenguaje —que genera código, lo ejecuta, lee los errores y vuelve a iterar—, el riesgo deja de ser hipotético: el LLM puede tocar archivos fuera del proyecto, modificar configuración del sistema o desplegar cambios no revisados, todo desde el mismo canal persistente.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Tramp vs VSCode: dos filosofías opuestas

El post traza una línea con el precedente histórico: Emacs Tramp, el antepasado espiritual de la edición remota, opera sobre una sesión SSH estándar y ejecuta comandos Bourne shell ya presentes en el servidor. No instala nada, no abre puertos adicionales, no persiste. Vive de lo que el remoto ya ofrece.

VSCode, en cambio, hace una invasión a escala completa: cada conexión monta su propio runtime. La diferencia no es técnica, es de modelo de confianza. Tramp trata al servidor como una extensión de tu máquina y respeta su superficie; VSCode lo trata como un subordinado al que se le puede instalar lo que el editor decida ejecutar.

Fly.io en 2026: infraestructura para agentes de IA

El ángulo comercial del post es explícito: si vas a dejar que un LLM itere contra código real, mejor que lo haga sobre un Linux recién creado que no pueda hacerte daño. Ese razonamiento es la base de Fly Machines, la oferta insignia de Fly.io: instancias Linux efímeras pensadas para alojar bucles cerrados de agentes.

Según SDxCentral, Fly.io llevó esa idea más lejos con Sprites, VMs persistentes con arranque en segundos y 100 GB de almacenamiento, diseñadas para que un agente pueda instalar paquetes una vez, retomar tareas días después y volver a un checkpoint anterior en aproximadamente un segundo. El fundador Kurt Mackey, citado por SDxCentral, resumió la tesis así: Claude es un niño savant de cinco años hiperproductivo. Es increíblemente listo, quiere meter el dedo en cada enchufe disponible, y trabaja mejor cuando le das una forma de electrocutarse a sí mismo.

El negocio, además, está funcionando. Un comunicado distribuido por Globe Newswire el 24 de julio de 2026 anunció una Serie D de US$25M co-liderada por Dell Technologies Capital e Intel Capital, con participación de Andreessen Horowitz, EQT, Geodesic y YC. En paralelo, la compañía incorporó como CEO a Scott Johnston, ex CEO de Docker, con cargos directivos previos en Puppet, Loudcloud y Netscape, mientras que Mackey pasó a un rol advisory. Fly.io declaró más de 37.000 clientes, de los cuales unos 8.000 son agent-native; entre sus clientes más grandes, los agent-native representan aproximadamente dos tercios de la facturación, con crecimiento cercano a 12x en los últimos 12 meses. Casos públicos: Firecrawl, Kilocode, Plastic Labs y Phonic.

¿Qué significa esto para tu startup?

Si tu equipo usa VSCode Remote SSH sobre servidores compartidos, conviene revisar tres puntos antes del próximo incidente:

Qué está corriendo realmente en tus servidores. El agente de VSCode puede sobrevivir al cierre del editor. Audita procesos, puertos y binarios en ~/.vscode-server, /tmp y rutas similares tras desconexiones largas.
Quién puede usar Remote SSH hacia dónde. Un atacante con acceso al editor de un desarrollador obtiene, en la práctica, un canal persistente hacia cualquier host que ese desarrollador pueda alcanzar. Restringe destinos y, si puedes, exige autenticación multifactor.
Dónde corren tus agentes de IA hoy. Si tus agentes iteran sobre código y comandos en máquinas con datos sensibles, muévelos a entornos efímeros (Fly Machines, contenedores descartables o VMs de un solo uso) antes que sobre infraestructura persistente.

La conclusión del post es provocadora pero defendible: en 2026, el riesgo de seguridad ya no está solo en el código que escribes, sino en el editor que usas para escribirlo.