Fallo crítico en LXD y MicroCloud: qué revisar en tu VPS

Un fallo en LXD y MicroCloud, el gestor de contenedores y máquinas virtuales de Canonical, permite a un atacante que llegue a su API por la red hacerse pasar por un cliente de confianza sin tener su clave. Canonical publicó los parches el 29 de octubre de 2026. Afecta a servidores y VPS que usan LXD con la API abierta.

Lo que se sabe

  • Qué es: LXD comprobaba los certificados de los clientes contra su lista de confianza, pero aceptaba como prueba toda la cadena de certificados, cuando la conexión solo demuestra que el cliente posee la clave del primero. Con el certificado público de un cliente de confianza bastaba para suplantarlo, según el aviso de Canonical del 28 de octubre.
  • Quién puede atacar: según Canonical, alguien «able to reach the LXD HTTPS API», es decir, que llegue a la API HTTPS de LXD, y que tenga el certificado público de un cliente de confianza. En MicroCloud, la vía es interceptar el certificado público de un miembro mientras se une al clúster. Dependiendo de los permisos de la identidad suplantada, Canonical dice que puede acabar en acceso root al servidor anfitrión.
  • Gravedad: el proyecto Incus, que lo descubrió y avisó a Canonical, le da 10 sobre 10 (CVSS 3.1) en su aviso de GitHub. Canonical lo califica de «crítico». La página del CVE en Ubuntu le asigna prioridad media para sus paquetes tradicionales; LXD se distribuye hoy como paquete snap.
  • Versiones corregidas (29 de octubre): LXD 6.10.1 (canal 6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable) y 4.0.15 (4.0/stable); MicroCloud 3.4.1 (3/stable) y 2.1.5 (2/stable). Incus lo corrige en la 7.6.0.
  • Despliegue gradual: Canonical avisa de que las nuevas versiones de LXD pasan poco a poco de «candidate» a «stable», así que la actualización puede no aparecer en el acto.
  • Ataques: según The Hacker News, la ficha del CVE recoge una valoración de CISA del 30 de octubre que no conoce explotación, y no hay un exploit publicado.

Qué cambia y qué no

  • Cambia para quien gestiona un servidor con LXD o MicroCloud cuya API escucha en la red: un clúster, un VPS administrado en remoto o un servidor de un proveedor que reparte contenedores.
  • Cambia menos para quien usa LXD solo en local: la API HTTPS no está abierta a la red si no se configura. Aun así, conviene actualizar.
  • No cambia para quien tiene la web en hosting compartido o en un VPS sin LXD: no hay nada que tocar en su servidor.
  • No toca la web: WordPress, Drupal, PHP y los plugins no tienen nada que ver; es la capa que crea y aísla los contenedores.

Cómo saber si te afecta

  1. Averigua si usas LXD. En una terminal del servidor, `snap list lxd` (o `snap list microcloud`) muestra la versión y el canal. Si responde que no está instalado, este fallo no es tuyo.
  2. Compara la versión con la corregida de tu canal: 6.10.1, 5.21.9, 5.0.11 o 4.0.15 en LXD; 3.4.1 o 2.1.5 en MicroCloud.
  3. Mira si la API está abierta a la red con `lxc config get core.https_address`. Si sale vacío, LXD solo escucha en local. Si sale una dirección y un puerto (por defecto el 8443), la API es alcanzable y la urgencia es mayor.
  4. Actualiza con `sudo snap refresh lxd` y, si lo usas, `sudo snap refresh microcloud`. Si todavía no llega la versión corregida, vuelve a probar en unas horas.
  5. Mientras tanto, cierra el acceso. El aviso de Incus dice que no hay ajuste que lo evite y recomienda limitar el acceso de red a la API a equipos de confianza: en la práctica, una regla de cortafuegos para ese puerto.
  6. Si tu VPS lo da un proveedor, pregúntale: «¿Usáis LXD o MicroCloud para crear las máquinas? ¿Ya está aplicada la corrección de CVE-2026-112816?». Si tu web está en hosting compartido, esa pregunta basta.

Relacionado: Fallo crítico en el kernel Linux: qué revisar en tu servidor

Fuentes

Actualizaciones: si se confirma explotación real o Canonical cambia las versiones corregidas, se añadirá aquí con su enlace.