Sophos Firewall: hotfix para la vulnerabilidad CVE-2026-98432
Sophos ha publicado un hotfix del kernel para CVE-2026-98432. El aspecto decisivo para el funcionamiento es que una actualización descargada solo protege el firewall después del reinicio necesario. Por tanto, aunque se utilice la distribución automática de hotfixes, conviene comprobar el estado de instalación y planificar una ventana de mantenimiento.
Este artículo distingue la vulnerabilidad técnica del procedimiento concreto de actualización de los dispositivos Sophos. Fuentes verificadas el 11 de noviembre de 2026. Las páginas del fabricante enlazadas pueden incorporar posteriormente otras versiones de firmware.
¿Qué versiones de Sophos requieren atención?
Estas son las correcciones disponibles para los siguientes productos y versiones de SFOS:
| Producto / versión | Corrección disponible |
|---|---|
| SFOS 22.0 MR3 | Hotfix HF110626.1, requiere reinicio |
| SFOS 23.0 GA | Hotfix HF110626.1, requiere reinicio |
| SFOS 23.0 EAP1 | Hotfix HF110626.1, requiere reinicio |
| Otras versiones de SFOS | El aviso revisado no menciona otras versiones destinatarias del hotfix; Sophos recomienda actualizar a 22.0 MR3 o 23.0 |
| Sophos SD-RED 20 / SD-RED 60 | Firmware RED 3.0.012 independiente |
Esta tabla recoge las correcciones disponibles, no una lista completa de todas las compilaciones vulnerables. Sophos no publica en ese aviso una matriz exhaustiva que indique la primera y la última versión vulnerable de SFOS. Por tanto, la ausencia de una versión en la tabla no permite considerarla segura. Esto afecta, por ejemplo, a la evaluación de una instalación con SFOS 21.5 o 22.0 MR2.
Antes de cambiar de versión, conviene comprobar la ruta de actualización admitida y la compatibilidad del hardware. El artículo sobre SFOS 22.0 MR3 explica esta versión de mantenimiento; el resumen de Sophos Firewall v23 describe la nueva versión principal. En un sistema de producción, la elección debe recaer de forma consciente en una versión adecuada y oficialmente publicada. Que EAP1 reciba un hotfix no es motivo para pasar a una versión preliminar con el único fin de aplicar esta corrección.
¿Cómo se puede explotar la vulnerabilidad del kernel?
CVE-2026-98432 afecta a un error use-after-free en el procesamiento de TCP sobre IPv4 del kernel de Linux. Una ruta de procesamiento accede a memoria que ya se ha liberado. La condición de carrera subyacente se produce por las siguientes operaciones paralelas:
- Durante el establecimiento de una conexión TCP, los datos de las opciones IPv4 se transfieren entre estructuras internas de sockets.
- En paralelo, otro núcleo del procesador puede procesar un SYN retransmitido y preparar una respuesta SYN-ACK.
- Si entretanto se libera la estructura correspondiente, el procesamiento paralelo puede seguir accediendo a sus datos de opciones.
Una condición de carrera es un error cuya aparición depende de la sincronización de operaciones paralelas. Para que el ataque tenga éxito, el procesamiento de red y el estado de la memoria deben coincidir de una determinada manera. Por tanto, el simple establecimiento de una conexión normal no demuestra una explotación satisfactoria.
Según Sophos, en determinadas condiciones es posible la ejecución remota de código sin autenticación y con privilegios del kernel. La demostración de laboratorio descrita públicamente se realizó contra un servidor con un listener Multipath TCP (MPTCP). Esto no constituye una prueba publicada de una toma de control satisfactoria de Sophos Firewall. Tampoco permite concluir que desactivar MPTCP por sí solo elimine la vulnerabilidad subyacente.
Sophos clasifica su aviso como High y cita distintas puntuaciones CVSS: 9,8 por parte de la CNA del kernel de Linux y 5,9 por parte de Red Hat, debido a la condición de carrera. Según la información del aviso, actualizado por última vez el 6 de noviembre, Sophos no tenía constancia de informes públicos sobre explotación activa. Esta afirmación, referida a una fecha concreta, no garantiza que no se produzcan ataques.
En la práctica, conviene evaluar por separado la accesibilidad y el estado de los parches. Restringir el acceso de administración es útil, pero no demuestra que el procesamiento afectado del kernel sea inaccesible. Del mismo modo, iniciar sesión correctamente con MFA no indica que exista protección frente a un ataque sin autenticación.
Guía: instalar el hotfix en el firewall
1. Preparar el mantenimiento
Antes de intervenir, crear una copia de seguridad de la configuración actualizada y aclarar las opciones de recuperación. En ubicaciones remotas, conviene prever un acceso de administración alternativo o una persona localizable in situ. Esto es especialmente importante cuando la única conexión con el firewall pasa por el túnel VPN que se interrumpirá durante el reinicio.
Preparar una lista breve de las conexiones críticas para la empresa que se comprobarán después: acceso a Internet, DNS, VPN de sitio a sitio, acceso remoto y aplicaciones publicadas. Un ping satisfactorio tras el mantenimiento no sustituye una prueba funcional de estos servicios.
Si se utiliza una versión de SFOS distinta de las indicadas anteriormente, primero hay que planificar la actualización de firmware. La guía Actualizar el firmware SFOS describe el procedimiento. Planificar la actualización y la instalación del hotfix como pasos independientes.
2. Comprobar la descarga y la instalación
Iniciar sesión en WebAdmin y buscar en Control center el aviso del hotfix del kernel descargado que requiere reiniciar.
Si los hotfixes automáticos están desactivados, abrir 4 – Device Console en la CLI y activarlos:
system hotfix enableEsperar a que finalice la descarga. Después de una actualización de firmware necesaria, el hotfix debe estar disponible posteriormente; se requiere otro reinicio para aplicarlo.
Reiniciar el firewall durante la ventana de mantenimiento. Esto interrumpe el tráfico de datos.
A continuación, comprobar en Device Console:
system hotfix list
Lo determinante es que aparezca la entrada HF110626.1 con el estado Installed. No basta con que el hotfix figure en la lista. En SFOS 23.0, la página Hotfix: Security updates puede seguir vacía a pesar de haberse instalado; en ese caso, Sophos remite a la comprobación mediante CLI.
3. Documentar el resultado
Como evidencia operativa, conviene registrar el nombre del dispositivo, la versión de SFOS, la hora del mantenimiento y el estado verificado del hotfix. Después, realizar las pruebas de conexión preparadas. Así se distingue entre una instalación satisfactoria y el restablecimiento del funcionamiento de la empresa.
Si falta el hotfix o su estado sigue sin estar claro, no dar el mantenimiento por terminado. Primero, contrastar la versión de firmware, la configuración de hotfixes y el aviso de descarga. Si el problema persiste, contactar con el soporte del fabricante y facilitar estos datos. Repetir reinicios sin obtener información nueva no es una forma fiable de resolver el problema.
Clúster HA: actualizar ambos dispositivos
Sophos establece un orden concreto: comprobar el aviso de descarga en ambos dispositivos, reiniciar primero el dispositivo Auxiliary, esperar a que vuelva a estar disponible y reiniciar después el dispositivo Primary. Ambos dispositivos necesitan el hotfix. Según la guía, el comando CLI para consultar la lista de hotfixes solo está disponible actualmente en el dispositivo que actúa como Primary.
El dispositivo Auxiliary también debe tenerse en cuenta cuando la gestión se realiza mediante Sophos Fusion. Después de la conmutación por error, el aviso puede aparecer de nuevo porque se refiere al otro dispositivo, que ahora está activo.
Antes del segundo reinicio, conviene comprobar además que el otro miembro vuelve a estar operativo y que el clúster presenta un estado correcto. Disponer de una pareja HA no permite anunciar un mantenimiento garantizado sin interrupciones: la conmutación por error y el comportamiento de las sesiones deben formar parte de la planificación. Para cerrar el mantenimiento, registrar ambos dispositivos por separado y probar las aplicaciones a través del clúster.
Actualizar SD-RED 20 y SD-RED 60 por separado
El hotfix del firewall no sustituye la actualización de RED. Para SD-RED 20 y SD-RED 60, Sophos indica el firmware 3.0.012, publicado el 5 de noviembre:
- En WebAdmin, abrir Backup & Firmware > Pattern Updates.
- Si el firmware de SD-RED es anterior a 3.0.012, ejecutar Update Pattern Now.
- Pulsar Install para distribuir el firmware a los dispositivos SD-RED conectados. Estos se reinician durante la instalación.
Para la distribución, Sophos indica como requisitos SFOS 20.0 MR3 y posteriores o SFOS 21.0 MR1 y posteriores, respectivamente. Estos datos se refieren a la distribución de la actualización de RED y no deben confundirse con las versiones destinatarias del hotfix del firewall. Los modelos RED antiguos que han llegado al final de su soporte no reciben esta corrección.
Después del reinicio, conviene probar una aplicación a través de la conexión RED de cada ubicación remota. Si hay varios dispositivos, resulta útil una lista de ubicaciones con la versión de firmware y el resultado de las pruebas: actualizar correctamente un dispositivo no demuestra el estado de todas las demás ubicaciones.
Preguntas frecuentes sobre el mantenimiento
¿Basta con reiniciar sin un aviso visible del hotfix?
Un reinicio por sí solo no constituye una prueba fiable de instalación. Para darla por finalizada, cuenta el estado verificado de HF110626.1. Si falta esa comprobación, la instalación sigue sin confirmarse.
¿Se pueden aplicar soluciones temporales de Linux en Sophos Firewall?
En los dispositivos Sophos debe utilizarse el procedimiento del fabricante. Sophos distingue expresamente sus recomendaciones generales para Linux de la corrección específica del producto. Por tanto, no deben trasladarse al dispositivo cambios propios en parámetros del kernel o filtros de paquetes procedentes de una guía de Linux.
Fuentes
