HD Doctor Logo

Proxmox Corrupto: Fallos, Vulnerabilidades y Recuperación

Por el Equipo Técnico HD Doctor

Respuesta directa

Un Proxmox corrupto tiene tres causas dominantes: fallo de storage (ZFS o LVM-thin), corrupción del cluster filesystem en /etc/pve e intrusión por vulnerabilidad sin parche. Las VMs casi siempre siguen en el disco — lo que se rompió es la capa que apunta hacia ellas. Diagnosticar antes de reparar es lo que separa 2 horas de trabajo de una pérdida definitiva.

Qué se corrompe exactamente en un Proxmox

Cuatro capas independientes pueden fallar, y el síntoma en pantalla rara vez dice cuál fue. (1) El pmxcfs: /etc/pve no es un directorio normal, es un sistema de archivos FUSE apoyado en SQLite en /var/lib/pve-cluster/config.db, replicado por Corosync. La pérdida de quórum o la corrupción de esa base deja /etc/pve en solo lectura y hace desaparecer las VMs de la interfaz — incluso con los discos intactos. (2) El storage: ZFS con pool FAULTED, errores de checksum o fallo al importar; LVM-thin con metadatos llenos o corruptos ('Check of pool failed'); Ceph con OSDs down y PGs incomplete. (3) El boot: fallo al importar rpool, systemd-boot o GRUB apuntando al dataset equivocado tras una actualización. (4) El vector de seguridad: el 1 de septiembre de 2026 Proxmox publicó el advisory PSA-2026-00043-1 (CVE-2023-54391), un bypass de autenticación en libpve-access-control donde el parámetro tfa-challenge del endpoint /api2/json/access/ticket permite entrar como root@pam sin contraseña. Afecta las versiones 7.0-7 hasta anteriores a 8.0.4 del paquete — es decir, Proxmox VE 7.0 a 7.4 y las primeras instalaciones 8.0 nunca actualizadas. Hay explotación activa, con ransomware y mineradores, y el prerrequisito es el puerto 8006 expuesto a internet.

Síntomas comunes y qué significa cada uno

  1. 1.
    'cannot import rpool: I/O error' en el arranque. El pool ZFS no importa por disco con fallo, cable/backplane malo o corrupción de metadatos. Nunca use -f como primer intento: importe readonly=on y evalúe. Con hardware sospechoso, imagen antes que nada.
  2. 2.
    /etc/pve en solo lectura y VMs desaparecidas de la interfaz. Pérdida de quórum de Corosync (cluster) o corrupción del config.db. Los datos de las VMs no fueron afectados — es la capa de configuración. Recuperable vía pmxcfs en modo local.
  3. 3.
    'Check of pool failed (status:1)' en LVM-thin. Metadatos thin corruptos o llenos. Es el escenario que más se pierde por reparación apresurada: lvconvert --repair en el original reescribe el mapeo. Copie los metadatos y trabaje con thin_dump antes.
  4. 4.
    ZFS con checksum errors subiendo en zpool status. Señal de disco degradándose, RAM sin ECC defectuosa o controladora con problema. Haga backup inmediato antes del scrub — un scrub en pool ya degradado a veces termina de tumbar lo que aún leía.
  5. 5.
    La VM no arranca: 'qcow2: Image is corrupt'. Encabezado o tabla L1/L2 dañados, normalmente por corte de energía durante escritura o storage lleno. qemu-img check -r all puede resolver casos leves — siempre sobre copia, nunca sobre el disco de producción.
  6. 6.
    Login extraño de root, logs vacíos y CPU al 100%. No es fallo, es intrusión. Combinación típica del PSA-2026-00043-1: minero consumiendo la CPU, logs redirigidos a /dev/null y, en parte de los casos, ransomware después. Aísle la máquina de la red sin apagarla.

Diagnóstico seguro de un Proxmox corrupto, en 7 pasos

Orden pensado para no destruir lo que aún es recuperable. Si en cualquier paso aparece señal de intrusión, deténgase y trátelo como incidente de seguridad, no como fallo técnico.

  1. 1

    Deje de reiniciar

    Cada arranque de un host con LVM-thin o ZFS degradado dispara replay de journal e intentos de reparación automática que consumen metadatos antiguos. Si el host ya no levanta, un reinicio más no lo va a cambiar — solo reduce lo que se puede recuperar.

  2. 2

    Arranque en modo rescue y monte todo read-only

    Arranque por live USB (el propio ISO de Proxmox en Debug Mode sirve) e importe el storage sin escribir: zpool import -o readonly=on -N rpool, o activación de LVM sin montar. Ver el estado real del storage sin grabar en él es la única forma segura de decidir qué sigue.

  3. 3

    Clasifique el fallo antes de tocar nada

    Ejecute el diagnóstico de solo lectura: zpool import y zpool status -v para ZFS; pvs, vgs, lvs -a y thin_check sobre copia de los metadatos para LVM-thin; ceph -s y ceph osd tree para Ceph; smartctl -a en cada disco. Fallo de disco físico, fallo lógico e intrusión exigen caminos totalmente distintos.

  4. 4

    Verifique si hubo intrusión

    Revise la versión del paquete con dpkg -l libpve-access-control (por debajo de 8.0.4 = vulnerable al PSA-2026-00043-1) y busque los indicadores publicados: archivo /var/lib/systemd/PVE-1, servicio PVE-1.service, archivos de log convertidos en enlace a /dev/null y conexiones de salida hacia pools de minería. Revise también /root/.ssh/authorized_keys, crontab y usuarios nuevos en /etc/pve/user.cfg.

  5. 5

    Recupere las configuraciones de las VMs desde config.db

    Si /etc/pve está vacío o en solo lectura, los archivos .conf no se perdieron: viven dentro de /var/lib/pve-cluster/config.db. Con el servicio detenido, pmxcfs -l monta el cluster filesystem en modo local y devuelve las definiciones de cada VM y contenedor, incluido el mapeo de discos — información esencial para reconectar los volúmenes después.

  6. 6

    Extraiga las VMs antes de intentar arreglar el host

    La prioridad es el dato, no el hypervisor. Con el storage montado read-only, copie los discos de las VMs a un destino externo y valide cada uno con qemu-img check. Solo después, con la copia segura, vale intentar reparación del pool, de los metadatos thin o del boot — si la reparación falla, no perdió nada.

  7. 7

    Reconstruya corrigiendo ya el vector del fallo

    Vuelva en versión soportada (8.x o superior), saque la interfaz 8006 de internet, deje acceso solo por VPN o lista de IPs, habilite TOTP para todas las cuentas, deshabilite login root por SSH y configure backup en PBS con verificación y copia inmutable. Reconstruir sin cerrar la puerta de entrada es repetir el incidente en semanas.

Preguntas frecuentes

¿Cómo sé si mi Proxmox es vulnerable al PSA-2026-00043-1?

Ejecute dpkg -l libpve-access-control en el host. Cualquier versión desde 7.0-7 y anterior a 8.0.4 es vulnerable — lo que incluye Proxmox VE 7.0 a 7.4 e instalaciones 8.0 nunca actualizadas. La corrección existe desde julio de 2023; lo que cambió en septiembre de 2026 fue la explotación masiva. Si el host está en versión fin de vida, actualice a una release soportada e, inmediatamente, saque el puerto 8006 de internet.

¿Proxmox corrupto significa VMs perdidas?

Casi nunca. En la mayoría de los casos que atendemos, los discos de las VMs estaban íntegros y lo que se rompió fue la capa de configuración (/etc/pve), los metadatos del pool o el arranque. Por eso el orden importa: extraer las VMs primero, reparar el host después.

¿Puedo ejecutar qemu-img check -r all para arreglar la VM?

Puede, pero nunca en el disco original. El -r all reescribe estructuras del QCOW2 y, en una imagen con daño mayor, puede empeorar el cuadro. Haga copia del archivo (o snapshot del dataset) y ejecute la reparación en la copia.

Perdí el quórum del cluster y /etc/pve quedó read-only. ¿Y ahora?

En cluster con nodos caídos, pvecm expected 1 devuelve la escritura temporalmente en el nodo sobreviviente — solución de contingencia, no de rutina. Si el problema es el config.db corrupto y no el quórum, el camino es pmxcfs en modo local para extraer las configuraciones antes de cualquier reconstrucción.

¿Vale reinstalar Proxmox e importar el pool después?

Solo después de tener las VMs copiadas afuera y con certeza de que el pool está sano. Reinstalar con storage degradado es la forma más común de convertir un fallo lógico reparable en caso de laboratorio: el instalador toca la tabla de particiones y puede reinicializar el pool.

Fallo físico de disco en ZFS RAIDZ: ¿se puede recuperar?

Sí, y es de los escenarios con mejor pronóstico — RAIDZ tolera 1 disco (RAIDZ1) o 2 (RAIDZ2). El riesgo está en el resilver: con discos del mismo lote envejeciendo juntos, es común que un segundo falle durante la reconstrucción. Si ya salieron dos discos, detenga el resilver y trátelo en laboratorio con imagen de cada miembro.

¿HD Doctor atiende Proxmox de cualquier versión y storage?

Sí: Proxmox VE 4.x a 9.x, con ZFS (mirror, RAIDZ, RAIDZ2), LVM-thin, Ceph RBD, NFS, CIFS y directory, además de contenedores LXC. En 20+ años fueron 280+ entornos Proxmox, con 91% de recuperación. Diagnóstico en 24h y NDA antes del envío.

¿Proxmox fuera de servicio o con sospecha de intrusión?

Diagnóstico en 24h. No reinstale ni reinicie antes de hablar con un ingeniero.

Próximas lecturas