Tretze dels vint-i-vuit errors de ClearPass són a l'agent, no al servidor

La mitigació provisional que porta l'avís d'HPE cap en una frase i anomena dues coses: la CLI i la interfície web de gestió. Totes dues són al servidor. Tretze de les vint-i-vuit vulnerabilitats del mateix avís, no.

L'avís és el HPESBNW05158 rev.1, «Multiple Vulnerabilities in HPE Networking ClearPass Policy Manager (CPPM)», amb data de publicació del 6 d'octubre del 2026. Són 28 CVE: deu crítiques, onze altes i set mitjanes. Les va trobar, majoritàriament, la investigació interna d'HPE Networking —l'avís diu «generally», i n'hi ha una, la CVE-2026-79811, acreditada al seu programa de bug bounty—, que és el millor escenari possible per a una llista així. A data de l'avís, HPE diu que no té constància de discussió pública ni de codi d'explotació, i tot seguit demana pedaçar ja «due to the complexity, breadth, and impact of these vulnerabilities».

ClearPass Policy Manager és un NAC: el que decideix si un port de switch o un SSID et deixen entrar, i amb quina VLAN i quins permisos. És el servidor RADIUS a qui pregunten els switches i els punts d'accés. Si no n'has tocat mai cap, l'equivalent mental és el porter: no guarda res valuós, només diu sí o no, i per això gairebé ningú no el compta entre els sistemes crítics fins que deixa de dir una de les dues coses.

Les versions afectades, tal com les llista l'avís: CPPM 6.14.0 and below i CPPM 6.11.15 and below. Les corregides: 6.14.1 and above i 6.11.16 and above. Guarda't aquestes quatre línies, perquè més avall decideixen si el teu cas és un pedaç o una migració.

La frase del workaround, sencera

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.

És un bon consell i el signaríem sense canviar-hi una coma. Higiene del pla de gestió de tota la vida: l'administració no viu a la xarxa d'usuaris, se li posa un tallafoc al davant i es registra qui hi entra. Ho hem defensat aquí mateix quan el forat era a la consola d'administració d'un altre fabricant, i continuem.

El que fa aquesta frase és dibuixar un perímetre al voltant d'una màquina. La CLI és a la màquina. La interfície web de gestió és a la màquina. Un segment de nivell 2 dedicat protegeix la màquina. I l'avís que conté aquesta frase reparteix els seus vint-i-vuit errors entre aquesta màquina i un altre lloc.

El recompte, i el criteri amb què està fet

Hem classificat els vint-i-vuit pel component que HPE anomena al títol de cada vulnerabilitat. Si el títol diu OnGuard Agent, Client Agent, Client Software, Android Client Application o Client Interface, va al costat del client. La resta, al costat del servidor. El criteri és nostre i és discutible —algun error del servidor es dispara des d'un client i a l'inrevés—, però té la virtut que el pots refer tu mateix amb l'avís obert. Surten tretze al costat del client i quinze al del servidor.

Un detall que ajuda a quadrar la llista si la refàs: els identificadors no vénen correlatius. Hi ha un bloc curt a la sèrie CVE-2026-767xx i un altre molt més llarg a la CVE-2026-79xxx, que arrenca a la CVE-2026-79794 i té dos buits a dins, la 79795 i la 79804, que no són d'aquest avís. La manera ràpida de saber si te n'has deixat alguna és quadrar el teu recompte amb el repartiment que el mateix avís declara: deu, onze i set.

Dues d'aquestes tretze són 9,8 i no demanen credencials

La descripció de la CVE-2026-76751 diu on cau el codi, i convé llegir-la a poc a poc perquè la paraula que importa és 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». A l'endpoint. Amb els privilegis de l'agent, que són els que necessita un agent de postura per mirar-te l'antivirus i el xifratge de disc, és a dir, alts.

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

Per xarxa, complexitat baixa, sense privilegis previs i sense que ningú hagi de clicar res. La CVE-2026-79801 és de la mateixa família —verificació d'integritat que falta a l'agent client— i porta el mateix vector. Cap de les dues passa per la interfície web de gestió, així que cap de les dues es frena posant aquesta interfície a la seva VLAN. El workaround és correcte per al que anomena. El que no abasta són aquestes tretze, i convé afegir un matís incòmode sobre les quinze restants: quatre són a l'API (79803, 79809, 79811 i 79818) i la 9,8 de format string, la 76753, l'avís la situa en «an affected service interface», sense dir quina. Donar per fet que segmentar la web de gestió les tapa totes és una suposició teva, no una afirmació d'HPE.

On és l'agent (la resposta no és «a la LAN»)

OnGuard és l'agent de postura de ClearPass. La documentació d'HPE descriu el persistent com un programa que s'instal·la a l'equip final, corre en segon pla i reporta periòdicament el seu estat de salut al servei de comprovació del Policy Manager. El que comprova és una llista llarga —antivirus, tallafoc, pedaços, xifratge de disc, dispositius USB, processos— i per comprovar tot això cal ser dins del sistema operatiu, no mirar-lo des de fora.

Això canvia la llista d'actius d'aquest avís. L'actiu és l'appliance i a més cada portàtil de la plantilla que porti l'agent instal·lat, inclosos els que aquesta setmana són a casa d'algú o a l'oficina d'un client. La CVE-2026-79797 és la més incòmoda de les tretze per una raó d'inventari molt concreta: és l'aplicació client d'Android, i una app que algú es va instal·lar a mà al seu mòbil no apareix en cap informe de programari instal·lat del parc.

La 6.12 i la nota que gairebé ningú no llegeix

L'avís corregeix en dues branques i només en dues: 6.14.1 i 6.11.16. Però les branques publicades de ClearPass no són dues. La 6.12 existeix, està desplegada, i cau dins del «CPPM 6.14.0 and below» que l'avís declara afectat — i no té versió corregida en aquesta llista. Per a aquest cas la resposta no és a la taula de versions, és en una nota de l'apartat de resolució que és fàcil passar per alt:

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.

Llegit amb calma, això diu dues coses diferents. Si la teva branca és en fi de manteniment, se't presumeix afectat i aquest avís no et dirà res més. Si està passada de fi de suport, HPE directament no ho ha mirat. En els dos casos la teva feina deixa de ser una finestra de canvi per aplicar un pedaç i passa a ser planificar un salt de branca, amb les seves proves de polítiques, la seva validació dels perfils i la seva marxa enrere preparada. És la diferència entre una tasca de manteniment i un projecte petit, i descobrir-ho dimarts a la tarda és pitjor que descobrir-ho avui. El primer pas, doncs, no és el pedaç: és mirar en quina branca ets i comprovar al cicle de vida d'HPE si continua en manteniment.

La pregunta que l'avís no fa

Si el teu ClearPass és un appliance sol, per pedaçar-lo cal aturar-lo. En clúster roda node a node i no es nota, sempre que els switches i les controladores tinguin més d'un servidor RADIUS configurat — i això és justament el que convé comprovar abans, no durant. En qualsevol dels dos casos hi ha una estona en què el que diu sí o no a un port o a una associació de wifi pot no ser-hi, i aleshores la pregunta deixa de ser de seguretat i passa a ser d'arquitectura: què fa la teva xarxa quan el RADIUS no contesta?

Hi ha tres estats possibles i només dos es trien expressament. El primer: si a la plantilla dels switches no hi ha res escrit per a aquest cas, un port el servidor d'autenticació del qual no respon no s'autoritza. El segon: si algú va preveure l'escenari, està escrit. A la documentació de Cisco aquesta previsió té nom i ordre —l'autenticació crítica, amb authentication event server dead action authorize vlan vlan-id— i el que fa és autoritzar el port en una VLAN que tu vas triar, amb l'accés que tu vas decidir, mentre el servidor no hi sigui. I el tercer, el que gairebé ningú no recorda haver configurat: authentication open, el port obert de bat a bat, que es va deixar així durant el desplegament perquè ningú no es quedés fora i encara hi continua.

Convé un matís abans de dramatitzar: les sessions ja autenticades acostumen a sobreviure a una caiguda curta del servidor, així que el que es trenca primer són les connexions noves i les reautenticacions. Qui arriba a les nou i endolla el portàtil ho nota; qui ja era a dins, no. Això fa que l'escenari sigui més trampós, no menys: l'impacte depèn de a quina hora vas tocar i de cada quant reautentica la teva xarxa, dues coses que ningú no mira abans de demanar la finestra.

La fallada és inevitable, l'avaria és una decisió de disseny. El NAC caurà alguna vegada, per un pedaç o pel que sigui; que en caure l'empresa deixi de treballar, que hi entri tothom sense preguntes, o que els portàtils quedin en una VLAN de contingència amb accés a l'ERP i a res més, és una decisió que algú va prendre o va deixar de prendre. Això ja ho vam explicar al setembre amb un altre NAC i un altre avís, i ho repetim aquí perquè l'avís d'HPE torna a posar la data de la finestra damunt la taula. Amb altres peces té la mateixa forma: un certificat que caduca i tomba la VPN és un problema de què ningú no va escriure per al dia que aquesta peça falti, i un túnel entre seus que no demana el segon factor a ningú, també. Canvia el component, no canvia el buit.

L'ordre en què ho faríem

El que no afirmem

Amb una consola, un parc de portàtils petit i un gestor d'endpoints que funcioni, això ho treu la teva gent sense ajuda: la versió és en una pantalla i el cens de l'agent en un informe. Es complica quan la xarxa fa anys que creix per capes —switches de tres generacions, un wifi que va muntar un proveïdor que ja no hi és, plantilles de port que ningú no ha tornat a llegir— i la pregunta del punt 5 no té resposta escrita. Aquesta feina, la de deixar la xarxa documentada i amb el comportament de fallada decidit expressament, és la de xarxes i comunicacions, i la de posar criteri a un salt de branca que ningú no vol signar és la de consultoria. Les dues coses les venem, així que llegeix-ho amb el conflicte d'interès al davant. Si la teva gent ja té les dues respostes, perfecte. Si en arribar al punt 5 has mirat cap a una altra banda, parlem-ne.

Fonts