En octubre de 2026 (ya hay quien lo llama "Black October") salieron varios fallos de seguridad críticos en piezas que usan millones de sistemas: el kernel de Linux, PHP, Node.js, Chrome y NGINX. Parecen problemas distintos, pero la mayoría comparte la misma raíz: errores de memoria en código escrito en C y C++. Y muchos se encontraron con ayuda de IA. Eso abre una pregunta que lleva años en el aire: ¿Rust los habría evitado?

Los tres fallos principales

1. Kernel de Linux (CVE-2026-98432)

Qué es:

  • Un fallo de tipo use-after-free, combinado con una condición de carrera, en el código IPv4 TCP del kernel, durante el establecimiento de conexiones. Afecta sobre todo a servidores con multipath TCP (MPTCP) y parece relacionado con las opciones IP de los paquetes de conexión.
  • Afecta a kernels desde la versión 4.4.

Cómo funciona, a nivel conceptual:

  • En el saludo TCP (SYN, SYN-ACK, ACK), el kernel guarda una estructura con la conexión a medio armar.
  • En ciertas condiciones, una parte del kernel libera esa memoria mientras otra la sigue usando.
  • El atacante, acertando el momento, rellena esa memoria con sus datos, y el kernel acaba ejecutando su código.

Gravedad: ¿9.8 o 5.9?

  • El equipo CVE del kernel lo publicó el 15 de octubre y lo puntuó el 24 con un CVSS 9.8 (crítico): se puede explotar por red, sin credenciales y sin que nadie haga clic.
  • Red Hat lo baja a 5.9, por la alta complejidad de ganar la carrera que lo dispara.
  • Esa diferencia complica decidir qué parchear primero.
  • Si sale bien, es un RCE con root: control total de la máquina. Según las noticias, una IA consiguió root con este fallo en 53 minutos.

Versiones corregidas: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. El equipo del kernel recomienda actualizar al último estable y no da soporte a aplicar arreglos sueltos (cherry-picking).

¿Por qué Ubuntu y RHEL aún no tienen parche, si todos usan el mismo kernel?

  • Ubuntu, RHEL y algunas versiones de Amazon Linux y SUSE aún no tienen kernel corregido. Red Hat dice que no hay ninguna mitigación que cumpla sus estándares.
  • Las distribuciones empresariales no usan el último estable: mantienen su propio kernel, basado en una versión más antigua y con cientos de parches propios.
  • Tienen que adaptar el arreglo a su versión (backport), probarlo y certificarlo. En RHEL, la estabilidad es el producto.
  • Las distribuciones que siguen de cerca el kernel estable (Arch, Fedora, openSUSE Tumbleweed) normalmente reciben estos arreglos antes. Esto no está confirmado específicamente para este fallo.

Qué hacer mientras tanto en Ubuntu:

  • Lo sensato: esperar el parche oficial, reducir la exposición de red con un firewall y vigilar Livepatch, que podría traer el arreglo sin reiniciar.
  • Kernel mainline (compilaciones sin modificar del kernel oficial): funciona, pero no tiene soporte de Canonical, puede romper drivers (NVIDIA, ZFS) y se pierden las actualizaciones automáticas. Arriesgado en producción.
  • Desactivar MPTCP o bloquear peticiones de conexión con opciones IP: no está confirmado que reduzca el riesgo. Serían medidas extra, no una solución.
  • En programas escritos en Go: GODEBUG=multipathtcp=0 desactiva MPTCP en ese programa (según el equipo de seguridad de Go).

2. PHP2Shell (CVE-2026-109618 y CVE-2026-109619)

Quién y cuándo:

  • Lo descubrieron Wiz Research con Calif y OpenAI, usando IA (modelos de OpenAI y Gemini, además de Wiz Atlas).
  • Se reportó a PHP en agosto, se filtró el 20 de octubre y el parche oficial salió el 21 de octubre.
  • Afecta a PHP desde la versión 5.4 (2012). Puntuación: 9.2 (CVSS 4.0).

Cómo funciona:

  1. El atacante hace que PHP se quede sin memoria justo mientras prepara una petición.
  2. PHP aborta de golpe (lo que se llama bailout), se salta la limpieza y conserva una referencia a memoria que ya liberó: un use-after-free, con estado obsoleto.
  3. Otra petición tiene que caer en el mismo proceso de Apache y colocar datos a medida en ese hueco para ejecutar código.

Por qué es grave, y por qué no tanto:

  • Pasa antes de que se ejecute una sola línea de tu aplicación: demostraron ejecución remota de código sin autenticación contra WordPress, Drupal y Joomla.
  • La complejidad es alta: depende de acertar el momento y el lugar en memoria.
  • Da los permisos del usuario del servidor web, no root.

3. Node2Shell / HTTP2Shell (CVE-2026-111497)

Qué es:

  • Aquí el error no es un use-after-free: es una escritura fuera de límites (out-of-bounds write) en el decodificador de Brotli, la librería de compresión de Google (versiones 1.0.3 a 1.2.0) que incluye Node.js.
  • Con datos Brotli manipulados, el decodificador llega a un estado "imposible" que no detecta, porque no comprueba un valor de retorno. Sigue adelante y escribe más allá de su espacio reservado, lo que puede acabar en ejecución de código.

A quién afecta:

  • A mucho más que Node: Python, .NET, PowerShell y Bun, entre otros.
  • CISA avisa de que ya se está explotando. Puntuación: 9.2 (CVSS 4.0).

Versiones corregidas: Node.js 26.12.1, 24.22.1 y 22.23.4; Brotli 1.0.10, 1.1.1 y 1.2.1; Python Brotli 1.2.1; Bun 1.4.4.

Los otros fallos de octubre

Encajan con la idea (memoria en C/C++)

  • Google Chrome 155: una actualización corrigió 247 fallos, y los 4 críticos de ejecución de código eran use-after-free. Otra corrigió 37 fallos, 7 de ellos críticos, de corrupción de memoria.
  • NGINX (CVE-2026-15176, CVE-2026-93479, CVE-2026-97205 y dos más): fallos de memoria que pueden tumbar un worker y quizá permitir ejecutar código. Cada uno requiere una configuración específica.

Encaja a medias

  • SAP: los parches de octubre traen fallos de inyección de código y de control de acceso (que no son de memoria), más uno de corrupción de memoria de severidad alta.

No encajan

  • Django REST Framework (CVE-2026-114136): una petición JSON pequeña se expande hasta ocupar decenas de MB y agota la memoria.
  • SDK de MCP (@modelcontextprotocol/sdk de la 1.3.0 a la 1.31.0; corregido en la 1.32.0): una petición consume toda la memoria y tumba el servicio.
  • Ambos son agotamiento de memoria (denegación de servicio) en Python y JavaScript, lenguajes que ya gestionan la memoria por ti. Rust tampoco los habría evitado.

Comparación

Fallo Tipo de error Cómo se dispara Qué consigue el atacante Estado
Kernel de Linux Use-after-free + carrera Paquetes TCP, sin servicio web Root en toda la máquina Sin parche aún en Ubuntu/RHEL
PHP2Shell Use-after-free Peticiones HTTP Código como el servidor web Parcheado
Node2Shell Escritura fuera de límites Datos comprimidos manipulados Código en el proceso Parcheado, explotado activamente
  • El kernel y PHP2Shell tienen la misma idea de fondo: se libera memoria, queda un puntero hacia ella y el atacante mete sus datos antes de que se reutilice. Lo que cambia es la capa: en PHP, el proceso web; en el kernel, toda la máquina.
  • Node2Shell es otro mecanismo, pero de la misma familia de errores de memoria en C.
  • Otro ejemplo distinto, de mayo de 2026: Dirty Frag, una escritura arbitraria en memoria (write-what-where) en el kernel.

Repaso: los tipos de errores de memoria

Tipo Qué pasa Ejemplo ¿Lo evita Rust seguro?
Use-after-free Usar memoria ya liberada Kernel, PHP2Shell, Chrome ✅
Escritura fuera de límites (buffer overflow) Escribir fuera del espacio reservado Node2Shell ✅
Lectura fuera de límites Leer fuera del espacio; filtra datos Heartbleed ✅
Double free Liberar dos veces la misma memoria; corrompe el gestor de memoria — ✅
Memoria sin inicializar Usar memoria con restos de datos anteriores Relacionado con PHP2Shell ✅
Condición de carrera (data race) Dos hilos tocan la misma memoria a la vez El kernel (carrera + use-after-free) ✅
Agotamiento de memoria No corrompe nada: consume hasta tumbar el servicio Django REST, SDK de MCP ❌

Rust evita los seis primeros con su sistema de propiedad (ownership), el borrow checker y la comprobación de límites. El agotamiento de recursos, no.

Qué tienen en común

No es que todos tengan el mismo bug, sino la misma causa de fondo:

  • C y C++ gestionan la memoria a mano y no te protegen de equivocarte. Usar memoria ya liberada o escribir fuera de tu espacio compila sin quejarse. Es deuda técnica de décadas, y el riesgo se conocía desde hace mucho.
  • Son piezas compartidas: un mismo kernel o una misma librería de compresión están en millones de sistemas, así que un fallo pega en todas partes.
  • La IA está encontrando estos fallos más rápido que nunca: errores escondidos durante años ahora salen en semanas. El volumen de CVEs crece: en julio de 2026 se publicaron 432 CVEs del kernel en dos días.

¿Rust los habría evitado?

En gran parte, sí. El Rust "seguro", el que escribes normalmente, no compila código que use memoria ya liberada, y comprueba los límites al acceder a los datos. Los tres fallos principales de octubre, y los de Chrome y NGINX, son justo de ese tipo. Por eso el propio kernel de Linux está incorporando Rust poco a poco.

Ya está pasando: Android borró Binder en C

  • Binder es el mecanismo principal con el que se comunican los procesos en Android: cada vez que una app habla con un servicio del sistema (la cámara, las notificaciones, la ubicación), pasa por Binder. Vive en el kernel, como un driver, y durante años estuvo escrito en C.
  • Es una pieza muy delicada para la seguridad: en 2019, un use-after-free en Binder (CVE-2019-2215, conocido como "Bad Binder") se explotó en ataques reales para tomar el control de teléfonos Android.
  • Google pasó años construyendo una versión en Rust (con Alice Ryhl como una de sus principales desarrolladoras). En Kangrejos 2026, la conferencia de Rust para Linux, Carlos Llamas anunció que había borrado el código en C, entre aplausos. Ahora Binder es solo Rust.
  • Es la prueba de que esto no es teoría: una pieza crítica, que ya sufrió exactamente este tipo de error, se reescribió en Rust y la versión en C desapareció.

Pero no es magia:

  • El código marcado como unsafe puede tener los mismos errores que C.
  • Rust no evita los errores de lógica, las inyecciones, los fallos de control de acceso ni los límites de recursos mal puestos.
  • Tampoco evita quedarse sin memoria, como demuestran Django REST Framework y el SDK de MCP.
  • Y hay décadas de código en C que no se van a reescribir de un día para otro.

Conclusión

Octubre de 2026 no fue mala suerte: fue la factura de décadas de memoria gestionada a mano en piezas que usa todo el mundo, cobrada ahora más rápido gracias a la IA. Rust no lo arregla todo, pero sí elimina de raíz la familia de errores que causó la mayoría de estos fallos. Por eso cada vez más proyectos críticos lo están adoptando, y Android ya dio el paso con Binder.

Fuentes