Introducción
Si tu data center, campus universitario o red corporativa opera sobre switches ArubaOS-CX, tenés un problema concreto que resolver esta semana. HPE publicó el 2026 un boletín de seguridad que cierra CVE-2026-73749, un desbordamiento de búfer en un proceso daemon del sistema operativo que habilita ejecución remota de código con privilegios elevados sin necesidad de credenciales. No estamos hablando de un ataque que requiere phishing ni acceso previo a la red: basta con enviar paquetes malformados al servicio vulnerable desde cualquier punto con alcance IP al switch. Para equipos de infraestructura que gestionan cientos o miles de puertos en entornos de misión crítica —hospitales, organismos gubernamentales, proveedores de servicios—, este tipo de vector de ataque convierte un switch en un pivote hacia el resto de la red segmentada.
Qué ocurrió
HPE identificó múltiples vulnerabilidades en un daemon de ArubaOS-CX que procesa de forma incorrecta entradas malformadas. El boletín oficial describe el escenario así: un atacante remoto no autenticado puede explotar el defecto enviando paquetes especialmente construidos al servicio afectado, desbordando un búfer en memoria y obteniendo ejecución de código con permisos elevados dentro del proceso daemon. El CVE asignado es CVE-2026-73749, clasificado como severidad crítica por el propio vendor.
El parche no se limita a este único flaw. El mismo boletín de seguridad aborda 23 vulnerabilidades adicionales distribuidas entre distintas ramas de ArubaOS-CX, con puntajes CVSS que oscilan entre 8.1 y 8.8. Esto indica que HPE aprovechó un ciclo de publicación para cerrar un conjunto amplio de defectos, lo que sugiere una revisión profunda del código del daemon afectado y de componentes adyacentes. Al momento de la publicación del boletín, HPE declaró no tener conocimiento de explotación activa ni de exploits de prueba de concepto públicos dirigidos a estas vulnerabilidades. Esa ausencia no reduce la urgencia: el tiempo entre la divulgación y la aparición de un PoC en foros ofensivos suele medirse en días, no semanas.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
ArubaOS-CX no corre en un servidor aislado. Opera sobre switches empresariales de HPE Aruba Networking que forman la capa de conmutación en campus de universidades, redes de salud, edificios gubernamentales, centros de datos y redes de proveedores de servicios. Si un atacante compromete un switch ArubaOS-CX con privilegios elevados, obtiene visibilidad y control sobre el tráfico L2/L3 que atraviesa ese equipo. Eso incluye VLANs de gestión, tráfico hacia firewalls, enlaces a gateways VPN corporativos y, en arquitecturas híbridas, conexiones dedicadas hacia entornos AWS o Azure vía Direct Connect o ExpressRoute.
Para equipos de SRE y plataforma que dependen de switches Aruba como parte de la infraestructura de red subyacente a cargas de trabajo cloud, el riesgo se multiplica. Un switch comprometido puede redirigir tráfico, interceptar sesiones TLS mediante técnicas de downgrade, o inyectar rutas BGP internas que desvíen flujos hacia hosts del atacante. En entornos donde la gestión de la red se expone a través de interfaces web o APIs REST sobre la misma red de datos, el vector de ataque se amplifica. Además, la rama 10.10.1181 entró en estado End of Maintenance (EOM): solo recibe correcciones para issues críticos descubiertos internamente por HPE. Si tu inventario incluye equipos en esa rama, el parche para CVE-2026-73749 llega, pero no tenés garantía de cobertura para futuros hallazgos.
Detalles técnicos
El componente afectado es un daemon de ArubaOS-CX que procesa paquetes de red. El mecanismo de explotación es un buffer overflow clásico: el daemon no valida correctamente la longitud o estructura de ciertos campos en paquetes entrantes, lo que permite sobrescribir memoria adyacente y redirigir el flujo de ejecución hacia código inyectado. El ataque no requiere autenticación previa; el paquete malformado se envía directamente al puerto o servicio del daemon expuesto en la red de gestión o en la red de datos del switch.
Las ramas afectadas y las versiones con corrección están listadas en el boletín de HPE. La versión 10.10.1181 está en EOM y recibe este fix como excepción por ser un issue crítico, pero cualquier otra vulnerabilidad descubierta en esa rama no tendrá parche. Las 23 vulnerabilidades adicionales del boletín incluyen fallas con CVSS 8.1, 8.4, 8.6 y 8.8, lo que apunta a problemas de validación de entrada, manejo de memoria y control de acceso en distintos módulos del sistema operativo.
Para verificar la versión instalada en un switch ArubaOS-CX:
ssh admin@switch-ip
switch# show version
El output incluye la rama de release y el build exacto. Comparar contra la tabla de versiones parcheadas del boletín es el primer paso no negociable. Para identificar si el daemon vulnerable está expuesto en la red de gestión:
switch# show system interface
switch# show ip interface brief
Revisar que los servicios de gestión no estén escuchando en interfaces expuestas a redes no confiables.
Qué deberían hacer los administradores y equipos técnicos
Primero: inventariar y priorizar. Generar un listado de todos los switches ArubaOS-CX en producción, con versión, rama y ubicación física. Cruzar contra la tabla de versiones afectadas del boletín de HPE. Priorizar equipos expuestos a la red pública, switches en bordes de red de data centers y equipos que gestionan VLANs de servidores críticos o enlaces a nubes públicas.
Segundo: aplicar el parche. HPE «alienta fuertemente» la actualización a las versiones fix listadas. El procedimiento estándar en ArubaOS-CX:
switch# install image arubaos-cx-10.x.xxxx.sw primary
switch# install commit
switch# reload
Ejecutar en una ventana de mantenimiento. Para redes con MLAG o stacking, actualizar los switches de uno en uno para mantener redundancia. Antes de aplicar, respaldar la configuración:
switch# copy startup-config scp://backup-server/configs/switch-name.cfg
Tercero: mitigar si no podés parchar de inmediato. Restringir el acceso a la red de gestión de los switches mediante ACLs que limiten las fuentes IP permitidas a subnets de administración específicas. Deshabilitar servicios no necesarios en interfaces expuestas. Si la arquitectura lo permite, colocar los switches detrás de un firewall que inspeccione tráfico hacia el puerto del daemon vulnerable. Para entornos con conectividad a AWS o nubes públicas, revisar que las conexiones Direct Connect o Site-to-Site VPN no atraviesen switches ArubaOS-CX sin segmentación adicional.
Cuarto: monitorear. Configurar alertas en el SIEM por tráfico anómalo hacia los puertos de gestión de los switches. Revisar logs del daemon post-parche para descartar intentos de explotación previos. Si detectás paquetes malformados recurrentes, tratá el evento como un incidente de seguridad, no como ruido de red.
Conclusión
CVE-2026-73749 es un recordatorio concreto de que la capa de red sigue siendo un objetivo de primera línea. Un switch con RCE sin autenticación no es un problema de «la red del otro»: en arquitecturas modernas donde la red subyace a cargas cloud, contenedores y flujos de datos entre regiones, la superficie de ataque de un daemon mal parcheado llega más lejos de lo que el equipo de networking suele dimensionar. El parche existe, la ventana de exposición es ahora, y la rama 10.10.1181 no tiene futuro en términos de soporte. La pregunta no es si vas a actualizar, sino cuánto tiempo más vas a correr el riesgo.
Fuentes
- https://www.bleepingcomputer.com/news/security/hpe-patches-critical-arubaos-cx-remote-code-execution-flaw/