HPE corrige 72 fallos en Aruba AOS-8 y AOS-10; ocho puntúan 10.0
El advisory HPESBNW05162 corrige 72 fallos en AOS-8 y AOS-10, con ocho CVSS 10.0. Afecta controladores, gateways y AP; HPE publica versiones corregidas por rama y recomienda aislar la gestión.
HPE publicó el 22 de octubre el advisory HPESBNW05162 para AOS-8 y AOS-10, los sistemas que operan sus controladores, Mobility Conductors, gateways y puntos de acceso inalámbricos. El paquete corrige 72 vulnerabilidades; ocho tienen puntuación CVSS 3.1 de 10.0. Entre ellas hay bypass de autenticación y fallos que podrían permitir ejecución remota de comandos. No es un único fallo con 72 síntomas: es un conjunto amplio que toca rutas distintas de la infraestructura Aruba.
Qué puede fallar en AOS
Los ocho hallazgos de severidad máxima incluyen bypass de autenticación en interfaces y protocolos de AOS-8 y AOS-10, entre ellos el PAPI, protocolo de administración de puntos de acceso; también hay inyección de comandos, desbordamientos de búfer e inyección SQL. HPE indica que varios permiten a un atacante remoto no autenticado ejecutar comandos en el sistema subyacente, aunque algunos escenarios dependen de condiciones fuera del control del atacante. La puntuación 10.0 corresponde a ocho vulnerabilidades concretas, no a las 72 ni a todos los dispositivos de red de HPE.
Entre los ejemplos están CVE-2026-79844, un bypass que puede llevar a ejecución remota en AOS-10, y CVE-2026-79846, una inyección de comandos sin autenticar en AOS-8. CVE-2026-79855 afecta al daemon SSH de AOS-8 y permitiría saltarse autenticación hasta conseguir privilegios administrativos. Las rutas difieren por versión y servicio: agruparlas bajo “fallo del punto de acceso” puede ocultar que el controlador, el gateway o una interfaz de administración también forman parte del alcance.
-InfraCrew dice: Un AP en el inventario suele tener dueño; el servicio de gestión que quedó expuesto entre VLAN a veces solo tiene antigüedad.-
El advisory abarca Mobility Conductors, Mobility Controllers, Mobility Gateways gestionados por HPE Networking Central, puntos de acceso AOS-10 y puntos de acceso Instant AOS-8. En las ramas enumeradas, HPE considera afectadas las versiones hasta AOS-10.8.1.1, 10.7.2.6, 10.4.1.13, AOS-8.13.3.0 y 8.10.0.23, inclusive. Una versión que no aparezca en la lista no debe clasificarse por intuición: el fabricante dice que los productos y versiones no enumerados no están afectados por este aviso.
Parches y exposición de gestión
Las versiones corregidas son AOS-10.8.1.2, 10.7.2.7, 10.4.1.14, AOS-8.13.3.1 y 8.10.0.24 o posteriores dentro de la rama correspondiente. HPE recomienda aplicar las versiones indicadas y recuerda que las instalaciones en fin de mantenimiento se presumen afectadas salvo que el aviso indique lo contrario. Para software fuera de soporte, HPE no evaluó la exposición; la recomendación es tratarlo como potencialmente afectado y llevarlo a una versión soportada para poder valorar y corregir el riesgo.
La compañía no tenía constancia de debate público ni código de explotación para estas vulnerabilidades a la fecha de publicación del 22 de octubre. Eso describe lo que HPE conocía entonces; no equivale a una garantía sobre el estado posterior ni reduce la gravedad de una vía sin autenticación. No hay que convertir “sin explotación conocida” en “puede esperar” cuando el propio fabricante urge a parchear por amplitud e impacto.
-InfraCrew dice: “No hay PoC” es una observación con fecha; no es una ventana de mantenimiento.-
HPE también pide limitar las interfaces CLI y web de administración a un segmento de capa 2 dedicado o protegerlas mediante políticas de firewall de capa 3 en adelante, con registro de actividad y uso. La recomendación reduce la posibilidad de explotación mientras se organiza la actualización, pero no sustituye el parche ni justifica mantener la consola accesible desde redes de usuario. El plano de gestión merece una revisión propia: comprueba qué redes alcanzan los controladores y gateways, quién administra cada instalación y si los logs permiten detectar accesos anómalos.
Una actualización por familia y rama
Conviene inventariar primero los equipos que ejecutan AOS-8 o AOS-10 y anotar el rol, la versión exacta, la rama y el estado de soporte. Después, contrasta cada sistema con la tabla de HPE, planifica la actualización de acuerdo con la ruta soportada y restringe el acceso de gestión en el intervalo. No basta con actualizar un punto de acceso aislado si el conductor, controlador o gateway que gobierna la red permanece en una rama afectada.
Tras el cambio, verifica la versión que informa cada componente y que los puntos de acceso, la autenticación y las políticas de red siguen operativos. En despliegues con software EoM o EoS, deja registrada la incertidumbre del fabricante y prepara una ruta hacia una rama soportada; HPE no publica en este aviso una evaluación de exposición para EoS. La revisión de alcance y la evidencia posterior importan tanto como la ventana de cambio: la administración inalámbrica también es una consola privilegiada.
-InfraCrew dice: El firmware quedó actualizado es un buen titular; la tabla completa por rol y rama es lo que evita el “quedó” sin sujeto.-
Diccionario de la Crew
AOS — Sistema operativo de red inalámbrica de HPE Aruba para controladores, gateways y puntos de acceso.
PAPI — Protocolo de administración de puntos de acceso Aruba mencionado en varias vulnerabilidades.
EoM / EoS — Fin de mantenimiento / fin de soporte del software.
