AWS concreta qué cargas deben parchear por CVE-2026-98432

AWS actualizó el 2 de noviembre su boletín 2026-160 sobre CVE-2026-98432, un fallo de uso después de liberar memoria en el camino del handshake TCP IPv4 del kernel Linux. El cambio más útil para quien opera en AWS es la matriz de responsabilidades: el mismo fallo no implica la misma tarea en una instancia EC2 propia, un nodo EKS o una función gestionada por el proveedor. El boletín sigue sin reportar indicios de explotación en AWS.

La vulnerabilidad permite que un paquete IPv4 TCP especialmente construido alcance un servicio expuesto y, bajo condiciones concretas, provoque caída, exposición de memoria o corrupción. Investigadores demostraron ejecución remota de código sin autenticación en hosts con un listener MPTCP; ese escenario probado no significa que cualquier máquina Linux expuesta permita ejecución de código. La posibilidad y el impacto dependen del kernel, el tráfico que llega al host y los servicios que acepta.

-InfraCrew dice: “hay un CVE en Linux” describe el titular; todavía no describe el inventario que hay que tocar.-

EC2 y los servicios que terminan conexiones

En instancias EC2 autogestionadas, AWS asigna al cliente la actualización del kernel y el reinicio que la activa. Amazon Linux 2 y Amazon Linux 2023 ya tienen paquetes corregidos según el boletín; el aviso ALAS2-2026-4065 identifica para AL2 el kernel 4.14.355-287.758 y recuerda que el reinicio es obligatorio. Si la instancia usa otra distribución, la corrección depende del proveedor de ese sistema operativo. Una imagen parcheada no corrige por sí sola una VM que sigue arrancada con el kernel anterior.

AWS distingue esos casos de AWS WAF (Web Application Firewall), Application Load Balancer, Classic Load Balancer, CloudFront, API Gateway y listeners TLS de Network Load Balancer. El proveedor aplica actualizaciones a la infraestructura subyacente y dice que no hace falta una acción inmediata del cliente cuando esos servicios se usan con sus prácticas recomendadas. Aun así, recomienda actualizar dentro de 30 días las instancias autogestionadas situadas detrás de ellos; la protección del frontal no elimina la responsabilidad sobre los sistemas que administra el cliente.

-InfraCrew dice: el balanceador puede estar al día y el backend seguir esperando su reinicio; son dos inventarios distintos.-

La excepción operativa importante son los listeners TCP de Network Load Balancer y los destinos detrás de Global Accelerator. AWS explica que esos caminos transmiten al destino paquetes de cliente, incluidas opciones IP. Por eso recomienda actualizar el kernel de los destinos Linux y reiniciarlos, o aplicar una mitigación temporal mientras llega la ventana de mantenimiento. El boletín también describe reducir la superficie deshabilitando MPTCP o bloqueando paquetes con opciones IP; esas medidas reducen condiciones de explotación, pero no resuelven el defecto.

Qué cambia en Kubernetes gestionado

Para EKS, AWS publicó AMI optimizadas basadas en Amazon Linux 2023 con la corrección. Los grupos de nodos administrados, nodos propios y Karpenter que usan esas AMI deben pasar a la versión v20261031 o posterior. EKS Auto Mode reemplaza nodos con una imagen corregida, sujeto a los presupuestos de disrupción definidos en NodePool. En EKS Fargate, los pods nuevos lanzados desde el 1 de noviembre a las 17:00 UTC usan la plataforma parcheada; los que ya existían se reemplazan dentro de un ciclo de hasta 14 días.

La palabra “gestionado” no basta para decidir quién debe actuar: importa si el kernel vive en una instancia que el cliente controla, en un nodo que debe rotar o en una plataforma que AWS mantiene. Lambda, por ejemplo, figura como no afectada porque sus funciones no exponen puertos TCP IPv4 públicos de la forma que requiere el ataque. Otros servicios tienen mitigaciones y calendarios propios; no conviene trasladar automáticamente el procedimiento de EC2 a toda la cuenta.

-InfraCrew dice: en Kubernetes, “actualizar los nodos” puede significar respetar un presupuesto de disrupción, no pulsar un botón durante el pico.-

La revisión útil empieza por trazar el camino de red hasta cada kernel: instancias detrás de balanceadores, destinos TCP, nodos EKS y cargas sobre plataformas administradas. Después se separan parche disponible, cambio automático y mitigación temporal, y se confirma cuándo se reiniciará o sustituirá cada sistema. En bases de datos y servicios con mantenimiento propio, el boletín detalla ventanas diferentes; comprueba la ficha del servicio antes de improvisar una intervención.

AWS dice que no tiene evidencia de explotación, una precisión que rebaja el ruido pero no convierte el boletín en opcional. Para las máquinas bajo control del cliente, la corrección completa requiere kernel actualizado y reinicio. La urgencia práctica está en los destinos alcanzables por IPv4, sobre todo los que exponen servicios o usan MPTCP; el resto de la cuenta se gestiona según la responsabilidad y el calendario publicados para cada servicio.

Diccionario de la Crew

MPTCP — Extensión de TCP que permite mantener una conexión usando varias rutas de red.
AMI — Imagen de máquina de Amazon usada para lanzar instancias EC2 y nodos.
NodePool — Recurso de EKS Auto Mode que agrupa nodos y define condiciones para aprovisionarlos.
Listener — Punto de una instancia o balanceador que recibe conexiones de red.
Kernel — Núcleo del sistema operativo que gestiona memoria, procesos y dispositivos.

Fuentes

AWS Security Bulletin 2026-160 | https://aws.amazon.com/security/security-bulletins/2026-160-aws/
Amazon Linux 2 — ALAS2-2026-4065 | https://alas.aws.amazon.com/AL2/ALAS2-2026-4065.html