La CISA da a las agencias tres días para parchear tres fallos del kernel de Linux explotados

La CISA añadió tres vulnerabilidades del kernel de Linux a su catálogo de Vulnerabilidades Explotadas Conocidas el 18 de septiembre de 2026, citando pruebas de que las tres se están explotando en la naturaleza, y dio a las agencias civiles federales hasta el 21 de septiembre para corregirlas. La ventana de unas 72 horas es mucho más corta que las tres semanas que suelen recibir las agencias para las entradas del KEV.

Lectura relacionada: CISA marca PolyShell como explotada mientras la campaña contra Magento alcanza cientos de tiendas · El Patch Tuesday de Microsoft de octubre de 2026 marca un récord con 1.407 correcciones.

Los tres fallos residen en partes no relacionadas del kernel, que es lo que hace inusual la inclusión. Son CVE-2025-39682, un fallo en la ruta de recepción de TLS del kernel valorado con 9.8; CVE-2026-53266, una escritura fuera de límites en el objetivo SNAT de ebtables del puente de netfilter valorada con 8.8; y CVE-2025-39964, una condición de carrera en la interfaz de socket criptográfico AF_ALG valorada con 7.8. La CISA los publicó en dos alertas el mismo día: una sobre CVE-2025-39682 y una segunda sobre los otros dos.

Los tres se marcaron como sujetos a triaje forense conforme a la Directiva Operativa Vinculante 26-04, lo que significa que las agencias deben investigar si sus sistemas ya estaban comprometidos en lugar de considerar el parche como el final de la respuesta. La CISA no reveló quién explota los fallos, qué organizaciones se han visto afectadas ni qué técnicas se emplearon. Ninguna de las entradas se marcó como vinculada a ransomware.

Tres errores muy distintos

CVE-2025-39682 es el más grave sobre el papel y el de mayor alcance. Afecta a TLS en el kernel, una función que traslada el procesamiento de registros TLS al espacio del kernel por eficiencia. El error está en el tratamiento de registros de longitud cero extraídos de la cola de recepción, que puede romper una suposición que hace después el código sobre si los datos ya se han descifrado. El aviso de Red Hat señala que la lógica afectada puede activarse con datos que llegan por la red en sistemas donde kTLS está asociado a sockets TCP, lo que pone a los servicios expuestos a internet que dependen de la aceleración TLS del kernel en primera línea para su revisión.

CVE-2026-53266 es más limitado, pero más grave cuando aplica. Es una escritura fuera de límites en el objetivo SNAT de ebtables dentro del código de netfilter para puentes, que reescribe direcciones de red en el tráfico puenteado. Cuando una función opcional reescribe la dirección hardware del remitente ARP, el kernel puede escribir en memoria sin confirmar antes que el destino sea escribible y, en algunos casos, esa memoria está respaldada por un fragmento de búfer de socket ligado a un archivo importado mediante una operación splice. Explotarlo requiere reglas concretas de netfilter para puentes y, en muchos análisis, privilegios equivalentes a CAP_NET_ADMIN, lo que reduce la población afectada pero incluye cargas de trabajo en contenedores y dispositivos de red que conceden esa capacidad a procesos de servicio.

CVE-2025-39964 es el más accesible para un atacante local. Es una condición de carrera en AF_ALG, la interfaz que permite a los programas de espacio de usuario usar directamente primitivas criptográficas del kernel. La interfaz no imponía una propiedad exclusiva de la ruta de escritura en un socket, así que dos hilos o procesos que escribieran al mismo tiempo podían entrelazar sus operaciones y dejar el estado criptográfico interno del kernel incoherente. El resultado puede ser un fallo o una salida criptográfica corrupta, lo que es un problema de integridad de datos además de uno de denegación de servicio. Al parecer, el fallo estuvo presente en el kernel unos 14 años y lo encontró STAR Labs, que demostró escalada de privilegios y escape de contenedores en el concurso kernelCTF de Google y dijo que no usó IA para hallarlo.

La advertencia de Red Hat y el panorama de parches

Red Hat actualizó sus avisos en torno al 19 de septiembre para reconocer la explotación activa. En los avisos de cada fallo, la empresa dijo que la vulnerabilidad es de alto riesgo y que hay exploits públicos conocidos, e instó a los clientes a abordarla con alta prioridad. Hay parches disponibles en las ramas del kernel con soporte, y Red Hat ha publicado correcciones como RHSA-2025:16880 y RHSA-2025:16904 para CVE-2025-39682, y RHSA-2026:36645, RHSA-2026:39082 y RHSA-2026:39083 para CVE-2026-53266.

Para CVE-2026-53266 existe una mitigación alternativa al parche: desactivar la reescritura de la dirección hardware ARP en las reglas SNAT de ebtables, o eliminar las reglas SNAT que operan sobre tráfico ARP en interfaces de puente. Para CVE-2025-39964 no hay ninguna mitigación funcional aparte de aplicar el parche, según Red Hat. Como los errores están en el kernel principal y no en el empaquetado de una sola distribución, la exposición abarca RHEL, Ubuntu, Debian y otros sistemas derivados del kernel en distinto grado, según la versión y la configuración del kernel que distribuya cada uno.

Un detalle merece separarse del mensaje del fabricante. CVE-2026-53266 no se ha demostrado con código de explotación público, y los análisis han inferido la cadena de escalada de privilegios por analogía con Dirty Pipe en lugar de mostrar un ataque funcional. Eso no contradice la conclusión de la CISA de que el fallo se ha explotado, pero significa que los defensores deberían considerar incompleto el panorama público de exploits.

Por qué el plazo fue tan corto

La BOD 26-04 cambió la forma en que la CISA prioriza el parcheo federal. En lugar de clasificar las vulnerabilidades solo por la puntuación CVSS, pondera cuatro variables, entre ellas si se sabe que un fallo se está explotando. Las incorporaciones del kernel de Linux son un ejemplo claro: CVE-2025-39964 parecería un fallo local de gravedad media en un proceso que prioriza la puntuación, pero la explotación confirmada y el requisito de triaje forense lo colocan en el mismo reloj de 72 horas que un fallo con 9.8.

Para las organizaciones ajenas al Gobierno federal de Estados Unidos, la inclusión en el KEV es una señal más que un mandato. Las funciones del kernel afectadas son lo bastante comunes como para que el consejo práctico sea sencillo: identificar los hosts y contenedores Linux que ejecutan versiones vulnerables del kernel, priorizar los sistemas donde kTLS esté asociado a sockets TCP, donde las reglas de netfilter para puentes usen SNAT de ebtables con reescritura ARP y donde las cargas de trabajo invoquen AF_ALG directamente. Como parchear un paquete no cambia un kernel en ejecución, los equipos deberían confirmar la versión del kernel después de actualizar y reiniciar cuando sea necesario.

Una lista de comprobación práctica

Los tres fallos requieren exposiciones distintas para ser explotables, así que los defensores pueden hacer un triaje en lugar de entrar en pánico. El error de TLS del kernel es el que hay que priorizar en los sistemas expuestos a internet, porque Red Hat dice que puede activarse con tráfico de red en hosts que tienen kTLS asociado a sockets TCP. Los servicios que terminan TLS en el kernel por rendimiento, incluidos algunos proxies, balanceadores de carga y sistemas de almacenamiento, son el primer lugar donde mirar. Comprobar si se usa kTLS es una cuestión de configuración, y los hosts que no lo usan no están expuestos por esa vía.

El fallo de ebtables es más circunstancial. Necesita reglas de netfilter para puentes que hagan SNAT con reescritura de la dirección hardware ARP, y los análisis de explotación sugieren que también requiere privilegios equivalentes a CAP_NET_ADMIN. Los hosts de contenedores, los nodos de virtualización y los dispositivos de red que ceden esa capacidad a procesos de servicio son los más propensos a verse afectados. Una mitigación a corto plazo es desactivar la reescritura de la dirección hardware ARP en las reglas SNAT de ebtables o eliminar las reglas SNAT que actúan sobre tráfico ARP en interfaces de puente.

La carrera de AF_ALG es un problema local, lo que significa que el atacante ya necesita código en ejecución en el host. Importa sobre todo en entornos multiusuario y de contenedores, donde un proceso con pocos privilegios podría competir con el manejo criptográfico de sockets del kernel. No hay mitigación aparte del parche y, como el fallo es una condición de carrera, su explotabilidad práctica varía según la carga de trabajo y el momento.

En los tres casos, el requisito de triaje forense es la parte fácil de omitir. Un parche cierra la puerta, pero no te dice si alguien ya había entrado por ella. Las organizaciones que tratan el plazo del KEV como el final del trabajo pueden pasar por alto pruebas de un compromiso anterior, que es justo lo que la directiva de la CISA pretende evitar.

Qué observar

La primera pregunta es qué están haciendo realmente los atacantes con estos fallos. La CISA no ha publicado indicadores de compromiso ni detalles de inteligencia sobre amenazas, así que los defensores trabajan solo con la inclusión en el KEV. Si el triaje forense saca a la luz pruebas de explotación en agencias federales, puede que sigan más detalles.

La segunda es si los fallos se usaron juntos. El error de TLS del kernel puede activarse de forma remota en la configuración adecuada, el de ebtables puede llevar a una escalada de privilegios y el de AF_ALG es una carrera local. Una cadena que empiece de forma remota y escale a nivel local sería más peligrosa que cualquier fallo por separado, y ninguna información pública los ha conectado todavía.

La tercera es el patrón más amplio. Tres errores del kernel no relacionados explotados a la vez, con un plazo de 72 horas, recuerdan que la superficie de ataque del kernel de Linux es amplia y que los ciclos de parcheo del software de infraestructura pueden quedarse atrás respecto a la explotación. Para los equipos que ejecutan Linux a gran escala, la conclusión útil es acortar la distancia entre un aviso del kernel y un reinicio, porque la próxima incorporación al KEV es una cuestión de cuándo, no de si ocurrirá.

Portada: foto de Wikimedia Commons de una actualización de sistema de Arch Linux mediante pacman en un portátil Acer, por Solijon Solayev (CC BY-SA 4.0).