CVE-2026-98432 y CVE-2026-106378: parches de Linux y Chrome

CVE-2026-98432 afecta a la gestión de TCP sobre IPv4 en el kernel de Linux; CVE-2026-106378 afecta al aislamiento de Chrome en macOS antes de 155.0.8059.39. Comprueba las máquinas Linux según el aviso del proveedor del kernel y los navegadores de los Mac según el historial de actualizaciones de Chrome. Verifica la versión activa después de actualizar: descargar una actualización no demuestra que las correcciones estén activas.

La alerta de Derek Ross del 30 de octubre llamó la atención de quienes administran servidores, nodos y servicios de retransmisión sobre el problema de Linux. La publicación de PWN.AI del 30 de octubre destaca un fallo distinto: el escape del entorno aislado del proceso GPU de Chrome. Para una startup, la pregunta práctica es qué máquinas, paquetes e instalaciones del navegador necesitan una actuación.

El anuncio de la CVE de Linux se publicó el 15 de octubre; la ficha de la CVE de Chrome publicada por Google data del 6 de octubre. Las publicaciones de hoy vuelven a poner el foco en vulnerabilidades y correcciones ya existentes.

Estado consultado el 30 de octubre de 2026. Los enlaces de los proveedores que aparecen a continuación son las referencias para conocer la situación actual. La disponibilidad de los paquetes puede cambiar después de esta consulta.

¿Qué es CVE-2026-98432 y permite tomar el control a distancia?

El defecto confirmado afecta al tiempo de vida de la memoria durante el procesamiento de conexiones TCP. Trátalo como una vulnerabilidad grave del kernel y distingue el fallo documentado de las afirmaciones sobre una toma de control remota reproducible.

El uso de memoria ya liberada se produce cuando el código accede a una zona de memoria después de que esta se haya liberado. En este caso, varias operaciones concurrentes pueden seguir leyendo las opciones de un socket IPv4 después de que otra ruta de ejecución las libere. El parche del proyecto Linux modifica dos rutas de destrucción para aplazar la liberación hasta que termine un periodo de gracia de RCU. RCU, o read-copy-update, es un mecanismo del kernel que permite que las lecturas en curso terminen antes de recuperar la memoria.

En la consulta del 30 de octubre, Ubuntu asigna una puntuación CVSS 3.1 de 9.8 y el aviso actual de Red Hat muestra una puntuación provisional de 9.8. Red Hat describe un posible bloqueo, una denegación de servicio o una corrupción de memoria. Amazon Linux la puntúa con 8.1. Atribuye cada puntuación a su proveedor y versión del sistema de valoración; una puntuación de gravedad no demuestra que se pueda tomar el control de forma reproducible en todos los despliegues afectados.

La investigación de Anthropic del 27 de octubre muestra cómo un exploit ejecuta comandos como root en un servidor Linux con un socket en escucha de Multipath TCP (MPTCP), sin credenciales ni interacción del usuario. Es un resultado concreto de ejecución remota para una configuración determinada. No demuestra que la explotación sea fiable en todos los kernels y despliegues afectados.

El aviso del equipo de seguridad de Go del 29 de octubre explica por qué puedes tener esos sockets sin saberlo: Go 1.24 activó MPTCP por defecto para los sockets en escucha en Linux, salvo que la configuración del programa o del entorno de ejecución lo modifique. El equipo recomienda un kernel corregido y advierte que desactivar MPTCP bloquea la vía demostrada, pero deja sin resolver el fallo de IPv4 subyacente.

En el expediente del incidente, separa tres preguntas: ¿existe el código vulnerable?, ¿puede llegar hasta él el tráfico pertinente?, ¿qué explotación se ha demostrado en tu entorno? Puedes dar prioridad al parche antes de tener las tres respuestas. Una respuesta desconocida no significa que la máquina esté a salvo ni que se haya confirmado una intrusión.

¿Qué versiones del kernel de Linux están afectadas y corregidas?

Los números de versión del proyecto Linux identifican las correcciones de sus ramas originales. Los paquetes de las distribuciones exigen una comprobación aparte, porque los proveedores pueden adaptar un parche a una versión anterior sin cambiar la versión de base.

La ficha actual de la autoridad de asignación de CVE de Linux sitúa el origen del problema en Linux 4.4 e identifica estas primeras versiones corregidas, consultadas el 30 de octubre:

Utiliza la última versión con mantenimiento de la rama que gestionas. Estos umbrales describen las ramas del proyecto Linux; no son una regla universal para detectar el fallo en Ubuntu, Debian, RHEL o una imagen de la nube. Los avisos del proveedor determinan qué paquetes de la distribución contienen la corrección.

Una adaptación a una versión anterior aplica la corrección a una base de código más antigua que sigue recibiendo mantenimiento. Por eso un paquete del proveedor cuyo número parece inferior puede incluir el parche. Comparar únicamente si uname -r es numéricamente superior a una versión de una publicación en redes puede llevarte a clasificar mal una máquina.

Conserva los datos completos del paquete: versión de la distribución, familia o variante del kernel, arquitectura y revisión del paquete. Un kernel para la nube, uno genérico y uno destinado a hardware más reciente pueden seguir vías de actualización distintas dentro de la misma distribución.

La descripción del proyecto Linux también indica que IPv6 no está afectado por el primer problema, aunque identifica otro problema relacionado con la migración en IPv6 que requiere un parche separado. Esa afirmación concreta no significa que pasar un servicio a IPv6 resuelva todos los problemas pertinentes del kernel. Consulta el aviso que corresponda a tu configuración.

¿Cuál es el estado de los parches de Ubuntu, Debian, RHEL y la nube?

El estado de una corrección corresponde a un producto y una serie de paquetes concretos. Esta tabla fechada ayuda a localizar la serie adecuada; no permite determinar el estado de una máquina en ejecución.

Fuentes: seguimiento de CVE de Ubuntu, seguimiento de seguridad de Debian, seguimiento de CVE de Amazon Linux, aviso de Red Hat y repositorio de CVE de Oracle Linux.

Los números de Debian que aparecen aquí son versiones de paquetes fuente, no los valores literales que debes esperar de uname -r. El seguimiento de Ubuntu incluye muchas otras variantes. Los avisos de actualización de UEK de Oracle no demuestran que todas las series del kernel de Oracle estén corregidas.

Si tu paquete exacto no figura en esta consulta, abre el seguimiento del proveedor. Mantén el estado como desconocido hasta poder establecer la correspondencia. Que un paquete no aparezca en una tabla breve de un artículo no demuestra que sea seguro.

¿Cómo compruebas qué kernel ejecuta realmente tu servidor?

Recoge primero el sistema operativo y la versión en ejecución. Después relaciona esos datos con la ficha del paquete del proveedor.

Estos comandos de solo lectura son un punto de partida en una máquina Linux:

cat /etc/os-release
uname -r

Guarda la salida junto con la identidad de la máquina y la hora de comprobación. Ejecuta las comprobaciones en el entorno cuyo kernel necesitas identificar y averigua quién controla sus actualizaciones. En un servicio gestionado, quizá necesites una confirmación del proveedor en lugar de acceso a un gestor de paquetes.

A continuación, utiliza las herramientas de paquetes de tu distribución para identificar los kernels instalados y sus revisiones completas. Compara el paquete aplicable con la compilación corregida que indica el proveedor. Que el gestor de paquetes termine correctamente ayuda a acreditar la instalación; aún tienes que determinar qué kernel está activo.

Mantén estos estados separados:

Después de una actualización convencional del kernel, sigue el procedimiento de reinicio del proveedor y vuelve a comprobar la versión en ejecución. Si utilizas parches en caliente, obtén una confirmación explícita de que el proveedor cubre esta CVE en ese kernel. Una suscripción a un servicio de parches en caliente no responde por sí sola a esa pregunta.

Aplica la misma distinción a las máquinas de sustitución. Comprueba la imagen o plantilla que utilizas para crear máquinas e inspecciona una instancia recién lanzada. De lo contrario, puedes corregir los servidores actuales y dejar las futuras sustituciones sin verificar.

¿Qué puedes hacer mientras esperas un parche del proveedor?

Reduce la exposición al fallo, designa quién tomará la siguiente decisión y mantén visibles los sistemas sin corregir. Las medidas temporales necesitan su propia verificación y un plan de retirada.

Empieza por un inventario de exposición: ¿qué máquinas aceptan conexiones TCP, desde qué redes y a través de qué controles? Incluye las interfaces administrativas y los servicios de infraestructura, además de la aplicación pública. El nombre de una máquina no describe por sí solo la ruta del tráfico hasta ella.

Revisa si puedes detener servicios innecesarios o restringir el acceso sin interrumpir las operaciones necesarias. Describe el resultado con precisión: ¿qué redes de origen pueden seguir llegando a cada servicio en escucha? Compruébalo desde el punto de la red pertinente. Considera esta medida una reducción de la exposición y deja constancia del riesgo residual.

El aviso de Red Hat indica que ninguna mitigación cumple actualmente sus criterios de idoneidad publicados. Las recomendaciones del equipo de CVE del kernel favorecen la actualización a una versión estable con mantenimiento y desaconsejan seleccionar parches aislados. Es preferible seguir la vía de actualización admitida por el proveedor que modificar el kernel por tu cuenta.

La alerta en redes también menciona el filtrado de opciones IPv4 y la desactivación de Multipath TCP, o MPTCP. El aviso de Go confirma por qué conviene revisar los sockets MPTCP en escucha, pero advierte que configurarlos programa por programa es un método frágil y que el fallo subyacente no es exclusivo de MPTCP. Antes de usar una solución provisional, determina qué ruta de código cubre, qué tráfico sigue llegando a la máquina y si el proveedor admite esa medida para tu configuración.

Si el equipo cambia los controles de red, conserva un acceso de recuperación, comprueba las conexiones necesarias y documenta cómo revertir el cambio. Una regla de cortafuegos copiada no puede evaluar tu política actual ni sus dependencias. Pide al responsable de esa red que apruebe el cambio concreto y verifique su efecto.

Asigna cada caso pendiente a una persona y fija la próxima hora de consulta del aviso. Eleva las decisiones que requieren una interrupción del servicio, una actuación del proveedor o la aceptación de un periodo de riesgo residual. Nuestra guía para elevar decisiones sobre correcciones de seguridad explica cómo dejar clara esa decisión.

¿Qué tienes que actualizar por CVE-2026-106378 en Chrome?

Actualiza Chrome en macOS a la versión estable actual que recibe mantenimiento y vuelve a abrirlo. La ficha CVE de Google identifica como afectadas las versiones anteriores a 155.0.8059.39. Ese umbral histórico de corrección no es una recomendación para seguir usando una versión antigua del navegador.

La versión estable de Chrome del 6 de octubre publicada por Google ya incluía esta CVE entre las correcciones de Chrome 155. La publicación del 30 de octubre presenta la investigación, posterior al parche.

En la investigación de PWN.AI, el código que ya se ejecutaba dentro del proceso GPU de Chrome podía enviar pulsaciones de teclado sintéticas a través de WindowServer de macOS. La demostración abrió Spotlight e inició Calculadora fuera del entorno aislado del proceso GPU. Los investigadores parten expresamente de una ejecución de código nativo en el proceso auxiliar de la GPU. La prueba muestra la salida del entorno aislado, pero presupone una intrusión previa en el navegador.

La descripción CVE de Google exige que el proceso de renderizado ya esté comprometido y clasifica el problema como Medium en el sistema de gravedad de Chromium. Conserva esa descripción del proveedor junto al punto de partida específico de la investigación en el proceso GPU. Ninguna de las dos justifica presentar este fallo aislado como un ataque completo y universal que se active con solo visitar una página. Ficha CVE de Google.

El parche de Chromium aborda la autorización heredada dentro del sistema de permisos de privacidad de macOS, TCC. Su descripción explica que iniciar directamente el ejecutable de Chromium desde otro proceso puede transmitir los permisos de ese proceso padre a Chromium y a sus procesos hijos. El proceso GPU no debería heredar esa autorización. La forma de iniciar el navegador y los permisos existentes son relevantes para el comportamiento descrito.

Asigna la actualización del navegador a un responsable y documenta las pruebas:

En Chrome, abre Ayuda → Información de Google Chrome, deja que termine la actualización admitida y vuelve a abrir el navegador cuando te lo pida. Comprueba de nuevo la versión que aparece. Las instrucciones de Google para actualizar Chrome explican el procedimiento. Mantén esta comprobación separada del despliegue del kernel de Linux: son programas y pasos de activación distintos.

¿Qué pruebas permiten cerrar las tareas de corrección de estas CVE?

Da por corregida una máquina cuando puedas relacionar su identidad, la corrección aplicable, el kernel activo y el resultado de la verificación. Mantén las excepciones separadas para que un despliegue terminado no oculte una máquina todavía pendiente de actuación.

Para la tarea de Chrome, utiliza los mismos campos con el Mac, la instalación del navegador, el aviso y la versión tras volver a abrirlo. Documenta el reinicio del kernel y el del navegador en sus tareas respectivas.

Utiliza una ficha breve como esta. Es una plantilla operativa, no un requisito del proveedor:

• Máquina y responsable: identidad estable de la máquina, servicio, entorno y persona encargada.
• Aplicabilidad: distribución, familia del kernel, revisión completa del paquete y URL del aviso.
• Acción: actualización o medida temporal aprobada, con su hora de finalización.
• Activación: versión en ejecución tras reiniciar o cobertura explícita de un parche en caliente admitido.
• Verificación: quién examinó las pruebas, cuándo y si los servicios necesarios siguen funcionando.
• Trabajo pendiente: máquinas aplazadas, medidas temporales, imágenes de sustitución y próxima comprobación.

Para un conjunto de máquinas, indica cuáles se han corregido y cuáles siguen pendientes a partir del mismo inventario. Una frase como «la actualización del kernel está desplegada» deja demasiado margen a la interpretación. Especifica qué máquinas ejecutan la compilación corregida, cuáles la tienen instalada pero inactiva y cuáles siguen pendientes.

Imagina una aplicación de tres servidores. Dos máquinas reinician con el kernel corregido; la tercera tiene el paquete instalado, pero no se reinicia durante su ventana de mantenimiento. Mantén abierto el caso de esa tercera máquina, nombra a su responsable y fija una nueva hora de activación. La instalación del paquete ha terminado correctamente, pero esa máquina aún no cumple la misma condición de cierre que las otras dos.

Si un investigador comunicó la exposición, acusa recibo del informe y explica qué has verificado sin revelar detalles innecesarios de la infraestructura. Nuestra guía para crear un programa de divulgación de vulnerabilidades explica esa vía de comunicación.

Preguntas frecuentes sobre las correcciones de Linux y Chrome

¿Instalar el último paquete del kernel completa la corrección?

Confirma que el paquete contiene la corrección del proveedor y que la máquina la ejecuta. Sigue el procedimiento admitido de reinicio o aplicación de parches en caliente y después deja constancia del estado activo.

¿Están corregidos todos los servidores Amazon Linux 2023?

El nombre de la distribución no permite una conclusión general. En la consulta del 30 de octubre, el seguimiento de Amazon incluye correcciones para kernel6.12 y kernel6.18, mientras que su serie kernel predeterminada sigue pendiente. Compara la familia del paquete de tu máquina con el aviso actual de Amazon.

¿Un número de kernel que parece antiguo demuestra que es vulnerable?

Una distribución con mantenimiento puede adaptar un parche a una versión anterior. Utiliza la revisión completa del paquete del proveedor y su correspondencia con el aviso; después verifica la activación. Comparar solo con las versiones del proyecto Linux es insuficiente.

¿La alerta significa que han comprometido mi servidor?

La alerta de vulnerabilidad justifica comprobar la exposición y corregir el problema. Afirmar que hay una intrusión exige pruebas aparte procedentes de tu entorno. Distingue en la documentación la aplicación del parche y la investigación del incidente.

¿El escape de Chrome demuestra que una página web puede tomar el control de todos los Mac?

La demostración publicada del proceso GPU presupone una ejecución previa de código nativo, y la descripción CVE de Google también exige que el proceso de renderizado ya esté comprometido. Actualiza los navegadores afectados y conserva esos requisitos al describir la investigación.

Conserva en Kit el responsable del informe y el historial de verificación

Para dar continuidad al trabajo bastan unos pocos datos: un responsable, el aviso aplicable, la acción realizada y las pruebas examinadas. Tu equipo inspecciona las máquinas y aplica los parches; el expediente permite que la siguiente persona encargada entienda la decisión.

El proceso CSIRT de Kit permite asignar un informe, conservar el historial de asignaciones y estados y distinguir entre resuelto y corrección verificada. El personal autorizado puede marcar como verificada la corrección de un informe resuelto y añadir una nota opcional. Esa nota puede remitir a las pruebas de la máquina; el cambio de estado es una confirmación humana, no una prueba automatizada del kernel.

Para CVE-2026-98432, parte de la fila actual del paquete del proveedor y llega hasta el kernel activo en la máquina. Para CVE-2026-106378, comprueba la versión de Chrome en ejecución tras volver a abrirlo. Mantén visibles las máquinas pendientes hasta que cumplan su condición de cierre. Si tu trabajo de divulgación necesita un responsable y un historial compartido de verificación, puedes probar Kit.