CVE-2026-98432, un nuevo bug remoto afecta al kernel de Linux

Un error de veinte líneas entró en el kernel de Linux el 2 de octubre de 2015, pasó revisión de varios desarrolladores expertos y se quedó ahí once años. Lo encontró una búsqueda sistemática hecha con inteligencia artificial, no una auditoría humana. Once días después del hallazgo, Greg Kroah-Hartman confirmaba que el fallo ya estaba corregido en las ramas estables 6.12.113, 6.18.56, 7.2.10 y 7.3-rc7. El problema es que corregir el kernel no equivale a que tu servidor lo tenga.

La ficha es CVE-2026-98432, un use-after-free en el código TCP de IPv4 que el equipo de CVE del propio kernel puntuó 9,8 sobre 10 el 24 de octubre. Afecta a todas las implementaciones de IPv4 desde la versión 4.4 sin excepción. IPv6 queda fuera. El 27 de octubre, un modelo de investigación interno de Anthropic escribió un exploit funcional que da shell de root a un atacante remoto sin autenticarse, un salto que convierte una ficha teórica en una herramienta disponible para quien sepa leerla.

Con ese escenario, el dato que importa hoy es otro. Al cierre de esta pieza, Debian, Oracle Linux, SUSE y Amazon Linux ya publicaron kernels corregidos para al menos algunas de sus versiones, y Ubuntu y Red Hat Enterprise Linux no. Un administrador con Ubuntu 26.04 LTS en producción tiene delante una ventana en la que el fallo es público, el exploit existe y el parche oficial todavía no ha llegado. La pregunta razonable no es si hay que actualizar, sino qué se hace mientras tanto con las máquinas que no pueden esperar.

Once años dormido en el código de IPv4

El error se cometió en 2015, en la versión 4.4 del kernel, y sobrevivió a once años de auditorías, a miles de revisores y a una industria que presume de revisar la pila de red.

La consecuencia práctica de esa antigüedad es el alcance. Cualquier kernel Linux con IPv4 desde 4.4 acarrea el problema, y eso incluye servidores, routers domésticos con firmware basado en Linux, electrodomésticos conectados, equipos industriales y la mayoría de las imágenes de contenedor que se ejecutan en la nube. Las versiones afectadas van desde la 4.4 hasta las ramas 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3, según la ficha publicada por el centro nacional de ciberseguridad de Hungría, que replica el aviso del kernel.

El vector tampoco exige privilegios ni interacción del usuario. Se trata de una conexión TCP manipulada que provoca el uso de memoria ya liberada, y de ahí a la ejecución remota de código hay un paso que el exploit de Anthropic ya recorrió. Quien tenga la máquina expuesta a Internet y no haya actualizado tiene el mismo problema que tenía un servidor sin parchear en las semanas de php2shell, un patrón que este año se ha repetido demasiado.

La superficie real es más amplia de lo que sugiere la etiqueta de servidor: routers, cámaras, equipos industriales y contenedores comparten el mismo código de red, y muchos de ellos no volverán a ver una actualización en su vida útil.

Quién tiene parche y quién sigue esperando

La foto por distribución es la parte más útil del aviso y la que ningún boletín resumió el viernes. Debian publicó la actualización DSA-6568-1 con linux 6.12.113-1 para Trixie, y para Bookworm mantiene dos vías abiertas, la 6.1.190-1 y la 6.12.113-1~deb12u1. Oracle Linux, SUSE y Amazon Linux movieron ficha en sus ramas de soporte. Red Hat mantiene el fallo en estado de corrección no garantizada para varias versiones, una fórmula que en la práctica significa que no hay compromiso de fecha.

La lista de Ubuntu es la que más incomoda porque incluye las cuatro versiones que la empresa considera actuales. Canonical marca el trabajo como en curso y asigna número de kernel a cada rama, lo que indica que el parche está en el horno, pero no hay fecha pública. En una LTS de 2024 eso deja a miles de empresas con la decisión de esperar o de moverse a un kernel alternativo, el HWE de una versión superior o el propio kernel de la distribución con mitigaciones parciales.

Un modelo de Anthropic escribió el exploit

El 27 de octubre, tres días después del 9,8, Anthropic comunicó que uno de sus modelos de investigación había producido un exploit funcional para este fallo, con shell de root para un atacante remoto no autenticado. La compañía mantiene un programa con modelos de frontera que usan laboratorios y defensores, y este episodio encaja con la línea que ya sigue su producto más agresivo en seguridad. La diferencia con otros anuncios es que aquí el exploit funciona contra kernels que la mayoría de las distribuciones todavía no ha reemplazado.

Ese es el cambio de era que el aviso deja entrever. Durante veinte años, la ventana entre la publicación de un CVE y su explotación se medía en semanas, y el tiempo lo ganaba quien parcheaba rápido.

Con modelos capaces de leer una ficha y escribir código de ataque en horas, esa ventana se comprime a días, y el equipo defensivo pasa a competir contra una herramienta que no se cansa. El fallo dormido once años se convierte en un exploit en tres días, y esa asimetría es la que los equipos de seguridad tendrán que asumir como normal.

Conviene mirar el otro lado del mismo fenómeno. La IA que encontró el error es también la que permite auditar código antiguo a una escala que ninguna plantilla humana alcanza, y el hallazgo salió precisamente de una búsqueda sistemática que revisó rutinas que nadie tenía en el radar. La misma tecnología que acorta el margen de reacción es la que destapó el agujero, y ninguna política pública ha resuelto todavía cómo repartir ese doble filo. En el ecosistema de agentes que analizan código, OpenAI ya ha tenido que revisar sus salvaguardas tras episodios parecidos.

Ninguna de las dos caras resuelve el problema inmediato del administrador que debe decidir, hoy, si reinicia un servicio en producción con un exploit ya circulando y sin parche oficial en su distribución.

¿Por qué el 9,8 no es 9,8 para todos?

La discrepancia de puntuación es otro detalle con consecuencias reales. El equipo de CVE del kernel calificó el fallo con 9,8, mientras Red Hat, Amazon, Oracle y SUSE lo sitúan entre 5,9 y 8,1 en sus propios análisis. La diferencia no es un error de cálculo, sino de criterio sobre lo que significa «explotable de forma remota» cuando el atacante necesita condiciones concretas de red o de configuración.

Para un administrador, esa brecha se traduce en una pregunta incómoda. Si el proveedor de tu distribución puntúa el fallo con 6,5, quizá no lo trate como emergencia y lo meta en el ciclo mensual. Si el kernel lo puntúa con 9,8, el comité de riesgos de tu empresa querrá ver una acción inmediata. Mientras las dos cifras convivan, la priorización dependerá de qué ficha mires primero, y eso es exactamente lo que la industria lleva años intentando resolver con CVSS 4.0 sin conseguirlo del todo.

La recomendación técnica es tan sencilla que resulta casi decepcionante. Actualiza el kernel en cuanto tu distribución lo publique, reinicia, y no esperes a que la ficha de tu proveedor cambie de color. Si no puedes reiniciar, revisa qué servicios exponen IPv4 a redes no confiables y reduce la superficie mientras llega el parche, porque el fallo no requiere autenticación. Y si tu flota es heterogénea, empieza por los servidores con Ubuntu 20.04 o anteriores, los únicos que hoy no tienen ni fecha ni kernel previsto.

Queda la parte incómoda de cualquier emergencia: comprobar que el reinicio ocurrió de verdad, que el kernel cargado es el nuevo y que ningún despliegue automático devolvió la máquina al estado anterior al día siguiente.

La era en que la IA encuentra tus fallos

El caso deja tres cosas claras y ninguna es cómoda. La primera es que el código antiguo que nadie audita sigue ahí, en el corazón de la pila de red, y que ahora lo van a encontrar herramientas que revisan miles de rutinas por hora. La segunda es que el tiempo entre «hay un fallo» y «hay un exploit» ya no se mide en semanas, y las distribuciones que prometen parches en días van a quedar cortas alguna vez. La tercera es que la puntuación de severidad dejó de ser un dato objetivo hace tiempo.

Lo que viene no es un kernel nuevo ni una política global. Es una carrera cotidiana entre modelos que encuentran fallos a escala y equipos que actualizan máquinas a escala, con los administradores de sistemas en medio, leyendo fichas contradictorias un viernes por la noche. La única ventaja real que conserva el defensor es la de siempre: tener inventario de lo que corre, saber qué parchea y reiniciar sin pedir permiso a tres comités. Si eso ya funciona, CVE-2026-98432 es un fin de semana de trabajo; si no, es una sorpresa.