Fly.io relata el parcheo de toda su flota en 10 horas por el fallo de kernel CVE-2026-99999

Fly.io publica un análisis posterior al incidente del 16 de octubre de 2026, cuando parcheó y reinició toda su flota de servidores en respuesta a un fallo del kernel de Linux. El despliegue completo duró 10 horas. El artículo, firmado por Daniel Botha y publicado el 6 de noviembre de 2026, combina el relato técnico con lecciones sobre comunicación de incidentes y recomendaciones de seguridad para quienes despliegan software con agentes.

El fallo, identificado como CVE-2026-99999, fue anunciado la mañana del día 15 por el equipo de CVE del kernel de Linux y por pwn.ai. Fly.io se enteró esa noche y empezó a preparar mitigaciones. El origen está en el 'checksum offload', un mecanismo de Linux que evita calcular de inmediato las sumas de comprobación de protocolos como TCP y UDP. En su lugar, el kernel guarda metadatos que indican desde dónde leer y dónde escribir la suma, y solo la calcula si hace falta. Esto funciona igual con máquinas virtuales: la tarjeta de red virtual acepta los metadatos y los pasa al host. El código de offload tenía comprobaciones para rechazar metadatos incorrectos, pero para IPv4 eran erróneas.

Para explotarlo, según el artículo, un atacante debe hacer tres cosas: apuntar la suma a otro campo de la cabecera, elegir un mensaje que produzca la suma deseada y forzar al host a calcularla por software. El resultado es que el host recibe el paquete, lo analiza y decide su destino, y después aplica la suma en el lugar equivocado. El atacante controla así dos bytes de una cabecera IPv4 en la que el host ya había confiado.

Esos dos bytes abren dos vías. La primera es un salto del cortafuegos: una reescritura de la IP de origen o destino ocurre después de que el host haya aplicado el enrutamiento y las reglas de firewall. La segunda es una lectura fuera de límites: reescribir la longitud de cabecera del IPv4 más pequeño al más grande hace que el host trate memoria adyacente como parte del paquete y capture 32 bytes como opciones del paquete saliente. Esa memoria puede contener paquetes del host, estructuras del kernel y paquetes de la máquina virtual vecina. Detectarlo es difícil: los paquetes del salto de firewall pueden estar bien formados, y los de lectura fuera de límites probablemente llevan una suma de cabecera errónea, pero cuando eso es visible ya es tarde. Las reglas XDP existentes no servían porque la reescritura ocurre después de ellas. Desactivar el checksum offload en el host exigía reiniciar, y si había que reiniciar, se haría con un kernel parcheado.

Sobre el posible impacto, Fly.io cree improbable que se expusieran datos de clientes, según la actividad de red observada durante el despliegue. Admite que, en teoría, entre la divulgación y el último reinicio una aplicación maliciosa podría haber leído pequeños fragmentos de tráfico de otras aplicaciones en el mismo host físico, aunque no tiene evidencia de que ocurriera. Recomienda a quien ejecutó cargas entre el 15 y el 17 de octubre rotar por precaución cualquier credencial enviada por HTTP u otro protocolo sin cifrar, incluido el tráfico sin cifrar por la red privada 6PN.

En la parte operativa, cada host tarda entre 15 y 20 minutos en reiniciar, y todas las Fly Machines que aloja quedan caídas durante ese tiempo. Como la colocación reparte las máquinas aleatoriamente entre hosts, no podían reiniciar más de uno a la vez sin tumbar todas las máquinas de algunas aplicaciones. Las aplicaciones de una sola máquina iban a caer en cualquier caso. Por eso planificaron en torno a Managed Postgres, dividiendo cada región en oleadas para que ningún clúster tuviera sus dos nodos en la misma. Aun así, su mayor región, iad, necesitó 17 oleadas.

Hubo imprevistos: la mayoría de los hosts volvieron dentro de la estimación anunciada, pero algunos no. Unos reiniciaron sin software esencial y requirieron reinstalación, otros se quedaron atascados en la BIOS, y un chasis de cuatro nodos en gru perdió una fuente de alimentación en pleno incidente sin repuesto en el sitio. Las máquinas de esos hosts siguieron caídas hasta que se restauraron el día 20. Según la empresa, no se perdieron Fly Machines ni datos de clientes.

La comunicación fue el otro punto delicado. A las 16:22 UTC publicaron un aviso de mantenimiento de emergencia en la página de estado y empezaron a avisar a los clientes mayores. El aviso decía 'mantenimiento', no seguridad, y no nombraba el CVE. Los clientes expresaron su malestar, algo que la empresa considera comprensible: un mantenimiento de emergencia el mismo día que reinicia toda una aplicación parece un parcheo apresurado sin explicaciones. La empresa explica que, al haberse divulgado el fallo junto con una descripción detallada de cómo explotarlo, decidió evitar confirmar públicamente que sus hosts eran vulnerables en ese momento. Como resultado del análisis posterior, su responsable de seguridad rehízo el plan de comunicación de incidentes: antes decidían el enfoque quienes estaban en el canal del incidente; ahora esa responsabilidad recae en el equipo directivo, con instrucciones precisas sobre quién dice qué, dónde y cuándo.

El artículo cierra con recomendaciones generales para un mundo en el que, según los autores, hay más fallos, se encuentran más rápido y se explotan con más facilidad. Primero, cifrar el tráfico entre los servicios propios, incluso en una red privada; el único consejo que tuvieron que dar tras este CVE fue rotar lo enviado en texto plano. Segundo, dar a los agentes credenciales limitadas al trabajo y con caducidad: el entorno de un agente es lo primero que lee una explotación exitosa, y un token que solo despliega una aplicación durante una hora es preferible a uno de toda la organización o que no caduca. Si es posible, mantener las credenciales fuera del alcance de los agentes. Tercero, asumir que toda frontera filtra un poco: la virtualización por hardware es la barrera más fuerte, pero durante día y medio un invitado pudo extraer 32 bytes cada vez, así que conviene no juntar en el mismo lugar un agente, sus secretos y los datos de producción. Cuarto, tratar lo que lee el agente como hostil y darle solo los permisos que se concederían al autor de la peor página web, incidencia o correo que pudiera leer. Quinto, ensayar la rotación de credenciales: hay que saber dónde están y poder localizarlas rápidamente.

Los autores reconocen que nada de esto hace invencible a nadie, pero sostienen que son restricciones firmes útiles cuando algo sale mal. Cierran con un tono resignado: nada de esto fue divertido y probablemente tendrán que repetirlo pronto.