La pared entre inquilinos tenía una grieta

La promesa callada de todo servidor en la nube y de todo servidor privado virtual es la separación. Su máquina y la del desconocido que paga al mismo proveedor corren sobre el mismo hardware físico, y una capa llamada KVM, incorporada al kernel de Linux, es lo que las mantiene apartadas. Januscape, registrado como CVE-2026-53359, es una grieta en esa pared. Es una condición de carrera en la forma en que KVM gestiona las tablas de páginas en sombra, el mapa interno que traduce la memoria de una máquina huésped a memoria real. Con el fallo, el host puede asociar una de esas entradas al marco de huésped equivocado, una confusión de número de marco y de tipo que, guiada con cuidado, permite a una máquina virtual hostil empujar al host a mapear la memoria que el atacante elige. Eso es una fuga de huésped a host: el inquilino sale de su caja al suelo que todos comparten.

Lo que lo agrava es el alcance. El fallo está en código común a los procesadores Intel y AMD, así que se dispara con VMX y EPT por un lado y SVM y NPT por otro. Se introdujo en 2010 y quedó latente dieciséis años, lo que significa que casi todos los kernel de Linux publicados en ese periodo lo llevan. Se divulgó el 6 de julio en la lista pública oss-security, se corrigió en el código base el 16 de junio, y los kernel estables corregidos, las versiones 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 y 5.10.260, solo llegaron el 4 de julio.

Por qué lo parcheamos ahora tiene dos respuestas

El peligro inusual aquí no es el fallo, es la forma del remedio. Cerrar Januscape exige dos commits acoplados en el código base, no uno: la corrección de la fuga que lleva CVE-2026-53359 y una corrección acompañante de número de marco que lleva CVE-2026-46113. Si se aplica solo la primera, la del nombre memorable, la puerta queda entornada. Un administrador que leyó el aviso destacado, aplicó ese único parche y cerró el ticket ha hecho lo razonable y sigue expuesto. Por eso una frase de rutina, ya lo parcheamos, deja de zanjar el asunto en este fallo.

Para un propietario la exposición rara vez es su propio rack de servidores. Es el proveedor bajo sus proveedores: el host VPS que ejecuta su web, la nube privada que ejecuta su software de negocio, la plataforma gestionada que ejecuta sus datos. En España, el INCIBE y su CERT son la vía de notificación, y la NIS2 empuja la misma expectativa: usted sigue respondiendo por la seguridad de los servicios prestados en su nombre. Una fuga del hipervisor es justo el tipo de fallo de infraestructura compartida para el que se escribieron esas reglas, porque un host sin parchear puede deshacer la separación que mil clientes estaban pagando.

La pregunta para su proveedor de alojamiento esta semana

Para la mayoría de los propietarios esto no es una tarea de compilar kernel, es una pregunta de compras hecha con claridad. Plantee a quien ejecuta sus máquinas virtuales, ya sea un host VPS, un equipo interno de nube privada o un proveedor de plataforma gestionada, tres cosas: si el kernel del host está ya en una versión estable corregida o en un parche en caliente; si esa corrección incluye los dos commits, el de la fuga y su acompañante; y cuándo se aplicó. No hay ningún interruptor de configuración que lo vuelva seguro. Un kernel parcheado con reinicio, o un parche en caliente aplicado sin él, es la única respuesta completa, y hasta que esté en su sitio, todo host multiinquilino debe tratarse como alcanzable desde un vecino hostil.

El cambio práctico es pequeño pero real. El inquilino de al lado, un nombre que nunca conocerá, pasó este mes de ser una preocupación abstracta a una línea de su modelo de amenazas. Los propietarios que convierten eso en una respuesta escrita y concreta de su proveedor, en lugar de una suposición cómoda, son los que no estarán adivinando si este fallo llega a encadenarse en una intrusión real.

Leer a continuación: CitrixBleed vuelve, explotado en menos de un día  |  Un token falso abre cada PC que gestiona la herramienta