Proxmox CVE-2023-54391: ¿quién está en riesgo real?

CVE-2023-54391 es una vulnerabilidad grave que permite eludir la autenticación en Proxmox VE. Sin embargo, los titulares alarmistas de "actualiza Proxmox ya" omiten un detalle fundamental: muchas instalaciones de Proxmox VE 7 y 8 no son vulnerables.

El rango de paquetes afectado es libpve-access-control >= 7.0-7 and < 8.0.4. Esto corresponde aproximadamente a Proxmox VE 7.0 hasta 7.4 y a la versión inicial de Proxmox VE 8.0. La ruta de código vulnerable se eliminó el 20 de julio de 2023, mucho antes de que el problema recibiera un identificador CVE en septiembre de 2026. Si tu servidor cuenta con libpve-access-control 8.0.4 o superior, no hay motivos para entrar en pánico por este fallo específico.

Si todavía ejecutas Proxmox VE 7, la situación es más delicada. La rama habitual de PVE 7 nunca recibió este parche, y esa versión lleva mucho tiempo sin soporte oficial. Si su API de administración ha estado accesible desde redes no confiables, esto va más allá de un simple aviso rutinario. Un software de administración al final de su ciclo de vida expuesto a internet resulta muy peligroso, incluso si el fallo se solucionó hace años en versiones posteriores.

¿Qué hace exactamente CVE-2023-54391?

CVE-2023-54391 permite a un atacante no autenticado eludir la verificación de contraseña para cualquier usuario activo de Proxmox que no tenga configurado un segundo factor de autenticación.

El problema radica en el flujo de inicio de sesión que gestiona libpve-access-control. En un acceso normal a Proxmox, las credenciales se envían a la API de tickets de acceso. Si el segundo factor está habilitado, el servidor devuelve un desafío que debe completarse antes de generar la sesión.

La lógica vulnerable aceptaba solicitudes que incluían un campo tfa-challenge sin comprobar adecuadamente si el servidor había emitido ese desafío durante un primer paso de autenticación legítimo. Para una cuenta activa sin segundo factor, el atacante podía saltarse la contraseña y obtener un ticket de sesión válido. Esto incluye cuentas críticas como root@pam si están habilitadas y carecen de un segundo factor configurado.

VulnCheck clasifica el fallo como crítico con una puntuación CVSS 9.3 bajo CVSS 4.0. La puntuación CVSS 3.1 derivada del NVD alcanza 9.8. El ataque se ejecuta a través de la red, no requiere autenticación previa ni interacción del usuario, y puede provocar un impacto alto en confidencialidad, integridad y disponibilidad. Por tanto, este CVE merece máxima atención aunque el código vulnerable sea antiguo.

¿Qué versiones de Proxmox son realmente vulnerables?

Debes fijarte en la versión exacta del paquete, ya que el número general de versión de Proxmox VE no basta para saberlo. El aviso de Proxmox define el rango afectado como:

libpve-access-control >= 7.0-7 and < 8.0.4

El rango vulnerable equivale aproximadamente a:

• Proxmox VE 7.0 hasta 7.4
• la versión inicial de Proxmox VE 8.0

La corrección se introdujo en:

libpve-access-control 8.0.4

Ese paquete se publicó el 20 de julio de 2023, por lo que afirmar que "PVE 8 es vulnerable" resulta inexacto. Cualquier máquina que haya instalado actualizaciones habituales de PVE 8 después de julio de 2023 ya superó el paquete afectado. Un sistema con PVE 8.1, 8.2, 8.3, 8.4 o Proxmox VE 9 con actualizaciones al día no se ve afectado por este CVE. El propio boletín de Proxmox aclara que ninguna versión con soporte oficial de Proxmox VE está afectada.

A fecha de septiembre de 2026, Proxmox VE 8 también ha alcanzado el fin de su soporte, y PVE 9 es la rama principal con soporte activo. Esto plantea dos preguntas diferentes:

1. ¿Está presente este CVE concreto en la máquina?
2. ¿Sigue ejecutando el servidor una versión de Proxmox con soporte?

Un sistema con una revisión tardía de PVE 8 puede estar a salvo de CVE-2023-54391 y, al mismo tiempo, encontrarse en una versión mayor sin soporte que ya no recibe actualizaciones de seguridad habituales.

¿Cómo comprobar si tu host está afectado?

Revisa directamente el paquete libpve-access-control instalado. Un comando sencillo para hacerlo es:

dpkg-query -W libpve-access-control

Debes comprobar si la versión es anterior a 8.0.4 y posterior o igual a 7.0-7.

Una comprobación más explícita surgida en el debate técnico fue:

V=$(dpkg-query -W -f='${Version}' libpve-access-control 2>/dev/null)
echo "libpve-access-control: ${V:-not installed}"
dpkg --compare-versions "$V" lt 8.0.4   && echo ">>> AFFECTED"   || echo ">>> not affected"

Comparar la versión del paquete aporta más certeza que mirar si el host indica "PVE 8", ya que las versiones de los paquetes y las versiones mayores del sistema no se corresponden de forma exacta.

Si ya te encuentras en un sistema Proxmox VE 9 con soporte y parches al día, puedes descartar este CVE. Si encuentras una instalación antigua de PVE 7, ejecutar apt update && apt full-upgrade dentro de los repositorios de PVE 7 no resolverá el problema.

¿Por qué un host PVE 7 actualizado al máximo sigue siendo vulnerable?

Nadie sabía que el fallo representaba un riesgo de seguridad cuando se retiró el código. La lógica defectuosa desapareció durante el desarrollo rutinario en julio de 2023. Proxmox indicó que esta omisión de autenticación no se había detectado internamente ni había sido reportada en aquel momento, por lo que el cambio no se catalogó como parche de seguridad. Las correcciones de seguridad se evalúan para trasladarlas a ramas anteriores con soporte. Una reescritura de código habitual normalmente no se traslada si nadie sospecha que cierra una brecha crítica.

Cuando CVE-2023-54391 se publicó formalmente el 1 de septiembre de 2026, Proxmox VE 7 llevaba más de dos años sin soporte, y la rama estándar de paquetes de PVE 7 todavía conservaba la lógica vulnerable. Uno de los investigadores de seguridad recalcó precisamente esto: un host PVE 7 actualizado al máximo puede seguir afectado porque la corrección nunca entró en el canal de actualizaciones estándar de PVE 7.

Proxmox publicó un parche de emergencia para administradores que no pueden afrontar una actualización mayor de inmediato, pero la solución a largo plazo consiste en migrar fuera de PVE 7, y para eso no basta con instalar parches rutinarios: debes seguir la ruta oficial de actualización.

¿Se estaba explotando realmente este fallo en septiembre de 2026?

CrowdSec detectó tráfico coincidente con intentos de explotación, aunque eso no implica que cada petición causara un acceso indebido real. Su informe del 7 de septiembre indicó que 133 direcciones IP únicas habían enviado peticiones con el patrón del CVE desde el 4 de septiembre, fecha en que se activó su regla de detección. Esto constituye una prueba creíble de escaneos activos o intentos de explotación, pero no significa que hubiera 133 intrusiones confirmadas.

En cuanto se hace público un patrón de explotación, los escáneres automáticos barren rangos masivos de direcciones en busca de sistemas vulnerables. La mayoría de los servidores que sondean pueden estar parcheados, tras un cortafuegos o no ser explotables. En un host antiguo con el puerto 8006 expuesto a internet, el riesgo es evidente: una petición sencilla sin autenticar es justo lo que los escáneres detectan de inmediato.

Varios administradores en la comunidad relataron situaciones sospechosas en sistemas Proxmox antiguos, como contraseñas modificadas o servidores presuntamente comprometidos. A menos que un análisis forense vincule un incidente con este CVE, esos testimonios son solo anécdotas. La historia de intrusión de otra persona no demuestra que tu servidor haya sido vulnerado, pero si tenías un host vulnerable y accesible, es un motivo claro para investigar.

¿Protege la autenticación en dos pasos frente a este fallo?

Cambia las condiciones del ataque, pero no sustituye a una actualización del sistema.

La descripción del CVE señala que el atacante puede autenticarse como un usuario activo que no tenga configurado un segundo factor. Una cuenta con 2FA configurado correctamente no encaja en el caso vulnerable más directo del boletín, lo que aporta una defensa en profundidad muy útil. Con todo, eso no convierte en seguro a un hipervisor sin soporte.

Un host Proxmox puede albergar varios usuarios activos, tokens de API, cuentas de servicio e identidades administrativas. Si una sola cuenta útil carece de segundo factor, el atacante puede encontrar una puerta de entrada. Por eso la respuesta debe articularse en varias capas:

• actualizar o aplicar la mitigación de emergencia del proveedor
• retirar el acceso de administración de redes no confiables
• exigir MFA a todos los usuarios administrativos
• revisar y desactivar cuentas activas innecesarias
• restringir el acceso a la API y la interfaz web mediante políticas de red

Con esas capas operativas, un único despiste no define el resultado final.

¿Debería estar abierto a internet el puerto 8006 en algún caso?

Para casi cualquier despliegue habitual, la respuesta es no. La interfaz web de Proxmox y su API externa son atendidas por pveproxy, normalmente en el puerto TCP 8006. Esa consola permite crear, borrar, arrancar, detener, reconfigurar y abrir consolas en máquinas virtuales y contenedores. Es el plano de control, y tratarlo como una aplicación web pública cualquiera permite a los atacantes alcanzar uno de los servicios con más privilegios de tu infraestructura.

El mayor consenso del debate se centró en el diseño de la red de administración antes que en este CVE concreto. La mejor práctica consiste en situar las interfaces de gestión de Proxmox en una red o VLAN de administración dedicada, restringiendo qué equipos pueden llegar a ella. Los administradores remotos deben acceder mediante una VPN, un servidor de salto debidamente mantenido u otra capa de control de accesos.

La accesibilidad es el factor determinante. Si un escáner en internet no puede conectarse a la API de administración, una vulnerabilidad en una API no autenticada resulta mucho más difícil de explotar remotamente. A pesar de ello hay que seguir aplicando parches: la segmentación simplemente asegura que una vulnerabilidad desconocida deba superar otra barrera antes de convertirse en un incidente real.

Para más detalles sobre la plataforma y el diseño de redes, consulta el Mr.PlanB Proxmox hub.

¿Basta con tener una VLAN de administración?

No, porque una VLAN por sí sola no aplica restricciones de tráfico. Necesitas un segmento de administración complementado con reglas de cortafuegos que limiten quién puede acceder a él.

Los dispositivos de usuario comunes, equipos IoT, máquinas virtuales con servicios públicos, la red Wi-Fi de invitados y las cargas en DMZ no tienen motivo alguno para establecer conexiones con la interfaz de gestión de Proxmox. Un equipo de administración o un servidor de salto sí necesitarán acceso. Un sistema de monitorización requerirá acceso limitado a la API, y una herramienta de backup o automatización necesitará puntos finales específicos. Para todo lo demás, deniega el tráfico.

Un administrador explicó que su segmento de gestión no tiene enrutamiento salvo a través de una ruta administrativa controlada. Otro señaló que ni siquiera las redes internas de usuarios deberían ver las interfaces de administración por defecto. Ambas perspectivas van en la dirección correcta.

No asumas que internet es hostil y que tu red de área local es confiable. Un portátil comprometido, una aplicación web expuesta, un dispositivo IoT infectado o unas credenciales de VPN robadas pueden convertir una red interna en un vector de ataque. Aplica el principio de mínimo privilegio entre zonas de red igual que lo haces entre cuentas de usuario.

¿Qué hacer si un host afectado estuvo expuesto a internet?

Trátalo como un posible incidente de seguridad y no como una simple tarea de parcheo pendiente. Primero, corta el acceso. Si es posible, elimina de inmediato el acceso público al puerto 8006 mediante un cortafuegos, listas de control de acceso previas, acceso exclusivo por VPN o la red de administración, de modo que las redes no confiables no puedan comunicarse con el servidor.

A continuación, actualiza a una versión de Proxmox con soporte, o aplica las instrucciones del fabricante si los procesos de control de cambios impiden una actualización mayor inmediata. Después, investiga: revisa los usuarios activos y los ajustes de autenticación. Busca usuarios desconocidos, contraseñas cambiadas, tokens de API, claves autorizadas de SSH y modificaciones de configuración sin justificar. Analiza el historial de tareas de Proxmox y los registros del sistema en busca de acciones administrativas extrañas, e inspecciona reglas de cortafuegos, definiciones de almacenamiento, configuraciones de VMs, parámetros de backup y tareas programadas.

Renueva cualquier credencial que haya podido quedar expuesta. Si el servidor custodiaba secretos en los que confiaban invitados o sistemas externos, considera renovar también esos accesos. Si sospechas que se produjo una intrusión real, conserva los registros antes de limpiar el equipo.

En una omisión de autenticación, un atacante exitoso puede figurar como un administrador conectado desde la primera petición. La ausencia de intentos fallidos de inicio de sesión apenas aporta tranquilidad: si el host era vulnerable y estaba expuesto, la falta de una alerta evidente no demuestra que no haya ocurrido nada.

Un diagnóstico mediante Proxmox Health Check puede ayudar a detectar debilidades de configuración, pero una sospecha de compromiso exige respuesta a incidentes, algo que una simple revisión no cubre por sí sola.

¿Fue demasiado alarmista el aviso original de actualizar Proxmox ya?

La urgencia estaba justificada para ciertos entornos, pero omitir los detalles de las versiones distorsionó el mensaje. La vulnerabilidad es crítica: que un atacante no autenticado pueda convertirse potencialmente en root@pam sin saber la contraseña es un asunto muy serio, y el hecho de que CrowdSec observara tráfico de explotación tras la publicación del fallo merece atención.

Aun así, un administrador con PVE 9 actual o con una instalación posterior de PVE 8 debidamente actualizada no debería leer el titular y creer que su servidor acaba de heredar una vulnerabilidad de autenticación con tres años de antigüedad.

Una advertencia más adecuada sería: si utilizas PVE 7 o un sistema inicial con PVE 8.0 y una versión de libpve-access-control inferior a 8.0.4, revísalo de inmediato. Si ese servidor era accesible desde redes no confiables, analízalo ante un posible compromiso. Si utilizas una versión moderna de PVE con soporte, este CVE ya está resuelto en tu sistema. Esa formulación resulta menos sensacionalista y mucho más fácil de trasladar a la práctica.

Exponer el plano de administración importa más que este CVE concreto

CVE-2023-54391 resulta atípico porque salió a la luz pública años después de que el código afectado hubiera desaparecido de las versiones recientes de Proxmox. Muchos administradores actualizaron en su momento y eliminaron un fallo crítico de autenticación sin saberlo. Otros se quedaron en PVE 7 y permanecieron expuestos, también sin sospecharlo.

Nadie debería aplicar cada actualización en el segundo en que aparece, ya que los cambios de infraestructura exigen validación. Sin embargo, aplazar indefinidamente las actualizaciones mayores pasa factura a la seguridad, y exponer el plano de administración multiplica ese coste de forma considerable.

Mantén Proxmox en una versión con soporte oficial, aleja la interfaz de gestión de la internet pública, utiliza MFA y segmenta el tráfico administrativo. Antes de reaccionar con alarma a los titulares sobre vulnerabilidades, averigua la versión exacta de los paquetes que tienes instalados.

Si mantienes un hipervisor sin soporte con el argumento de que "lleva años funcionando sin problemas", recuerda que este CVE estuvo presente en sistemas antiguos durante años antes de que nadie supiera de su existencia, incluidos quienes decidieron no actualizar.