Se han añadido tres antiguos errores del núcleo de Linux a la lista KEV de la CISA

La versión resumida

Ir a la versión completa ↓

En qué consisten: El 18 de septiembre de 2026, la CISA añadió tres vulnerabilidades del núcleo de Linux a su catálogo de vulnerabilidades explotadas conocidas. La CVE-2025-39682 se encuentra en la ruta de recepción TLS del núcleo, la CVE-2026-53266 está en el destino SNAT de ebtables utilizado en los puentes de red, y la CVE-2025-39964 es una condición de carrera en los sockets criptográficos AF_ALG. Tres subsistemas independientes, tres pruebas de exposición diferentes. Ir a esta sección →

Repercusión: Varía mucho más de lo que sugieren los titulares. El fallo de kTLS permite que los registros posteriores se procesen bajo supuestos erróneos de «zero-copy» y de colas. El fallo de ebtables puede provocar que una escritura del núcleo termine en una página respaldada por un archivo que nunca se pretendía modificar a través de esta ruta, lo que Red Hat describe como una vía hacia la corrupción de memoria, la denegación de servicio o la escalada de privilegios. La carrera de AF_ALG produce por sí sola un fallo local o una salida criptográfica corrupta, pero el código de explotación público ahora la encadena para obtener un shell de root en un núcleo afectado. Ir a esta sección →

Gravedad: Es una cuestión más matizada de lo que sugieren los titulares. Red Hat les asigna puntuaciones de 7,0 ; 7,5 y 7,3, y las califica como «Moderada», «Importante» y «Moderada», respectivamente, ya que su escala de gravedad va más allá de la simple cifra. El NVD y el Linux CNA utilizan diferentes vectores para algunas de ellas, de ahí que se obtengan cifras más elevadas: 9,8; 8,8 y 7,8. Ir a esta sección →

Quiénes se ven afectados: RHEL y sus versiones derivadas, entre las que se incluyen AlmaLinux, Rocky Linux, Oracle Linux y CloudLinux, aunque el alcance varía según el CVE. En el caso del CVE-2025-39682, Red Hat señala que solo se ven afectadas las versiones EL9 y EL10. Los otros dos CVE tienen un alcance más amplio, y el CVE-2026-53266 incluye ahora incluso a RHEL 6, que se encuentra en fase de soporte ampliado. Cada fallo tiene además una condición previa que reduce la exposición real. Ir a esta sección →

Estado: No son vulnerabilidades «zero-day». Todas las correcciones del desarrollador original son anteriores a la inclusión en la lista; las correcciones de kTLS y AF_ALG se remontan a más de un año atrás. Los registros de Red Hat señalan ahora estas tres vulnerabilidades como exploits conocidos, pero ni la CISA ni Red Hat han publicado una cadena de ataque, objetivos o datos de telemetría más allá del estado vinculado a KEV, y el uso en ransomware figura como desconocido. También existe ya código de exploit público para dos de las tres. Ir a esta sección →

Hazlo ahora mismo: instala un kernel fijo del proveedor y reinicia el sistema con él, o deja que KernelCare aplique los parches en vivo sin necesidad de reiniciar, siempre que estén disponibles para el kernel concreto que se esté ejecutando. Y omite la lista negra del módulo af_alg. En los kernels de Enterprise Linux comprobados aquí, AF_ALG viene integrado, por lo que la lista negra no tiene ningún efecto. Ir a esta sección →

Antes de confiar en cualquier solución alternativa para af_alg, comprueba cómo está integrado AF_ALG en el núcleo que se está ejecutando:

grep -E 'CONFIG_CRYPTO_USER_API' /boot/config-(uname-r)2>/dev/null||grep-E'CONFIGCRYPTOUSERAPI'/lib/modules/(uname -r)/config

Si CONFIG_CRYPTO_USER_API=y aparece en la salida, AF_ALG está integrado en el código y Ningún módulo de la lista negra puede desactivarlo..

El hecho de que tres CVE del núcleo se incorporen a KEV el mismo día puede parecer un único suceso. En realidad se trata de tres casos distintos, sin una clase de fallo compartida, sin un subsistema común y sin una única prueba que permita determinar si un host está expuesto.

Lo que sí coincidió fue el momento en que se produjo y el revuelo que generó. La publicación incluía un plazo de tres días para que las agencias civiles federales aplicaran las medidas correctivas, de conformidad con la BOD 26-04, y la cobertura mediática posterior citaba una puntuación de gravedad de 9,8 y afirmaba que Red Hat había confirmado de forma independiente que las tres vulnerabilidades estaban siendo explotadas activamente. Los registros de Red Hat sí señalan los CVE como vulnerabilidades conocidas, pero ese estado está vinculado a la lista del KEV y no a la telemetría publicada por Red Hat, y la puntuación de 9,8 debe contextualizarse, ya que procede de un sistema de evaluación distinto al que utiliza Red Hat para RHEL.

Además, ninguno de los errores es nuevo. La corrección de kTLS se incorporó al código fuente original el 19 de agosto de 2025, la de AF_ALG el 16 de septiembre de 2025 y la de ebtables el 23 de mayo de 2026. Por lo tanto, se trata de un problema de retrasos en la aplicación de parches, y la pregunta relevante para cada host es si la corrección llegó alguna vez al núcleo que se está ejecutando realmente.

La CISA añadió las tres CVE al catálogo KEV el 18 de septiembre y fijó el 21 de septiembre como fecha límite para la corrección, según la directiva BOD 26-04, para los organismos civiles federales. Tres días es un plazo corto según los estándares del KEV.

La inclusión significa que la CISA dispone de pruebas de explotación que considera fiables. No significa que dichas pruebas sean públicas, y en este caso no lo son. Las entradas del catálogo no incluyen detalles técnicos, la alerta adjunta no dice nada sobre cadenas de ataque ni objetivos, y en las tres se indica que el uso en campañas de ransomware conocidas es «Desconocido».

Los registros de Red Hat incluyen ahora un indicador de «vulnerabilidad conocida» para las tres, pero Red Hat no ha publicado sus propios detalles sobre la explotación, las cadenas de ataque, los objetivos ni la telemetría, y dicho indicador se basa en la lista de KEV, en lugar de en observaciones independientes de Red Hat. Considéralo como la misma señal que ofrece KEV, no como una segunda fuente.

Por lo tanto, considera esta lista como una indicación fiable de que la CISA dispone de pruebas de que estas vulnerabilidades están siendo explotadas y, a continuación, evalúa cada una de ellas en función de sus condiciones previas reales. La designación KEV aumenta la prioridad, pero la urgencia práctica sigue dependiendo de si cada vía vulnerable es accesible en el servidor.

Las cifras de 9,8, 8,8 y 7,8 que circulan son reales, y las puntuaciones específicas de los productos de Red Hat vuelven a ser diferentes: 7,0 para CVE-2025-39682, 7,5 para CVE-2026-53266 y 7,3 para CVE-2025-39964. Las diferencias se deben a distintos vectores y supuestos sobre la explotabilidad y el impacto.

CVE-2025-39682 es un buen ejemplo. El NVD le otorga una puntuación de 9,8, mientras que Red Hat le asigna un 7,0 para RHEL. Ambos lo consideran accesible desde la red, pero Red Hat le asigna una complejidad de ataque «alta» y un impacto menor en la confidencialidad y la integridad, por lo que el mismo fallo se clasifica de forma muy diferente.

Esa distinción es importante a la hora de realizar el análisis, pero no debería convertirse en un motivo para retrasar la corrección. Las tres figuran en el catálogo KEV de la CISA, y lo que realmente importa no es qué puntuación prevalece. Comprueba si la vía de vulnerabilidad es accesible en tus sistemas, establece las prioridades en función de ello, aplica el kernel corregido o el parche en tiempo real, y verifica que el kernel en ejecución quede realmente protegido.

La vulnerabilidad CVE-2025-39682 se encuentra en el lado de recepción del TLS del núcleo, la capa de registros integrada en el núcleo que permite a las aplicaciones delegar parte del procesamiento de registros TLS al núcleo tras el protocolo de enlace.

Cada recvmsg() Se supone que esta llamada debe procesar bien una secuencia de registros de datos contiguos, bien un único registro que no sea de datos, pero nunca una mezcla de ambos. Un registro de longitud cero que ya se encuentre en la cola de rx_list se cuela en esa comprobación del tipo de registro, por lo que los registros posteriores se gestionan con supuestos erróneos sobre la copia cero y las colas. Esta discrepancia rompe los supuestos de la ruta de recepción sobre los registros y los búferes que contiene, razón por la cual Red Hat lo considera más grave que un simple error de disponibilidad.

Lo importante es la accesibilidad. Tener CONFIG_TLS en el núcleo no es suficiente. El protocolo de capa superior TLS debe estar asociado a un socket TCP, lo cual solo ocurre cuando se ha activado expresamente, como en el caso de una implementación de nginx configurada para utilizar kTLS, una aplicación compilada con una ruta kTLS de OpenSSL compatible o NFS sobre TLS a través de tlshd. Cuando kTLS está habilitado de forma deliberada y la aplicación permite desactivarlo, al deshabilitar la descarga, el procesamiento de los registros vuelve al espacio de usuario, lo que conlleva cierto coste para la CPU. Considéralo una medida de mitigación provisional, no un sustituto de la aplicación de parches.

La corrección se encuentra en la confirmación de origen. 62708b9452f8, con fecha del 19 de agosto de 2025. Red Hat lanzó los núcleos corregidos de RHEL 9 y RHEL 10 el 29 de septiembre de 2025, y las ramas 9.2 SAP y 9.4 EUS les siguieron a finales de octubre. En relación con este CVE, Red Hat indica que RHEL 6, 7 y 8 no se ven afectados. El código vulnerable se introdujo en la versión original de Linux 6.0 y está presente en las ramas del núcleo de RHEL 9 y 10, pero no en RHEL 8 ni en versiones anteriores, basadas en 4.18. Desde entonces ha aparecido código de explotación público que aprovecha esta vulnerabilidad para provocar una corrupción de la memoria del núcleo y obtener un shell de root contra un objetivo específico de kernelCTF, lo cual no equivale a un exploit portátil para los núcleos de RHEL en producción, pero sí significa que el fallo de la ruta de recepción se ha utilizado con fines maliciosos en algún lugar.

El fallo de SNAT de Ebtables que escribe en la página equivocada

CVE-2026-53266 presenta el CVSS de Red Hat más alto de los tres, 7,5, con un nivel de gravedad de «Importante» según Red Hat, y es el que presenta el modo de fallo más interesante.

El destino SNAT de ebtables puede, de forma opcional, reescribir la dirección física del remitente dentro de los paquetes ARP cuando estos atraviesan un puente. Lo hace mediante skb_store_bits(), que escribe en los fragmentos no lineales del paquete. Uno de esos fragmentos puede estar respaldado por una página de archivo importada a través de splice, por lo que la operación de escritura puede acabar en una página respaldada por un archivo que nunca se pretendía modificar a través de esta ruta. Red Hat la asocia con el CWE-825 y describe el resultado como una vía que puede conducir a la corrupción de memoria, a la denegación de servicio o a la escalada de privilegios.

La condición previa es estricta. Tiene que haber una regla SNAT de ebtables configurada por el administrador con reescritura de ARP en un puente, y un atacante no puede activarla. Muchos hosts conectados a un puente nunca utilizan el NAT de ebtables. Como primera comprobación rápida, revisa la tabla NAT en busca de una regla SNAT con reescritura de ARP:

sudo ebtables -t nat -L | grep -i 'snat-arp'

Considéralo como una comprobación inicial de la configuración, más que como una prueba concluyente en ningún sentido. La ausencia de resultados coincidentes es un claro indicio de que la regla no está configurada en ese host. Si se encuentra una coincidencia, el host debería pasar a la parte superior de la cola de correcciones, siempre que se respete tu propio proceso de cambios. Si la reescritura no es realmente necesaria, desactivar esa regla concreta puede reducir la vulnerabilidad hasta que se instale el kernel corregido, pero comprueba que el cambio se ajusta al diseño de la red antes de aplicarlo.

La corrección en el código fuente es la siguiente: commit 67ba971ae025, con fecha del 23 de mayo de 2026. Red Hat corrigió las vulnerabilidades de RHEL 8 y 9 en julio, mucho antes de que se publicara la lista, y a continuación corrigió las de RHEL 10 y RHEL 7 ELS el 24 de septiembre, y las de RHEL 6 ELS el 30 de septiembre. RHEL 9 kernel-rt sigue figurando como afectado.

Dos escritores en un socket AF_ALG

CVE-2025-39964 es un error de concurrencia en AF_ALG, la interfaz de sockets que expone la API de cifrado del núcleo al espacio de usuario. Dos operaciones de escritura simultáneas en el mismo socket AF_ALG pueden entremezclarse y provocar una inconsistencia en el contexto de cada socket.

Red Hat describe la vulnerabilidad directa como algo que permite a un usuario local bloquear el sistema o corromper los resultados criptográficos. A partir de ahí, las puntuaciones divergen. La puntuación principal del NVD es de 5,5, y se refiere únicamente al impacto en la disponibilidad. La CNA de Linux la sitúa en 7,8, y Red Hat en 7,3, con un vector que añade el impacto en la confidencialidad y la integridad. Lo que inclina la balanza es el exploit público. Un repositorio encadena la carrera por la corrupción de la memoria del núcleo, filtra una dirección del núcleo y sobrescribe core_pattern, y consigue un shell de root. Tanto las propias notas del autor como un análisis independiente señalan la existencia de desplazamientos codificados de forma rígida y una elusión de KASLR que podría no ser compatible con todos los núcleos; por lo tanto, se trata de una cadena de escalada de privilegios demostrada en una compilación específica, más que de un exploit portátil contra las versiones de RHEL compatibles. En cualquier caso, la interpretación de que solo provoca un bloqueo ya no es válida, y eso es importante en servidores compartidos o multitenant.

La corrección en el código fuente es la siguiente: commit 1b34cbbf4f01, con fecha del 16 de septiembre de 2025. Este es también el CVE para el que Red Hat lanzó las correcciones con mayor rapidez tras su publicación. El 21 de septiembre, Red Hat aún no había publicado ninguna errata al respecto en ningún producto. La primera errata apareció el 22 de septiembre y, para el 24 de septiembre, ya se habían lanzado correcciones para RHEL 8, 9, 10 y RHEL 7 ELS, además de las variantes con soporte ampliado.

La solución alternativa para AF_ALG que no sirve para nada

Este va a dar problemas.

Las recomendaciones anteriores de Red Hat sobre el CVE-2025-39964 aconsejaban evitar el af_alg que se cargue el módulo. La página actual ya no incluye esa línea, y menos mal, porque nunca funcionó en los núcleos de Enterprise Linux que se han comprobado aquí. En ellos, AF_ALG está integrado en el núcleo, en lugar de incluirse como módulo cargable. Los núcleos incluidos en AlmaLinux 8, 9 y 10, así como en CloudLinux 8, establecen CONFIG_CRYPTO_USER_API=y, con la implementación de AF_ALG y sus interfaces integradas. El modules.builtin listas de archivos kernel/crypto/af_alg.ko, y el paquete no contiene ningún archivo independiente af_alg.ko.

A modprobe.d Por lo tanto, la lista negra se puede aceptar sin que se produzca ningún error, pero no puede desactivar un componente integrado. Lo mismo ocurre con modprobe.blacklist=af_alg en la línea de comandos del núcleo. En las configuraciones probadas no se ha encontrado ningún parámetro sysctl ni de arranque compatible que desactive AF_ALG.

Y el cálculo al que recurre la mayoría de la gente lo entiende al revés:

lsmod | grep af_alg

El hecho de que la salida esté vacía no demuestra que AF_ALG esté inactivo. En los núcleos comprobados aquí, esto concuerda con que AF_ALG esté integrado en el núcleo en lugar de cargarse como módulo, lo cual se confirma con el CONFIG_CRYPTO_USER_API el comando «grep» que aparece al principio de esta entrada y con modules.builtin. No se debe considerar que un servidor está protegido simplemente porque este comando no devuelva ningún resultado. Si la configuración indica =y, las opciones reales son un núcleo parcheado o un parche que no requiere reinicio. Como medida de defensa en profundidad, una política de seccomp sometida a pruebas exhaustivas puede denegar socket() requiere la familia de direcciones AF_ALG para determinadas cargas de trabajo, pero eso depende de cada carga de trabajo en concreto y no sirve de nada frente a los usuarios locales habituales del servidor.

A continuación se muestra la situación de las tres principales familias de Enterprise Linux según las fuentes analizadas hasta el 2 de octubre de 2026. Cada celda comienza con el estado del kernel del proveedor y, en el caso de AlmaLinux y CloudLinux, se añade la cobertura de KernelCare sin necesidad de reinicio cuando difiere, ya que se trata de dos tipos distintos de correcciones. Fíjate en las etiquetas y no solo en las fechas:

Rocky Linux y Oracle Linux no aparecen detallados más arriba, pero siguen el mismo código de origen que RHEL, por lo que conviene consultar el aviso específico de cada uno y el kernel exacto que se está ejecutando, en lugar de dar por hecho que las fechas coinciden. Las ramas de «Extended Update Support» (EUS) de Red Hat para RHEL 8 (8.4, 8.6, 8.8) y RHEL 9 (9.2, 9.4, 9.6) también recibieron correcciones entre el 23 y el 24 de septiembre, mientras que las versiones principales más antiguas, RHEL 6 y 7, reciben mantenimiento a través del Soporte de Ciclo de Vida Ampliado (ELS), al que se refieren las notas de ELS de la tabla.

Dos comentarios breves. En CloudLinux 8, los núcleos de 4.18.0-553.142.1 Las versiones posteriores ya incluyen la corrección de CVE-2026-53266, así que comprueba uname -r antes de dar por hecho que existe una vulnerabilidad. Además, Red Hat cambió el estado de RHEL 6 de «No afectado» a «Afectado» para el CVE-2026-53266 a finales de septiembre, y publicó una corrección para RHEL 6 ELS el 30 de septiembre, lo cual es importante para cualquiera que siga utilizando RHEL 6 o CloudLinux 6 bajo el programa de soporte de ciclo de vida ampliado (ELS).

Debian, Ubuntu y Amazon Linux realizan un seguimiento de estas CVE según sus propios calendarios. Consulta el aviso correspondiente a tu kernel concreto en lugar de basarte en el de RHEL.

Los parches sin reinicio de KernelCare también cubren las ramas de RHEL, tal y como se muestra en la línea temporal del cuadro de estado situado en la parte superior de esta entrada; por lo tanto, la fila de RHEL que aparece más arriba hace referencia a los propios núcleos de Red Hat y no a la ausencia de una opción de parche sin reinicio.

Consigue KernelCare hoy mismo →

Un paquete del núcleo corregido que se encuentra en el disco no modifica el núcleo que hay en memoria. Para realizar una actualización convencional, instala los paquetes del núcleo corregidos correspondientes a tu versión concreta, reinicia el sistema y comprueba cuál es el que se está ejecutando realmente:

uname -r

Compáralo con el aviso de Red Hat o con el de la reinstalación, no con lo más reciente que haya en el disco. Un servidor que instaló la actualización hace tres semanas y nunca se ha reiniciado sigue ejecutando el núcleo antiguo.

Cuando hay disponible un parche compatible, KernelCare aplica las correcciones correspondientes al núcleo activo sin necesidad de reiniciar el sistema. Estas correcciones se distribuyen como parches en tiempo real sin necesidad de reinicio a través de los canales mencionados anteriormente, y la disponibilidad de los parches en tiempo real depende del núcleo concreto. Las configuraciones con las actualizaciones automáticas activadas descargan los nuevos parches periódicamente, y kcarectl --update Se solicita uno bajo demanda. Comprueba cuáles de los tres están incluidos en el núcleo actualmente en ejecución:

kcarectl --patch-info | grep -E 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

Si no aparece ningún CVE para el kernel en ejecución, no deduzcas la cobertura a partir de otra distribución, otra rama menor o una actualización de paquete que nunca se haya ejecutado, y mantén activa cualquier medida de mitigación provisional validada hasta que aparezca. CloudLinux 8 es un caso especial, en el que es posible que un kernel reciente ya contenga de forma nativa la corrección del CVE-2026-53266, incluso si una consulta de parches en tiempo real no muestra ningún parche independiente.

No. Todas las correcciones ya eran públicas en el código fuente original antes de la publicación, y Red Hat ya había lanzado kernels corregidos para CVE-2025-39682 casi un año antes. Lo nuevo a nivel público es la designación KEV de la CISA, que indica que se sabe que las vulnerabilidades están siendo explotadas, pero no ofrece detalles públicos sobre dicha explotación. Es la típica historia de los «n-day». Las antiguas correcciones del kernel que nunca se aplicaron son precisamente el lugar al que acuden los atacantes en busca de oportunidades.

Sin embargo, conviene ser preciso en lo que respecta al código de explotación. Actualmente existen repositorios públicos con pruebas de concepto (PoC) de escalada de privilegios que funcionan para CVE-2025-39682 y CVE-2025-39964, ambas creadas para objetivos específicos al estilo kernelCTF con desplazamientos codificados de forma fija. Se trata de una verdadera «armamentización», no de un exploit portátil contra un parque de servidores de producción parcheados pero sin reiniciar, por lo que afirmar que «no hay ninguna prueba de concepto pública» es sencillamente erróneo a estas alturas, aunque «cualquiera puede obtener privilegios de root en cualquier host» sea igualmente erróneo.

Por qué es importante el trío de núcleos KEV

Ninguna de las tres cuenta con una vía de ataque amplia y sin requisitos previos. Una requiere kTLS, otra necesita una regla específica de ebtables configurada por el administrador y la tercera exige acceso local, aunque los exploits públicos disponibles muestran ahora una cadena de escalada de privilegios contra un kernel específico. Esa es la parte tranquilizadora.

La lección está en todo lo que les rodea. Las tres vulnerabilidades se podían solucionar antes de que la CISA dijera nada, y la reparación en el código fuente, las adaptaciones de los proveedores, la implementación en el parque informático y la explotación no se producen al mismo ritmo. Mientras tanto, las puntuaciones que circulaban indicaban a la gente un nivel de urgencia erróneo, y una solución provisional anterior del proveedor para un CVE no surtió efecto alguno, de forma silenciosa, en los núcleos que se suponía que debía proteger. El plazo de tres días también transcurrió antes de que Red Hat hubiera lanzado ninguna solución para el CVE-2025-39964, por lo que el núcleo del proveedor simplemente no estaba disponible cuando venció la fecha federal de corrección para ese caso concreto.

En el caso de las flotas con parches convencionales, instala los núcleos corregidos y reinicia según un calendario razonable, dando prioridad a los hosts con reescritura de ARP mediante ebtables y a los hosts con kTLS. En las flotas en las que la coordinación de los reinicios supone un cuello de botella, KernelCare cierra las rutas cubiertas en el núcleo en ejecución mientras continúa el mantenimiento habitual.

Consigue KernelCare hoy mismo →

Cronología

Referencias

Las fuentes principales de esta entrada son el catálogo de vulnerabilidades explotadas conocidas de la CISA (versión 2026.10.01), la alerta de la CISA del 18 de septiembre de 2026, la Directiva Operativa Vinculante 26-04 y las páginas de Red Hat sobre los CVE-2025-39682, CVE-2026-53266 y CVE-2025-39964, las entradas del NVD para CVE-2025-39682, CVE-2026-53266 y CVE-2025-39964, y las correcciones de origen 62708b9452f8, 67ba971ae025 y 1b34cbbf4f01.