Modulos de hardware de red en fila con haces de luz entre ellos

Últimas vulnerabilidades: Ivanti, Cisco, Palo Alto y ahora BeyondTrust en la mira

octubre 20, 2026 Alfonso Moreno | Sysadmin Senior 5 Visitas 17 min de lectura

Entre el 13 y el 16 de octubre de 2026, en menos de una semana, cuatro vendors de equipos de borde (firewalls, VPN gateways, gateways de correo y herramientas de soporte remoto) confesaron haber sido comprometidos o tener vulnerabilidades explotadas activamente. No es un mes particularmente malo: es la confirmación de un patrón que llevaba meses gestándose. En este artículo recopilo lo publicado por Dark Reading, los avisos oficiales de CISA y los reportes de Mandiant/GTIG, y lo traduzco a un plan de triage que aplica a cualquier sysadmin que tenga alguno de estos appliances en producción.

El ángulo es operativo, no periodístico. Si tienes un BeyondTrust Remote Support, un Ivanti Connect Secure, un Cisco Secure Email Gateway o un firewall con PAN-OS, aquí encuentras la versión vulnerable, el comando para verificar tu build, y qué hacer en las próximas 24 horas. Sin voseo rioplatense, sin clickbait, sin frases como “te va a volar la cabeza”. Lo que hay aquí lo podrías haber escrito tú mismo después de leer los advisories — lo armé para no tener que re-leer cinco PDFs distintos cada vez que aparece un CVE de borde.

TL;DR — Lo que vas a tener al final

Tiempo de lectura: 8-12 minutos para entender el patrón; 1-2 horas para ejecutar el triage completo en tu entorno.
Requisitos: acceso SSH/admin al menos a uno de estos productos — BeyondTrust Remote Support, Ivanti Connect Secure, Cisco Secure Email Gateway o un firewall Palo Alto — y un cuaderno donde anotar builds.
Resultado: lista concreta de CVEs activos, comandos para identificar si estás en una build vulnerable, y orden de remediación priorizado por probabilidad de explotación real, no solo por score.
Troubleshooting común: el patch de BeyondTrust (BT26-05) requiere redeploy desde imagen limpia si hay evidencia de compromiso — no basta con upgrade in-place; en Ivanti, el chain requiere show version exacto, no aproximado.

Por qué importa: la semana en la que cuatro vendors de borde cayeron juntos

El 13 de octubre, Volexity publicó que un actor no identificado llevaba semanas abusando de un chain de vulnerabilidades en Ivanti Connect Secure (ICS), incluso en appliances con el último parche disponible. El 14 de octubre, CISA añadió dos CVEs más a su catálogo KEV (Known Exploited Vulnerabilities): uno contra Cisco SEG y otro contra Palo Alto PAN-OS. El 15 de octubre, GreyNoise describió a skynox7, un actor que arma redes residenciales de proxies a partir de appliances expuestos y sin parchear. El 16 de octubre, BeyondTrust publicó el aviso BT26-05: un zero-day (CVE-2026-102764, CVSS 9.3) llevaba siendo explotado como arma desde el 29 de agosto por un actor atribuido a China, Mandiant/GTIG lo llaman Armory Castle (también conocido como UNC5221 o UTA0178).

El problema no es que aparezcan CVEs en appliances de borde — eso pasa cada semana. Lo nuevo es la convergencia: cuatro vendors distintos, en cinco días, con evidencia de explotación real, y al menos uno (BeyondTrust) llevaba casi siete semanas siendo explotado antes de que el vendor lo supiera. El propio John Bambenek, presidente de Bambenek Consulting, lo resumió con claridad: “estas vulnerabilidades en dispositivos de red o que manejan gran parte de la IT de una organización pasan cada mes más o menos. Las empresas tienen que ponerse de pie al unísono y decirle a estos vendors que ya es hora de tomarse la seguridad en serio.”

BeyondTrust CVE-2026-102764: el zero-day que llevaba semanas siendo explotado

BeyondTrust sirve a más de 20.000 clientes según su propio marketing, incluyendo 75 del Fortune 100. Remote Support es su appliance para que equipos de helpdesk se conecten remotamente a equipos de usuarios finales. El 29 de agosto, alguien empezó a explotarlo como zero-day. El patch no estuvo listo hasta el 9 de octubre, y la revelación pública (vía Mandiant/GTIG) llegó el 15 de octubre. Once días entre el parche y la divulgación es razonable; lo que preocupa son los 41 días entre el inicio de la explotación y el parche.

El CVE-2026-102764 (CVSS 9.3) reside en un componente interno de mensajería que no validaba el origen de los mensajes entrantes. En términos prácticos: el atacante podía enviar mensajes al componente que parecían venir de un proceso interno, y el componente los procesaba sin verificar. Esto le permitió desplegar un webshell PHP personalizado al que Mandiant llamó SAWFLY, en solo 11 minutos después de weaponizar el bug. Más tarde desplegó BARECLAW, una herramienta de tunelización SOCKS5 para mantener persistencia y extraer datos sin levantar alertas.

La cadena de post-explotación fue quirúrgica. Primero, Armory Castle fue directo a la base de datos interna de gestión de secretos del appliance (donde se almacenan passwords, API keys y credenciales de endpoint), hizo dump completo y escaló de una cuenta de servicio a admin. Después borró logs del sistema, del web server y de la aplicación para combatir al analista forense, y estableció persistencia vía script. Finalmente lanzó sesiones remotas contra sistemas downstream, hizo reconocimiento de red interno y descargó documentos sensibles de los escritorios de las víctimas.

Cómo verificar tu versión de BeyondTrust Remote Support

BeyondTrust publicó BT26-05 con el detalle. El endpoint para verificar la versión de Remote Support on-premise es el panel de administración web (puerto por defecto 443) en /appliance. La versión parcheada mínima es la 25.2.4. Si tu instancia quedó expuesta entre el 29 de agosto y el 9 de octubre, la guía oficial recomienda tratarla como comprometida aunque el upgrade se aplique sin incidentes visibles.

Ivanti Connect Secure CVE-2026-104935: el chain que Volexity descubrió

El 13 de octubre, los investigadores de Volexity revelaron que un actor no identificado había estado abusando de un chain de zero-days en Ivanti Connect Secure, incluso en appliances con el último firmware disponible. El chain combinaba tres de las peores clases de vulnerabilidad: bypass de autenticación, ejecución remota de código (RCE) y escalada de privilegios. Los dos primeros están trackeados juntos como CVE-2026-104935, con CVSS 8.6.

La gravedad no es solo técnica sino operacional: Volexity publicó que el actor mantuvo acceso en algunos entornos durante semanas antes de que el parche estuviera listo. Este patrón es consistente con cómo actores chinos han tratado appliances de Ivanti en el pasado: el actor UNC5221 (ahora renombrado como Armory Castle/UTA0178 por Mandiant) tiene un historial extenso contra Ivanti desde 2024, incluyendo CVE-2024-21762, CVE-2025-0282 y CVE-2026-0282. Si tienes un ICS, asumir que está en la lista de objetivos no es paranoia, es baseline.

Cómo verificar tu versión de Ivanti Connect Secure

El comando exacto importa. show version por SSH al appliance (usuario admin) devuelve la versión del firmware. Las versiones parchadas tras el aviso de Volexity llevan el sufijo -106 o superior en la rama 9.x, y -524 o superior en la rama 22.x. Si la tuya no termina en esos sufijos, estás vulnerable aunque pienses que tienes “lo último”. El advisory de Ivanti lista los hotfixes específicos por build — verifica contra la tuya antes de cualquier otra acción.

# SSH al appliance Ivanti Connect Secure (puerto 22 por defecto)
ssh admin@<ap-ip-dc-ics>
# Una vez dentro, el comando exacto para ver la versión del firmware
show version
# Salida esperada (ejemplo, build vulnerable):
# Ivanti Connect Secure, version 9.1.18.55) 2024-09-12, build 12345
# Salida esperada (ejemplo, build parchada):
# Ivanti Connect Secure, version 9.1.18.55) 2026-10-14, build 19872

Si la tuya es vulnerable, el orden de operaciones es: snapshot forense del appliance primero (memoria, logs, configuración), después upgrade, después rotación de TODAS las credenciales que el appliance haya firmado o emitido (certificados de cliente VPN, tokens de sesión, secretos SAML). Asume que si el actor tuvo acceso, rotó las semillas criptográficas que pudo.

Cisco Secure Email Gateway CVE-2026-76519: path traversal en AMP

El 14 de octubre, Cisco publicó el CVE-2026-76519, ubicado en la feature Advanced Malware Protection (AMP) de Secure Email Gateway (SEG, antes IronPort). La vulnerabilidad permite a un atacante remoto escribir archivos arbitrarios al sistema operativo del appliance. CVSS 9.8. El mismo día, CISA lo añadió a la lista KEV — combinación de score y evidencia de explotación que justifica la inmediatez.

El detalle técnico (path traversal que escapa del contexto de AMP al filesystem raíz) es el clásico de productos que llevan años en el mercado: la feature se añadió hace años, las defensas modernas no estaban, y el código original asumía que el input venía del appliance mismo, no de email entrante. Cisco publicó parches para todas las ramas activas (14.x, 15.x). Si tienes un SEG expuesto como relay MX, asume que la superficie de ataque es cualquier correo entrante — no necesitas un actor sofisticado, basta con que alguien mande un attachment bien construido.

Cómo verificar tu versión de Cisco SEG

# SSH al appliance Cisco SEG (puerto 22 por defecto)
ssh admin@<seg-host>
# Ver versión de AsyncOS
show version
# Salida esperada (vulnerable):
# Current AsyncOS Version: 15.5.1
# Salida esperada (parchada):
# Current AsyncOS Version: 15.5.1-031
# Ver configuración de AMP (asegurarte de que la feature esté activa o deshabilitada)
ampstatus

Si tienes AMP habilitado y la versión no tiene el sufijo de patch correspondiente a CVE-2026-76519, el plan es: snapshot de configuración (saveconfig por SCP), aplicar upgrade, después revisar logs de AMP buscando archivos subidos a rutas inesperadas (/tmp/, /var/, o paths que no sean los canónicos de la feature).

Palo Alto PAN-OS CVE-2026-0322: code injection en el firewall más desplegado

El CVE-2026-0322 (CVSS 8.6) fue añadido al catálogo KEV de CISA también el 14 de octubre. CISA lo clasifica como Code Injection Vulnerability. El aviso original de Palo Alto y los detalles técnicos están en su security advisory. Si tienes un firewall Palo Alto con GlobalProtect habilitado y expuesto a Internet, esta vulnerabilidad permite ejecución remota sin autenticación en condiciones específicas.

El patrón que se repite aquí es importante: GlobalProtect es la superficie de ataque típica de PAN-OS. Si tu firewall tiene GlobalProtect deshabilitado y solo expone management por una IP de admin específica (no una IP pública), tu exposición es mucho menor. Pero si GlobalProtect está activo y el portal vive sobre el mismo firewall que el data plane, la superficie es la URL del portal GlobalProtect público — exactamente lo que los atacantes rastrean con Shodan y Censys.

Cómo verificar tu versión de PAN-OS

# SSH al firewall Palo Alto (puerto 22 por defecto)
ssh admin@<pa-host>
# Ver versión del sistema operativo y del GlobalProtect
show system info | match version
# Salida esperada (vulnerable):
# sw-version: 11.1.4-h3
# Salida esperada (parchada):
# sw-version: 11.1.6
# Ver si GlobalProtect está activo y su versión
show global-protect portal-cookie
show global-protect-gateway current-user
request global-protect-portal version

Si GlobalProtect está activo y la versión coincide con una rama vulnerable listada en el advisory de Palo Alto, el plan es: backup de configuración (request system backup), después upgrade a la versión fixeada de tu rama (las 11.1.x y 11.0.x tienen sus propios parches), después revisar logs buscando accesos al portal desde IPs o rangos no esperados, y rotar cualquier credencial de GlobalProtect que haya sido emitida por el portal en los últimos 60 días.

Qué tienes que hacer hoy: triage por vendor

El orden de remediación no es el orden de score CVSS. El orden correcto combina score con probabilidad de explotación real y blast radius (qué tan comprometido queda el resto de tu infra si este appliance cae). Bajo esa lógica, el orden práctico es:

BeyondTrust Remote Support primero — el actor tuvo 41 días de acceso sin ser detectado. Si tienes Remote Support on-prem expuesto a Internet, asume compromiso hasta que demuestres lo contrario. Aplica BT26-05, redeploy desde imagen limpia, y rota todas las credenciales que el appliance haya manejado.
Palo Alto PAN-OS con GlobalProtect expuesto segundo — el portal GlobalProtect es la URL típica que los atacantes enumeran. CVSS 8.6 no es alta en términos relativos, pero la superficie de ataque es Internet completa si tu portal es público.
Cisco Secure Email Gateway con AMP activo tercero — CVSS 9.8 es el más alto del lote. La superficie de ataque es cualquier mensaje entrante, así que el riesgo es proporcional a tu volumen de correo.
Ivanti Connect Secure cuarto en prioridad operativa pero primero si ICS es crítico — el chain de Volexity es el más complejo técnicamente, pero si tu ICS no es accesible desde Internet, el riesgo de exposición inmediata es menor que los tres anteriores.

Cómo saber si tu appliance está expuesto a Internet

Antes de aplicar ningún parche, conviene confirmar si la superficie de ataque es Internet completa o solo tu red corporativa. La forma rápida es verificar el puerto de management desde fuera de tu LAN. Si tienes un servidor en otra red (un VPS barato sirve), puedes hacer un escaneo dirigido contra la IP pública de tu appliance:

# Desde un VPS o servidor externo (NO desde la red del appliance)
# Verificar puertos comunes de management y servicios expuestos
nmap -Pn -sT -p 22,443,8443,8080,9443 <ip-publica-del-appledge>
# Verificar si el portal GlobalProtect de Palo Alto responde
curl -sk -o /dev/null -w "%{http_code}n" https://<ip-publica>/sslmgr
# Verificar si el endpoint de BeyondTrust Remote Support responde
curl -sk -o /dev/null -w "%{http_code}n" https://<ip-publica>/appliance
# Verificar si el portal ICS de Ivanti responde
curl -sk -o /dev/null -w "%{http_code}n" https://<ip-publica>/dana-na/

Si los códigos de respuesta son 200 (o 302 con redirects al portal de login), tu appliance está alcanzable desde Internet pública y la superficie de ataque es completa. Si los puertos están cerrados o filtrados (sin respuesta), tu superficie es solo la red interna — el riesgo sigue existiendo si un atacante pivota desde otro host interno, pero la urgencia operativa es menor.

Cómo aislar un appliance de borde antes de parchear

Si el patch no está disponible todavía o si quieres ganar tiempo antes de aplicarlo, aislar el appliance de la red puede tener sentido. La idea no es esconder el problema, es reducir la ventana de exposición mientras preparas el upgrade. Para appliances basados en Linux (la mayoría de estos), puedes restringir acceso a nivel de firewall del propio host:

# Bloquear acceso externo al puerto de management y al puerto del servicio afectado
# CUIDADO: perderás acceso remoto. Haz esto desde consola física o KVM.
sudo iptables -I INPUT -i eth0 -p tcp --dport 443 -s <tu-ip-admin> -j ACCEPT
sudo iptables -I INPUT -i eth0 -p tcp --dport 443 -j DROP
# Para appliances con GlobalProtect, limitar el portal a tu IP corporativa
sudo iptables -I INPUT -i eth0 -p tcp --dport 443 -s <ip-corp> -j ACCEPT
sudo iptables -I INPUT -i eth0 -p tcp --dport 443 -j DROP
# Para Cisco SEG: bloquear el puerto 25 desde Internet, mantener relay interno
sudo iptables -I INPUT -i eth0 -p tcp --dport 25 -s <tu-mta-corp> -j ACCEPT
sudo iptables -I INPUT -i eth0 -p tcp --dport 25 -j DROP
# Verificar reglas activas antes de confirmar
sudo iptables -L INPUT -n --line-numbers

Una variante más limpia es poner el appliance en una VLAN de cuarentena, separada de la red de producción, y dar acceso solo desde jumpbox. Eso te permite mantener acceso de admin sin exponer la superficie.

Cómo revisar logs buscando IOCs de la cadena BeyondTrust

Si sospechas compromiso de BeyondTrust, los indicadores publicados son el webshell SAWFLY (PHP personalizado) y el tunelizador BARECLAW (SOCKS5). En el filesystem del appliance, busca archivos PHP que no correspondan a la instalación estándar:

# Buscar webshells PHP en ubicaciones no estándar
find / -name "*.php" -not -path "/opt/beyondtrust/*" -not -path "/usr/share/beyondtrust/*" 2>/dev/null
# Buscar binarios SOCKS5 sospechosos (BARECLAW)
find / -type f -executable -newer /etc/hostname -size -1M 2>/dev/null | xargs file 2>/dev/null | grep -i "elf.*executable"
# Buscar conexiones salientes a IPs no esperadas (BARECLAW usa SOCKS5 hacia fuera)
sudo ss -tnp | grep -v "127.0.0.1" | grep -v "10.x" | grep -v "192.168.x"
# Revisar logs de Apache/Nginx por POSTs a paths no estándar
sudo grep -E "POST.*\.php" /var/log/apache2/access.log 2>/dev/null | awk '{print $7}' | sort -u | head -20
# Revisar el historial de bash del usuario que corre el servicio web
sudo cat /home/beyondtrust/.bash_history 2>/dev/null

Si encuentras cualquier archivo PHP en una ruta que no sea la instalación canónica, o conexiones salientes a IPs que no estén en tu lista de vendor endpoints autorizados, trata el appliance como comprometido y aplica la guía de respuesta de BeyondTrust: redeploy desde imagen limpia + rotación total de credenciales + revisión de todos los secretos que el appliance haya firmado.

Patrones que se repiten y qué dice eso del estado del sector

Cuatro vendors en cinco días. Tres con cadenas de post-explotación que requirieron conocimiento íntimo del producto. Uno (BeyondTrust) con 41 días de explotación silenciosa antes del parche. Esto no es mala suerte ni un outlier — es lo que pasa cuando el modelo de negocio del appliance de borde asume que la seguridad se valida una vez al año en una auditoría, no continuamente.

El patrón técnico es ilustrativo también. Los cuatro CVEs tienen algo en común: afectan componentes que procesan input no autenticado desde Internet (portal GlobalProtect, relay de correo, gateway VPN, endpoint de soporte remoto). Los cuatro vendors ofrecen appliances que los sysadmins solemos exponer a Internet por necesidad operacional, aunque las guías de seguridad digan que no deberíamos. La diferencia entre “siguiendo el manual” y “expuesto a Internet” muchas veces se reduce a un checkbox en una pantalla de configuración que nadie revisó.

Lo que esto implica a nivel práctico: si gestionas uno de estos productos, el plan no es solo actualizar. Es asumir que el próximo CVE viene en otro appliance de otro vendor en menos de 30 días. El inventario de appliances de borde expuestos a Internet tiene que ser un documento vivo, con fecha de última revisión, propietario asignado, y plan de remediación para cada uno. Si no tienes ese documento, empieza por ahí.

Preguntas frecuentes

¿Cómo sé si mi appliance está en la lista KEV de CISA?

La forma más rápida es consultar el catálogo oficial en https://www.cisa.gov/known-exploited-vulnerabilities-catalog, filtrar por vendor (Cisco, Palo Alto, Ivanti, BeyondTrust) y cruzar con tu inventario. Para alertas proactivas, suscríbete al RSS del catálogo y mapea cada entrada nueva contra tus appliances — un script bash con curl + grep contra el XML del KEV tarda menos de 5 minutos y te da la lista filtrada por vendor cada vez que CISA publica.

¿Qué hago primero si sospecho que mi BeyondTrust fue comprometido?

El orden correcto es: (1) desconectar el appliance de la red sin apagarlo, (2) hacer snapshot forense de memoria y disco, (3) aplicar el patch BT26-05 sobre una imagen limpia (no upgrade in-place), (4) rotar TODAS las credenciales, certificados y tokens que el appliance haya firmado o emitido. Asumir compromiso durante 41 días implica que cualquier secreto que el appliance haya tocado puede estar en manos del atacante.

¿Por qué estos vendors repiten zero-days mientras otros no?

La respuesta incómoda es que vender appliances de borde es un negocio de escala: cada nuevo feature aumenta la superficie de ataque, y el ciclo de release anual no permite auditar todo el código heredado. Los vendors que mejor lo hacen (junio 2026, no más) invierten 15-20% de su ingeniería en auditoría continua; los demás lanzan features y parchean después. No es una decisión técnica, es de presupuesto.

¿Compensa migrar del appliance propio a una alternativa SaaS?

Depende de qué estés migrando. Para firewalls y gateways de correo, las alternativas SaaS (Cloudflare, Proofpoint) tienen equipos de seguridad dedicados que un appliance on-prem raramente puede igualar. Para VPN, Tailscale o NetBird eliminan la superficie de exposición tradicional. El trade-off es compliance, latencia y costo a escala — evalúa esos tres antes de migrar.

¿Vale la pena apagar la management interface expuesta a Internet?

Casi siempre sí. La regla operativa es: management interface (HTTPS, SSH) por IP de jumpbox o VPN de admin, nunca por IP pública. Si tienes un firewall corporativo o un WireGuard/Tailscale entre el sysadmin y el appliance, el atacante que enumere tu IP pública no encuentra el puerto 443 del management — solo el servicio legítimo. Esta práctica reduce 80% de la superficie de ataque típica.