Actualizado el 31 de octubre de 2026, a las 06:04 (hora peninsular española). Una vulnerabilidad en el núcleo de Linux, identificado como CVE-2026-98432, ha provocado una alerta de seguridad para administradores de servidores, proveedores de alojamiento y empresas con infraestructura tecnológica propia. Red Hat publicó el viernes 30 de octubre un boletín de impacto crítico y trabaja en correcciones. La investigación de Anthropic describe una demostración de ejecución remota de comandos con privilegios de administrador (root) sobre una configuración específica de Linux. No hay pruebas confirmadas de explotación de esta vulnerabilidad en ataques reales, según la información pública examinada.
Qué ha confirmado Red Hat en su aviso del 30 de octubre
En su boletín RHSB-2026-016, publicado el 30 de octubre a las 16:03, Red Hat califica la incidencia de crítica y explica que un atacante remoto sin credenciales podría aprovechar una condición de carrera durante el establecimiento de conexiones TCP. El problema se produce cuando el sistema libera datos de memoria que otro proceso todavía está utilizando, un fallo conocido como use-after-free. Bajo determinadas circunstancias puede causar corrupción de memoria y, potencialmente, ejecución de código.
La compañía identifica como afectados a Red Hat Enterprise Linux 8, 9 y 10 y a entornos OpenShift que dependen de sus kernels. El fabricante afirma que está acelerando las correcciones. La ficha actualizada del CVE de Red Hat y el registro CVE recogen una puntuación de gravedad de 9,8 sobre 10. Esa cifra describe el riesgo potencial del defecto, no el número de equipos comprometidos ni la probabilidad de que cualquier servidor pueda ser tomado automáticamente.
Qué ha demostrado Anthropic y cuáles son sus límites
El equipo de investigación de Anthropic publicó el 27 de octubre una investigación sobre vulnerabilidades descubiertas con Claude. En una de sus pruebas, un modelo experimental generó un método para enviar paquetes a un servidor Linux con un servicio que escucha mediante Multipath TCP (MPTCP) y ejecutar órdenes como root sin iniciar sesión. Según Anthropic, el procedimiento tardó unos 48 minutos en obtener información de memoria y otros cinco en alcanzar la ejecución del comando.
Esta demostración es relevante porque pasa de un posible bloqueo del sistema a un escenario de control privilegiado, pero tiene límites importantes. Se realizó en un entorno de investigación, el código completo del exploit no se ha publicado y la ejecución remota como root no se ha demostrado públicamente en servidores sin un servicio MPTCP. La vulnerabilidad de memoria, sin embargo, afecta al procesamiento ordinario de conexiones IPv4 TCP. Por ello, desactivar MPTCP no equivale a corregir el defecto subyacente.
El medio especializado BleepingComputer confirmó el 30 de octubre la situación de las distribuciones y las limitaciones de la prueba. La existencia de un exploit experimental no permite afirmar que existan miles de intrusiones, robos de datos o una campaña global en marcha.
Ubuntu, Debian y CloudLinux: no todos los servidores están igual
La situación depende de la distribución, el kernel instalado y las actualizaciones realmente aplicadas. El registro oficial de Canonical, actualizado el 30 de octubre, marcaba como vulnerables y con trabajo de corrección en curso los paquetes principales de Linux para Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS y 26.10. Eso no implica que todos los equipos con Ubuntu sean explotables del mismo modo, sino que el fabricante todavía no los consideraba corregidos en esos paquetes.
En cambio, el rastreador de Debian identifica paquetes de seguridad corregidos para Debian 12 y 13. La diferencia entre un parche disponible y uno instalado es esencial: el administrador debe actualizar, comprobar que está ejecutando el kernel corregido y, cuando proceda, reiniciar el servidor. Las distribuciones pueden incorporar el arreglo mediante parches propios sin adoptar exactamente la numeración del kernel original.
Para empresas de alojamiento compartido, CloudLinux también publicó el viernes un seguimiento por versiones. La compañía advertía de que parte de sus sistemas seguían esperando actualizaciones, mientras algunas ramas LTS ya habían iniciado su despliegue. Su equipo señaló además que no había reproducido la explotación remota descrita por Anthropic en sus propios kernels: una cautela que conviene mantener al evaluar la amenaza.
Por qué importa a las empresas españolas
Linux sostiene numerosos servidores web, máquinas virtuales, servicios de correo, aplicaciones corporativas y plataformas en la nube. Si una organización utiliza una versión vulnerable y expone servicios TCP a internet, sus responsables deben evaluar la exposición. En el caso de proveedores de hosting, un fallo en el kernel del servidor puede ser más grave que una vulnerabilidad limitada a una página web, porque el sistema operativo gestiona recursos compartidos por múltiples clientes.
Para una pyme que solo contrata alojamiento gestionado, la primera medida práctica es pedir al proveedor confirmación del estado de sus kernels y del calendario de corrección. No basta con actualizar WordPress, PHP o un complemento: el problema reside en el núcleo de Linux. Tampoco debe confundirse con la crisis PHP2Shell, ya analizada por Business Magazine, que afecta a otro componente tecnológico y requiere medidas diferentes.
El alcance exacto en España no está cuantificado: no existe una cifra pública verificada de empresas, servidores o webs españolas comprometidas por CVE-2026-98432. Tampoco se ha acreditado una interrupción general de servicios por esta causa. El riesgo empresarial reside en una eventual intrusión, indisponibilidad o necesidad de ventanas de mantenimiento para aplicar parches.
Qué deberían revisar ahora los responsables técnicos
La prioridad es inventariar servidores físicos, virtuales y nodos de contenedores; identificar la distribución y la versión del kernel realmente cargada; y contrastar esos datos con los avisos de seguridad oficiales de cada fabricante. Los equipos expuestos a conexiones IPv4 TCP desde internet requieren una revisión preferente, especialmente si ejecutan servicios que utilizan MPTCP. También conviene revisar los procedimientos de respuesta a incidentes y conservar registros para detectar comportamientos anómalos.
Red Hat propone en su boletín una filtración temporal de determinados paquetes IPv4 con opciones, pero advierte de que no sustituye al parche y de que puede interferir con cargas de trabajo legítimas. Cualquier medida de filtrado debe probarse antes de su despliegue en producción. El remedio definitivo es instalar la actualización específica del fabricante cuando esté disponible y verificar su aplicación; no improvisar cambios que puedan dejar inaccesibles servicios críticos.
Una alerta importante, no una crisis mundial confirmada
El caso ilustra un desafío recurrente para empresas y administraciones: una corrección puede existir en el proyecto original de software y tardar en llegar a todas las versiones distribuidas comercialmente. La publicación del aviso crítico de Red Hat el viernes y la información técnica independiente de ese mismo día justifican una revisión urgente, pero no permiten anunciar una oleada de ataques sin pruebas.
Fuentes principales consultadas: Red Hat (30 de octubre), Canonical (actualización del 30 de octubre), Debian, Anthropic (27 de octubre), CloudLinux (30 de octubre) y BleepingComputer (30 de octubre). Información contrastada a las 06:04 CET del 31 de octubre de 2026.
