BeyondTrust Remote Support: parchea CVE-2026-102764, ya explotada

La CISA pidió el 16 de octubre corregir una vulnerabilidad crítica de BeyondTrust Remote Support que ya estaba siendo utilizada en intrusiones. El aviso apunta a CVE-2026-102764, una falla de autenticación con puntuación CVSS v4 de 9,3. No es una alerta para esperar a la próxima ventana mensual: el riesgo afecta a servidores de soporte remoto que reciben conexiones y puede poner a disposición del atacante una vía hacia los sistemas administrados.

La advertencia de la CISA confirma explotación activa y fija el 19 de octubre como fecha límite de remediación para las agencias federales civiles estadounidenses. Ese plazo no es una obligación regulatoria para todas las empresas, pero sí sirve como señal operativa: el fabricante y el gobierno de Estados Unidos consideran que la corrección requiere prioridad inmediata. El organismo recomienda aplicar las instrucciones del aviso de la CISA sobre CVE-2026-102764.

A quién afecta y qué corregir

BeyondTrust identifica como vulnerables Remote Support en las versiones 24.3.1 a 26.2.3 y las anteriores a 24.3.1. Para la primera franja, el fabricante distribuye el parche BT26-05-RS. Las instalaciones anteriores a 24.3.1 deben actualizar primero a una versión compatible y después aplicar la corrección. No basta con comprobar que el número de versión parece reciente: hay que confirmar en el panel y en el registro de cambios que el parche se aplicó a la instancia concreta.

El aviso técnico BT26-05 de BeyondTrust atribuye a la vulnerabilidad una puntuación CVSS v4 de 9,3 y la clasifica como un problema de autenticación impropia. La explotación puede afectar especialmente a instalaciones autohospedadas expuestas a Internet. Según el fabricante, los clientes SaaS ya habían recibido la corrección antes del aviso público; los responsables de SaaS deben verificar el estado con su proveedor, mientras que quienes operan el producto por su cuenta deben confirmar manualmente la actualización.

Respuesta para las próximas horas

Empieza por inventariar cada instancia de Remote Support, su versión, ubicación, exposición externa y responsable técnico. Comprueba si el servicio está cubierto por actualización automática y guarda evidencia de la versión corregida. Si la actualización no puede aplicarse de inmediato, limita temporalmente el acceso a redes y equipos de administración autorizados; no dejes una consola de soporte publicada mientras se gestiona el cambio.

Después de parchear, revisa los registros de autenticación, sesiones de soporte, creación de cuentas, cambios de configuración y conexiones iniciadas desde orígenes inusuales. Conserva los registros antes de rotarlos y correlaciónalos con los sistemas atendidos mediante la plataforma: una herramienta de acceso remoto puede convertir una brecha del plano de soporte en actividad dentro de servidores de producción. Si aparecen sesiones no reconocidas, trata el caso como una posible intrusión y escala la investigación al equipo de respuesta.

-InfraCrew dice: prioriza el parche por exposición y por evidencia de explotación activa; la fecha del boletín no sustituye a la comprobación de cada instancia.-

La CISA publicó en la misma alerta otra vulnerabilidad explotada, esta vez en Fortinet FortiWeb. Conviene revisar también ese aviso si la organización utiliza el producto, pero la presencia de dos CVE en una alerta no significa que compartan causa técnica ni remediación. Mantén tareas separadas y asigna cada una al equipo que administra el producto correspondiente.

Cerrar el riesgo con evidencia

Registra la versión anterior y posterior, cualquier excepción aprobada y la hora de actualización junto con el resultado de la comprobación. Para SaaS, conserva la confirmación del proveedor y revisa que no queden instancias de prueba u organizaciones secundarias fuera del inventario. Para instalaciones autohospedadas, verifica además que el parche no se haya aplicado solo al servidor principal cuando existen nodos o appliances adicionales.

Si la plataforma almacena credenciales o facilita el acceso a sistemas críticos, rota las credenciales que pudieran haber quedado expuestas si la revisión encuentra actividad sospechosa. El orden importa: primero preserva evidencia y determina alcance; luego invalida secretos y sesiones con el equipo de respuesta para no destruir pistas útiles. Cierra el incidente solo cuando todos los activos estén identificados, corregidos o aislados y exista una comprobación posterior documentada.

-InfraCrew dice: una actualización registrada y una consola fuera de exposición innecesaria reducen el riesgo; la revisión de sesiones determina si además hay que responder a una intrusión.-

Diccionario de la Crew

• Autenticación impropia — fallo que permite completar una acción sin demostrar correctamente la identidad o los permisos requeridos.
• Instancia autohospedada — instalación de software que la propia organización opera y mantiene en su infraestructura.
• CVSS v4 — versión del sistema común de puntuación de vulnerabilidades que expresa severidad técnica mediante una escala de 0 a 10.