PwnEscape: la falla de Linux que obligó a reiniciar servidores en todo el mundo

Hace unos días hubo un reinicio masivo de servidores. No fue un ataque: fue la cura. Desde el jueves 15, proveedores de servidores de todo el mundo salieron a parchar de urgencia sus máquinas por CVE-2026-99999, una falla crítica del núcleo de Linux bautizada PwnEscape.

Qué es PwnEscape, en criollo

Buena parte del hosting funciona igual: una computadora física muy potente, el host, se divide en muchas computadoras virtuales, los VPS, que se alquilan a clientes distintos. El programa que reparte esa máquina se llama hipervisor, y la promesa es que lo que pasa dentro de tu VPS no puede tocar al vecino ni a la máquina de abajo.

Según la ficha oficial de la vulnerabilidad, el error está en cómo el núcleo de Linux del host procesa ciertos datos que acompañan a los paquetes de red que salen de una máquina virtual. Con paquetes armados a propósito, quien controla un VPS podía hacer que el host le devolviera pedazos de su memoria o que se colgara y, en laboratorio, tomar el control del host como administrador.

Pese al nombre, no es una falla de KVM, el hipervisor más usado en Linux, sino del código de red del propio núcleo, como aclara el aviso de AlmaLinux, que además ubica el código vulnerable en Linux desde 2008. Los mantenedores del núcleo la calificaron con 9,3 sobre 10, nivel crítico. No se dispara desde cualquier lugar de internet: el atacante tiene que estar ejecutando código dentro de una máquina virtual. Pero en un servicio donde cualquiera alquila un VPS con una tarjeta, esa condición es fácil de cumplir.

Cómo se descubrió

En agosto, Vercel ofreció hasta un millón de dólares en premios a quien lograra escapar de sus entornos aislados. Según su informe, el hallazgo más importante llegó al tercer día, de la mano de Paulos Yibelo, investigador de la firma pwn.ai. La fuga de memoria se demostró contra los entornos reales de Vercel; el cuelgue y la toma de control, en máquinas del propio investigador.

El 4 de septiembre la falla se reportó en privado a los responsables del núcleo. La corrección, escrita por Michael S. Tsirkin, de Red Hat, entró a la versión principal de Linux el 14 de octubre. El 15 se publicaron la ficha del CVE, el análisis técnico de pwn.ai y el boletín de AWS. Ahí empezó la carrera.

Por qué le pegó a tantos proveedores a la vez

Porque casi todos usan la misma base. Vercel lo resumió así: casi todos los grandes proveedores de nube separan a sus clientes sobre esta misma capa del núcleo de Linux, así que un defecto ahí es un riesgo para toda la infraestructura compartida.

Y el arreglo no es un clic: hay que actualizar el núcleo del host y reiniciarlo, y con él se pausan o reinician todos los VPS que tiene encima. Las capturas de avisos que circularon el fin de semana muestran en mantenimiento de emergencia a Akamai (Linode), Hostinger, BandwagonHost, Contabo, Sakura Internet, Fly.io y FreakHosting, entre otros. Algunos ejemplos:

• Akamai (Linode) reconoció el problema el 15 a las 14:27 (hora argentina) y a las 2:07 del 17 dio por terminado el parche de sus hipervisores, sin explotación detectada, según su página de estado, y con tiempos de reinicio de unos 8 minutos por VPS.
• BandwagonHost explicó en su aviso que mudar cada VPS antes de reiniciar le llevaría unas dos semanas, así que reinició directo: pausas de 6 a 7 minutos en la mayoría de los casos.
• Hostinger parchó por tandas desde el 16 y reinició cada VPS al menos una vez, según su página de incidentes.
• Contabo avisó en su centro de ayuda que no podría notificar cada reinicio por separado y pidió tener copias de seguridad recientes.
• UpCloud mueve las máquinas en caliente y no espera impacto visible para la mayoría, salvo en servidores con GPU, con cortes de 30 a 60 minutos, según su comunicado.
• AWS informó que EC2, Lambda y Fargate no están afectados; el riesgo es para quien administra por su cuenta máquinas virtuales con KVM sobre núcleos sin parchar.

¿Hubo ataques reales? No hay evidencia pública. Varios proveedores dicen no haber detectado explotación y la falla no figura en el catálogo de vulnerabilidades explotadas de CISA, la agencia de ciberseguridad de Estados Unidos. Que no se haya detectado no prueba que no haya pasado.

La reflexión: ya no importa cuán chico seas

Durante años, muchas webs se sintieron a salvo por ser chicos: "¿quién va a querer atacar a un diario local ?". PwnEscape muestra el límite de esa lógica. Ningún proveedor esperó a ver a quién apuntaban los atacantes; parcharon todo, porque una vulnerabilidad se explota por el solo hecho de existir. Esto puede empezar a ocurrir con cierta frecuencia, y el tamaño o la importancia de un servicio ya no protege.

Hay señales de que esa frecuencia va a subir. Según pwn.ai, llegaron a la falla en tres días, con un modelo de inteligencia artificial como motor principal del análisis y menos de 700 dólares de gasto, aunque la investigación la dirigieron personas. Vercel recibió 1.285 reportes en dos semanas y lo atribuyó a que los investigadores ahora trabajan "a velocidad de IA". Ya lo advertían más de cien empresas de tecnología.

¿Qué puede hacer un medio con esto?

• Elegí un proveedor que parche rápido y lo diga. Fijate si tiene página de estado pública y cuánto tardó en reaccionar esta vez.
• Tené tu propio canal de aviso. Si el sitio se cae en plena cobertura, tus lectores tienen que saber dónde enterarse: redes, newsletter.
• Hacé copias de seguridad fuera del servidor (si manejás tu propio VPS). Que un reinicio salga mal es raro, pero Contabo se lo pidió a todos sus clientes por algo.
• No dejes un WordPress autoadministrado sin actualizar. El proveedor parcha el host; el sistema de tu servidor, los plugins y el CMS siguen siendo tu problema.
• Averiguá quién actualiza qué. Si no lo sabés, este es buen momento. Y si querés salir de ese esquema, migrar a Medios CMS con CMSBridge es el camino más fácil y sin costo.

Una plataforma autoadministrada no te vuelve inmune; nuestros ocho minutos lo prueban. Lo que cambia es quién se queda mirando los avisos el fin de semana: mantener los servidores de la plataforma es trabajo nuestro, no de cada redacción. Igual que con los ataques de denegación de servicio, la seguridad de un medio ya no se resuelve con un plugin: depende de la infraestructura que elegiste y de qué tan rápido reacciona cuando algo se rompe.