Trece de los veintiocho fallos de ClearPass están en el agente, no en el servidor

La mitigación provisional que trae el aviso de HPE cabe en una frase y nombra dos cosas: la CLI y la interfaz web de gestión. Las dos están en el servidor. Trece de las veintiocho vulnerabilidades del mismo aviso, no.

El aviso es el HPESBNW05158 rev.1, «Multiple Vulnerabilities in HPE Networking ClearPass Policy Manager (CPPM)», con fecha de publicación del 6 de octubre de 2026. Son 28 CVE: diez críticas, once altas y siete medias. Las encontró, en su mayoría, la investigación interna de HPE Networking —el aviso dice «generally», y hay una, la CVE-2026-79811, acreditada a su programa de bug bounty—, que es el mejor escenario posible para una lista así. A fecha del aviso, HPE dice que no tiene constancia de discusión pública ni de código de explotación, y acto seguido pide parchear ya «due to the complexity, breadth, and impact of these vulnerabilities».

ClearPass Policy Manager es un NAC: el que decide si un puerto de switch o un SSID te dejan entrar, y con qué VLAN y qué permisos. Es el servidor RADIUS al que preguntan los switches y los puntos de acceso. Si nunca has tocado uno, el equivalente mental es el portero: no guarda nada valioso, solo dice sí o no, y por eso casi nadie lo cuenta entre los sistemas críticos hasta que deja de decir una de las dos cosas.

Las versiones afectadas, tal cual las lista el aviso: CPPM 6.14.0 and below y CPPM 6.11.15 and below. Las corregidas: 6.14.1 and above y 6.11.16 and above. Guárdate esas cuatro líneas, porque más abajo deciden si lo tuyo es un parche o una migración.

La frase del workaround, entera

To minimize the likelihood of an attacker exploiting these
vulnerabilities, HPE Networking recommends that the
CLI and web-based management interfaces be restricted to a
dedicated layer 2 segment/VLAN and/or controlled by firewall
policies at layer 3 and above along with accounting controls
for tracking and logging user activities and resource usage.

Es un buen consejo y lo firmaríamos sin cambiar una coma. Higiene del plano de gestión de toda la vida: la administración no vive en la red de usuarios, se le pone un cortafuegos delante y se registra quién entra. Lo hemos defendido aquí mismo cuando el agujero estaba en la consola de administración de otro fabricante, y seguimos.

Lo que hace esa frase es dibujar un perímetro alrededor de una máquina. La CLI está en la máquina. La interfaz web de gestión está en la máquina. Un segmento de nivel 2 dedicado protege la máquina. Y el aviso que contiene esa frase reparte sus veintiocho fallos entre esa máquina y otro sitio.

El recuento, y el criterio con el que está hecho

Hemos clasificado los veintiocho por el componente que HPE nombra en el título de cada vulnerabilidad. Si el título dice OnGuard Agent, Client Agent, Client Software, Android Client Application o Client Interface, va al lado del cliente. El resto, al lado del servidor. El criterio es nuestro y es discutible —algún fallo del servidor se dispara desde un cliente y al revés—, pero tiene la virtud de que lo puedes rehacer tú mismo con el aviso abierto. Salen trece al lado del cliente y quince al del servidor.

Un detalle que ayuda a cuadrar la lista si la rehaces: los identificadores no vienen correlativos. Hay un bloque corto en la serie CVE-2026-767xx y otro mucho más largo en la CVE-2026-79xxx, que arranca en la CVE-2026-79794 y tiene dos huecos dentro, la 79795 y la 79804, que no son de este aviso. La forma rápida de saber si te has dejado alguna es cuadrar tu recuento contra el reparto que el propio aviso declara: diez, once y siete.

Dos de esas trece son 9,8 y no piden credenciales

La descripción de la CVE-2026-76751 dice dónde cae el código, y conviene leerla despacio porque la palabra que importa está al final: «Successful exploitation could allow an unauthenticated, remote attacker to execute arbitrary code on the affected endpoint with the elevated privileges of the agent». En el endpoint. Con los privilegios del agente, que son los que necesita un agente de postura para mirarte el antivirus y el cifrado de disco, o sea, altos.

CVE-2026-76751
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Por red, complejidad baja, sin privilegios previos y sin que nadie tenga que hacer clic en nada. La CVE-2026-79801 es de la misma familia —verificación de integridad que falta en el agente cliente— y lleva el mismo vector. Ninguna de las dos pasa por la interfaz web de gestión, así que ninguna de las dos se frena poniendo esa interfaz en su VLAN. El workaround es correcto para lo que nombra. Lo que no alcanza son esas trece, y conviene añadir un matiz incómodo sobre las quince restantes: cuatro están en la API (79803, 79809, 79811 y 79818) y la 9,8 de format string, la 76753, el aviso la sitúa en «an affected service interface», sin decir cuál. Dar por hecho que segmentar la web de gestión las tapa todas es una suposición tuya, no una afirmación de HPE.

Dónde está el agente (la respuesta no es «en la LAN»)

OnGuard es el agente de postura de ClearPass. La documentación de HPE describe el persistente como un programa que se instala en el equipo final, corre en segundo plano y reporta periódicamente su estado de salud al servicio de comprobación del Policy Manager. Lo que comprueba es una lista larga —antivirus, cortafuegos, parches, cifrado de disco, dispositivos USB, procesos— y para comprobar todo eso hace falta estar dentro del sistema operativo, no mirándolo desde fuera.

Eso cambia la lista de activos de este aviso. El activo es el appliance y además cada portátil de la plantilla que lleve el agente instalado, incluidos los que esta semana están en casa de alguien o en la oficina de un cliente. La CVE-2026-79797 es la más incómoda de las trece por una razón de inventario muy concreta: es la aplicación cliente de Android, y una app que alguien se instaló a mano en su móvil no aparece en ningún informe de software instalado del parque.

La 6.12 y la nota que casi nadie lee

El aviso corrige en dos ramas y solo en dos: 6.14.1 y 6.11.16. Pero las ramas publicadas de ClearPass no son dos. La 6.12 existe, está desplegada, y cae dentro del «CPPM 6.14.0 and below» que el aviso declara afectado — y no tiene versión corregida en esta lista. Para ese caso la respuesta no está en la tabla de versiones, está en una nota del apartado de resolución que es fácil pasar por alto:

NOTE: Product software versions that have reached End of
Maintenance (EoM) are presumed to be affected by the
vulnerabilities unless explicitly stated otherwise and are
not covered by this security advisory. For deployments
running software versions that are past End of Support
(EoS), HPE Networking has not assessed exposure to the
vulnerabilities referenced in this advisory. As a result,
such installations should be considered potentially impacted
by the listed CVE. Customers are strongly encouraged to
upgrade to a supported software release to ensure proper
evaluation and remediation.

Leído con calma, eso dice dos cosas distintas. Si tu rama está en fin de mantenimiento, se te presume afectado y este aviso no va a decirte nada más. Si está pasada de fin de soporte, HPE directamente no ha mirado. En los dos casos tu trabajo deja de ser una ventana de cambio para aplicar un parche y pasa a ser planificar un salto de rama, con sus pruebas de políticas, su validación de los perfiles y su marcha atrás preparada. Es la diferencia entre una tarea de mantenimiento y un proyecto pequeño, y descubrirla el martes por la tarde es peor que descubrirla hoy. El primer paso, por tanto, no es el parche: es mirar en qué rama estás y comprobar en el ciclo de vida de HPE si sigue en mantenimiento.

La pregunta que el aviso no hace

Si tu ClearPass es un appliance solo, para parchearlo hay que pararlo. En clúster rueda nodo a nodo y no se nota, siempre que los switches y las controladoras tengan más de un servidor RADIUS configurado — y eso es justo lo que conviene comprobar antes, no durante. En cualquiera de los dos casos hay un rato en el que el que dice sí o no a un puerto o a una asociación de wifi puede no estar, y ahí la pregunta deja de ser de seguridad y pasa a ser de arquitectura: ¿qué hace tu red cuando el RADIUS no contesta?

Hay tres estados posibles y solo dos se eligen a propósito. El primero: si en la plantilla de los switches no hay nada escrito para ese caso, un puerto cuyo servidor de autenticación no responde no se autoriza. El segundo: si alguien previó el escenario, está escrito. En la documentación de Cisco esa previsión tiene nombre y comando —la autenticación crítica, con authentication event server dead action authorize vlan vlan-id— y lo que hace es autorizar el puerto en una VLAN que tú elegiste, con el acceso que tú decidiste, mientras el servidor no esté. Y el tercero, el que casi nadie recuerda haber configurado: authentication open, el puerto abierto de par en par, que se dejó así durante el despliegue para que nadie se quedara fuera y ahí sigue.

Conviene un matiz antes de dramatizar: las sesiones ya autenticadas suelen sobrevivir a una caída corta del servidor, así que lo que se rompe primero son las conexiones nuevas y las reautenticaciones. El que llega a las nueve y enchufa el portátil lo nota; el que ya estaba dentro, no. Esto hace que el escenario sea más traicionero, no menos: el impacto depende de a qué hora tocaste y de cada cuánto reautentica tu red, dos cosas que nadie mira antes de pedir la ventana.

El fallo es inevitable, la avería es una decisión de diseño. El NAC se va a caer alguna vez, por un parche o por lo que sea; que al caerse la empresa deje de trabajar, que entre todo el mundo sin preguntas, o que los portátiles queden en una VLAN de contingencia con acceso al ERP y a nada más, es una decisión que alguien tomó o dejó de tomar. Esto ya lo contamos en septiembre con otro NAC y otro aviso, y lo repetimos aquí porque el aviso de HPE vuelve a poner la fecha de la ventana encima de la mesa. Con otras piezas tiene la misma forma: un certificado que caduca y tumba la VPN es un problema de qué nadie escribió para el día que esa pieza falte, y un túnel entre sedes que no le pide el segundo factor a nadie, también. Cambia el componente, no cambia el hueco.

El orden en que lo haríamos

Lo que no afirmamos

Con una consola, un parque de portátiles pequeño y un gestor de endpoints que funcione, esto lo saca tu gente sin ayuda: la versión está en una pantalla y el censo del agente en un informe. Se complica cuando la red lleva años creciendo por capas —switches de tres generaciones, un wifi que montó un proveedor que ya no está, plantillas de puerto que nadie ha vuelto a leer— y la pregunta del punto 5 no tiene respuesta escrita. Ese trabajo, el de dejar la red documentada y con el comportamiento de fallo decidido a propósito, es el de redes y comunicaciones, y el de ponerle criterio a un salto de rama que nadie quiere firmar es el de consultoría. Las dos cosas las vendemos, así que léelo con el conflicto de interés por delante. Si tu gente ya tiene las dos respuestas, perfecto. Si al llegar al punto 5 has mirado para otro lado, hablémoslo.

Fuentes