Pasillo en penumbra con una fila de taquillas metálicas cerradas; una de ellas está entreabierta, iluminada por dentro, y contiene una mochila oscura, mientras una llave descansa en el suelo.

Rust y la seguridad de memoria ante los fallos críticos de octubre

seguridad de memoria, rust, vulnerabilidades, kernel linux, php, node.js, use-after-free, brotli, ciberseguridad

Rust y la seguridad de memoria ante los fallos críticos de octubre

Fecha: 2026-11-07 18:28:54
Autor: Alex Rubio

En octubre de 2026 se publicaron tres vulnerabilidades críticas en piezas de software que funcionan en una gran parte de los servidores de internet: el núcleo de Linux, el lenguaje PHP y la biblioteca de compresión Brotli que incluye Node.js. Las tres tienen algo en común: son errores de seguridad de memoria en código escrito en C, y eso ha reabierto el debate sobre si lenguajes diseñados para impedir este tipo de fallos, como Rust, los habrían evitado.

La cuestión no es solo técnica. Detrás de estos componentes están las webs de muchas pymes, incluidas las que funcionan con WordPress . Además, los tres fallos los encontraron o demostraron equipos que trabajaban con herramientas de inteligencia artificial: Anthropic en el caso de Linux, Wiz en el de PHP y OpenAI en el de Brotli. La respuesta corta es que Rust elimina ciertos tipos de error, pero no todos, y que no basta con tenerlo disponible para proteger el software que ya existe.

Tres fallos críticos en piezas básicas de internet

Linux: un error en la gestión de conexiones TCP

El primer caso, identificado como CVE-2026-98432 (el CVE es el número público que recibe cada fallo de seguridad, como una matrícula), afecta al código del kernel, el núcleo del sistema operativo que reparte memoria, red y procesador entre los programas. Según TuxCare, se trata de un error en la parte que gestiona las conexiones TCP sobre IPv4, relacionado con las opciones IP . El equipo de CVE del kernel lo publicó el 15 de octubre y el 24 de octubre le asignó una nota de gravedad de 9,8 sobre 10.

Esa nota, sin embargo, no es unánime. Según BleepingComputer, Red Hat le da un 5,9 y lo considera sobre todo un riesgo de que el sistema se caiga, porque aprovecharlo es complejo. Anthropic anunció el 27 de octubre que un modelo Claude interno, no publicado, había escrito en unos 53 minutos un exploit (el programa que aprovecha el fallo) capaz de obtener permisos de administrador en remoto contra servidores con Multipath TCP activo, una función que permite que una conexión use varias rutas a la vez. Anthropic no ha publicado ese exploit, y según Aikido y TuxCare el equipo de CloudLinux no pudo reproducirlo.

PHP: ejecución de código sin iniciar sesión

El segundo caso, bautizado como PHP2Shell, agrupa dos fallos: CVE-2026-109618 y CVE-2026-109619, con una nota de 9,2 según Tenable y Rapid7. Wiz demostró con ellos ejecución remota de código, es decir, que alguien de fuera consiga que el servidor ejecute sus órdenes, en WordPress , Drupal y Joomla sin necesidad de iniciar sesión. Según Wiz, el primer fallo se descubrió el 19 de agosto con ayuda de herramientas de IA.

Conviene precisar que el error está en PHP y no en WordPress. Según Patchstack y Rapid7, afecta a varias formas de ejecutar PHP, como PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. Patchstack añade que Wiz también logró leer la memoria de los procesos de PHP, donde puede haber contraseñas y claves.

Node.js y Brotli: datos comprimidos que escriben donde no deben

El tercero, CVE-2026-111497 o Node2Shell, es según Akamai una escritura fuera de los límites de la memoria en el descompresor de Brotli, un formato que usan las webs para enviar páginas más ligeras. El error está en la biblioteca en C de Google , no en el código propio de Node.js, y por eso, según Cycode, también afecta a Bun, a paquetes de Python, a .NET y a Envoy. Lo descubrieron Khai Tran y Sylvie Mayer, de OpenAI Codex Security.

Es, además, el único de los tres con ataques reales confirmados: según Sophos, la agencia estadounidense CISA lo añadió el 27 de octubre a su catálogo de vulnerabilidades explotadas. Según la telemetría de Akamai, el 61 % de las redes que analiza usan versiones afectadas, y las aplicaciones quedan expuestas a través de funciones habituales como fetch() o Express 5 aunque nunca llamen directamente a Brotli.

Qué es un error de seguridad de memoria

Un programa guarda sus datos en zonas de memoria que reserva y libera continuamente. En lenguajes como C, el programador gestiona esas zonas a mano, y un descuido puede dejar una puerta abierta. Por eso estos errores son tan frecuentes en código antiguo y muy utilizado.

El tipo más conocido es el llamado use-after-free (uso después de liberar). Se entiende bien con las taquillas de un gimnasio: alguien devuelve la llave pero sigue usando la taquilla, que ahora es de otra persona; si un atacante deja allí su mochila, el primero acabará usando lo que el atacante quería. Tenable describe así el caso de PHP: datos que quedan de una petición apuntan a memoria ya liberada, y una petición posterior la reutiliza.

El otro gran tipo es la escritura fuera de límites, parecida a escribir más allá del último renglón de un formulario e invadir la casilla de al lado. Es lo que ocurre en Brotli. Según Rapid7 y Zafran, PHP combina un uso después de liberar, una corrupción de memoria al quedarse sin ella y una confusión de tipos, con versiones afectadas desde PHP 5.4. En Linux, según BleepingComputer y CSO, el error de uso después de liberar viene de la versión 4.4.

Qué aporta Rust a la seguridad de memoria y dónde están sus límites

Rust es un lenguaje diseñado para impedir estos errores por defecto. En su código seguro, el compilador funciona como un revisor que no deja construir el programa si detecta, por ejemplo, el uso de memoria ya liberada. Los accesos fuera de límites, en cambio, se frenan habitualmente mientras el programa se ejecuta: Rust comprueba cada acceso y detiene el programa si se sale de la zona permitida, en lugar de dejar que escriba donde no debe.

Esas garantías tienen excepciones. Rust permite marcar fragmentos como unsafe, una zona en la que el programador desactiva parte de las protecciones y asume la responsabilidad; ahí los errores anteriores vuelven a ser posibles. Tampoco protege de errores de lógica ni del agotamiento de recursos, como un servidor que reserva memoria sin límite hasta caerse.

A esto se suma una cuestión práctica. Linux ha empezado a aceptar código en Rust, sobre todo en componentes nuevos, pero la pila TCP afectada por CVE-2026-98432 sigue escrita en C. Por tanto, que el kernel admita Rust no habría evitado este fallo concreto: habría hecho falta que esa parte estuviera reescrita.

Lo que se dice sobre Rust y los fallos de octubre, y lo que dicen los datos

Afirmación que circula	Veredicto	Explicación
En octubre hubo fallos muy graves en Linux, PHP y Node.js	Cierto	Así lo recogen BleepingComputer, Tenable, Rapid7 y Akamai, con notas de 9,8 y 9,2 sobre 10.
El fallo de Linux, con un 9,8, permite tomar el control de un servidor solo con paquetes de red	Exagerado	Red Hat lo puntúa con un 5,9. El control total solo lo afirma Anthropic, sin publicar el exploit, y CloudLinux no pudo reproducirlo. No consta ningún ataque real, según The Back Room Tech.
En PHP se podía ejecutar código en WordPress sin iniciar sesión	Cierto	Wiz lo demostró en WordPress, Drupal y Joomla. El fallo está en PHP.
En Node.js, un archivo comprimido permitía escribir donde no debía	Incompleto	No hace falta un archivo: bastan datos comprimidos con Brotli, como una respuesta web. El error está en la biblioteca de Google , no en Node.js.
Todos son errores de memoria en código C/C++ heredado	Cierto en lo esencial	Los tres son errores de memoria en código antiguo, aunque escrito en C, no en C++.
El uso después de liberar fue de los errores más explotados del mes	Sin confirmar	No hay datos sobre los más explotados. El único fallo con explotación confirmada, el de Brotli, es una escritura fuera de límites.
Que Linux incorpore Rust protege frente a estos fallos	Incompleto	El código afectado sigue escrito en C.
Con Rust ya no hay usos después de liberar ni desbordamientos	Incompleto	Es así en el código seguro, pero no en los bloques unsafe.
Este mes, fallos en Python y JavaScript tumbaron servidores agotando su memoria	Exagerado	En Python hubo fallos que lo permitían, pero no consta que se usaran en ataques. No hemos encontrado un caso en JavaScript en octubre.

El último punto merece detalle. Según cvefeed y OpenCVE, en Django REST Framework el fallo CVE-2026-114136 permitía que una petición JSON comprimida y muy pequeña ocupara muchísima memoria al descomprimirse, lo que se conoce como bomba de descompresión; está corregido en la versión 3.18.2. VulDB recoge otro de consumo de recursos, CVE-2026-114138. Según el aviso publicado en GitHub, el SDK oficial de MCP para Python, las herramientas para conectar asistentes de IA con aplicaciones, guardaba en memoria peticiones sin límite de tamaño (CVE-2026-109527, corregido en la 1.29.1), y el de Java tenía un problema equivalente (CVE-2026-108395). No hemos podido confirmar las fechas exactas de estos dos avisos.

Qué significa para ti

Si tienes una web o un servidor, lo urgente no es cambiar de lenguaje, sino aplicar los parches. Reescribir software en Rust es un trabajo de años y no protege lo que ya tienes en producción.

Node.js: actualiza a 22.23.4, 24.22.1 o 26.12.1, según Picus. Las ramas 20.x y 25.x ya no reciben soporte y siguen siendo vulnerables.
PHP: consulta en php.net qué versión corrige PHP2Shell para tu rama y pregunta a tu proveedor de hosting si ya la ha aplicado. Si usas WordPress, actualizar plugins no basta.
Linux: instala el kernel corregido en cuanto tu distribución lo publique. Según The Back Room Tech, Red Hat lo publicó el 1 de noviembre para RHEL 9 y 10, mientras RHEL 8 y varias versiones de Ubuntu seguían sin corrección el 2 de noviembre. Desactivar Multipath TCP no es suficiente, según Red Hat.
Django REST Framework y MCP: sube a las versiones 3.18.2 y 1.29.1, respectivamente.

Para proyectos nuevos, elegir lenguajes con seguridad de memoria reduce una categoría entera de errores. Aun así, conviene seguir limitando el tamaño de las peticiones y revisando el código con independencia del lenguaje.

En resumen

Los fallos críticos de octubre de 2026 en Linux, PHP y Brotli fueron errores de seguridad de memoria en código C, y el código seguro de Rust está diseñado para impedir ese tipo de errores. Sin embargo, la gravedad del fallo de Linux está discutida, su explotación remota no se ha reproducido de forma independiente y el código afectado sigue en C. Rust tampoco evita los bloques unsafe ni el agotamiento de memoria, como muestran los fallos en Django REST Framework y en los SDK de MCP. Hoy la protección real pasa por actualizar.