Proxmox CVE-2023-54391: por qué actualizar PVE 7 ya

CVE-2023-54391 es un bypass de autenticación confirmado que afecta a instalaciones antiguas de Proxmox VE a través del paquete libpve-access-control. El aviso de Proxmox de septiembre de 2026 indica que las versiones vulnerables del paquete empiezan en la 7.0-7 y llegan hasta antes de la 8.0.4, lo que cubre aproximadamente Proxmox VE 7.0 a 7.4 y la primera versión de Proxmox VE 8.0. Si todavía ejecutas Proxmox VE 7, actualizar a una versión con soporte es ahora una tarea de seguridad urgente.

Revisé el registro del CVE y el debate del foro de Proxmox que dio lugar al aviso, porque los primeros informes describían un posible zero day sin pruebas del vector de entrada. Ahora el panorama está más claro: hay un CVE con nombre, un rango de paquetes vulnerables, un aviso y varios usuarios que informan de hosts antiguos comprometidos. Eso respalda una conclusión más firme que el primer rumor, aunque más acotada que afirmar que todos los sistemas Proxmox están expuestos.

¿Qué es exactamente CVE-2023-54391?

CVE-2023-54391 es un bypass de autenticación en el componente libpve-access-control de Proxmox VE. El registro del CVE indica que Proxmox VE 7.0 a 8.0 contiene el fallo antes de la versión 8.0.4 del paquete afectado.

En la práctica es grave. El código de autenticación está delante del plano de gestión, así que un atacante que consiga saltárselo en un host de virtualización expuesto llega a la capa que controla las máquinas virtuales, el acceso al almacenamiento, la configuración de red y las funciones administrativas que las rodean, mucho más que una sola aplicación invitada.

El aviso de Proxmox citado en el foro da un rango de paquetes más preciso: versiones de libpve-access-control mayores o iguales que 7.0-7 e inferiores a 8.0.4. También dice que ese rango se corresponde a grandes rasgos con Proxmox VE 7.0 a 7.4, más la versión inicial de Proxmox VE 8.0.

La versión del paquete te dice más que la versión comercial, porque las dependencias no siempre avanzan al mismo ritmo que el número de versión del producto. Si estás investigando la exposición, comprueba el paquete instalado en lugar de dar por hecho que "PVE 8" responde automáticamente a la pregunta.

¿De verdad se estaba explotando en la práctica?

Hay informes creíbles de hosts Proxmox VE 7 comprometidos en el mismo periodo, pero conviene tener cuidado antes de atribuir cada incidente notificado a CVE-2023-54391. En el hilo del foro hay usuarios que describen ransomware o actividad destructiva, minería de criptomonedas, persistencia, archivos de autenticación modificados y técnicas antiforenses en hosts antiguos expuestos.

La prueba más sólida es que el problema pasó de sospecha de la comunidad a aviso de Proxmox y registro de CVE. Eso confirma la vulnerabilidad, aunque no demuestra que todos los atacantes vistos en todas las publicaciones del foro usaran exactamente la misma cadena.

La distinción importa porque la respuesta a incidentes debe continuar después de encontrar una vulnerabilidad plausible. Un host sin soporte puede tener otras debilidades sin parchear, servicios expuestos, credenciales reutilizadas, invitados comprometidos o persistencia añadida después del acceso inicial. Si encuentras señales de compromiso, trata el host como infraestructura comprometida y no como un sistema limpio con un paquete defectuoso.

¿Qué sistemas Proxmox deberían preocuparse más?

Los sistemas Proxmox VE 7 expuestos a internet son la máxima prioridad, porque Proxmox VE 7 está fuera de soporte desde julio de 2024 y el bypass de autenticación recién documentado afecta a esa rama antigua. Un plano de gestión obsoleto y accesible directamente desde internet combina dos riesgos que nunca deberían convivir tranquilamente.

La interfaz web de Proxmox suele escuchar en el puerto 8006. Eso por sí solo no hace vulnerable el puerto 8006 en todas las versiones. El problema es exponer tan ampliamente un servicio de gestión con privilegios altos que un fallo de autenticación futuro pase a ser accesible en remoto.

Por eso "usé una contraseña larga" no te protege aquí. Una contraseña protege una vía de autenticación, y un bypass de autenticación ataca la vía en sí.

Si necesitas administración remota, pon la gestión detrás de una VPN, direcciones de origen restringidas, un bastión u otra capa de acceso controlada. La guía de instalación de Proxmox ya trata la interfaz web como una interfaz de gestión y no como una aplicación web pública, y los despliegues de producción deberían ser todavía más estrictos.

¿Cómo compruebo si tengo instalado el paquete vulnerable?

Comprueba la versión instalada del paquete libpve-access-control y compárala con el rango afectado del aviso de Proxmox. En el debate del foro se usó dpkg-query para identificar la versión instalada y se señaló que las versiones inferiores a 8.0.4 eran vulnerables dentro de la rama correspondiente.

No leas "8.0.4" como un punto en el que detenerte en septiembre de 2026. Esa corrección histórica cerró esta vía de código concreta, pero Proxmox VE 8 ya es lo bastante antiguo como para que un sistema de producción pase a la versión mayor con soporte actual y no a la compilación mínima que evita un CVE.

La página de Proxmox de Mr.PlanB sigue la versión actual y el contexto de actualización. Úsala como punto de partida y después sigue la documentación oficial de actualización de Proxmox para conocer el camino exacto con soporte desde tu instalación actual.

Antes de una actualización mayor, verifica las copias de seguridad, prueba una restauración, revisa los repositorios de terceros, confirma la salud del almacenamiento y asegúrate de entender el quórum del clúster y las dependencias de red. La urgencia de seguridad no hace más segura una actualización sin control.

¿Y si el host ya estaba comprometido?

Si el host ya estaba comprometido, reconstruirlo es más seguro que intentar limpiarlo en el sitio. Un host de virtualización tiene privilegios suficientes para que un atacante pueda alterar la autenticación, la configuración de SSH, los servicios, los registros, los archivos de arranque y el estado de gestión de los invitados.

Los informes del foro lo muestran bien. Hay usuarios que describieron mineros ocultos, persistencia por SSH, código de AccessControl modificado, utilidades borradas, registros destruidos y marcas de tiempo manipuladas. Aunque elimines la carga visible, demostrar que ha desaparecido todo mecanismo de persistencia es difícil.

Una secuencia de recuperación defendible consiste en aislar la red de gestión afectada, conservar las pruebas si necesitas un análisis forense, rotar las credenciales que hayan podido pasar por el host, instalar una versión de Proxmox VE con soporte desde medios de confianza, restaurar la configuración con cuidado y recuperar las cargas de trabajo desde la última copia de seguridad que sepas que está limpia.

No conectes un repositorio de copias de seguridad a un host comprometido dando por hecho que la copia es segura solo porque los archivos de las VM siguen ahí. Comprueba la integridad de las copias y los registros de acceso. Si el atacante tuvo control administrativo del hipervisor, piensa en qué credenciales o qué almacenamiento montado podía alcanzar el host. Este es también un motivo para mantener separada la infraestructura de copias de seguridad, de modo que comprometer un hipervisor no dé automáticamente acceso destructivo a todas las copias de recuperación.

¿Significa esto que Proxmox no es seguro para uso empresarial?

No. El software sin soporte y las interfaces de gestión expuestas crean un riesgo predecible, y en una rama antigua de Proxmox existió un fallo de autenticación grave. Todas las grandes plataformas de infraestructura reciben avisos de seguridad con el tiempo.

Más útil que preguntarse si un producto ha tenido alguna vez un CVE es fijarse en lo rápido que reciben correcciones las versiones con soporte, lo claramente que se identifican las versiones afectadas, cómo gestiona la organización los parches y cuánta exposición hay antes de que llegue el parche.

El paso de Proxmox en 2026 al soporte empresarial 24/7 refuerza su oferta de soporte, pero el soporte no sustituye a la disciplina con el ciclo de vida. Una suscripción empresarial no puede rescatar un host que lleva años en una versión sin soporte y publicado directamente en internet.

La misma regla se aplica a VMware, Hyper V, Linux, las cabinas de almacenamiento, los firewalls y los sistemas de copia de seguridad. Los planos de gestión merecen un acceso más restringido que las aplicaciones normales, porque las consecuencias de un compromiso son mayores.

¿Debería ser público alguna vez el puerto 8006 de Proxmox?

Yo no expondría la interfaz de gestión de Proxmox directamente a internet. Incluso con una versión con soporte y todos los parches, ganas poco dando a cada escáner de internet una ruta hacia tu interfaz de infraestructura con más privilegios.

Usa una VPN, restricciones por IP de origen, un proxy de acceso seguro pensado para uso administrativo o una red de gestión dedicada. Añade autenticación multifactor donde se pueda, separa las cuentas de administrador de las cuentas del día a día y monitorea los eventos de autenticación.

La exposición directa solo puede ser defendible cuando un requisito operativo concreto la exige y tienes controles compensatorios más fuertes que la comodidad. En la mayoría de los homelabs y pequeñas empresas, ese requisito no existe.

CVE-2023-54391 convierte una buena práctica abstracta en un modo de fallo concreto. Cuando falla la propia autenticación, la interfaz de gestión más segura es la que un atacante no puede alcanzar.