CVE-2026-98432 se publicó el 15 de octubre, sin mucho ruido, como una corrección más en el kernel. Cambió de escala el 27 de octubre, cuando el Frontier Red Team de Anthropic publicó que un modelo interno de investigación, aún sin lanzar, había escrito un exploit que daba root sin credenciales en servidores Linux con un listener MPTCP. Según Anthropic, su demostración tarda 48 minutos en filtrar un puntero del kernel y otros cinco en ejecutar comandos, y si pierde la carrera solo falla esa conexión, así que puede reintentar.
Desde entonces circula en dos versiones igual de engañosas: que afecta a todo servidor Linux del mundo por igual, o que solo importa si usas MPTCP. Lo que sigue es lo que dicen el registro del CVE, las distribuciones y Proxmox a 4 de noviembre de 2026.
Cuando llega una conexión TCP, el kernel guarda las opciones IP de la petición y, al crear el socket hijo, le transfiere esa memoria sin copiarla. Mientras tanto, otra CPU puede estar respondiendo a un SYN retransmitido de esa misma petición y leyendo la misma memoria. Si el socket hijo se libera en ese momento, la segunda CPU trabaja sobre memoria ya liberada.
El registro del kernel describe esa carrera y otra parecida al migrar peticiones entre sockets. Es decir, no es un fallo de MPTCP, sino del camino de IPv4 que usa casi todo Linux.
La corrección es el cambio «ipv4: free inet_opt and ireq_opt after an RCU grace period», que retrasa la liberación de esa memoria hasta que nadie pueda seguir leyéndola.
El exploit que describe Anthropic ataca servidores con un listener MPTCP, algo que parecía minoritario. Conviene aclarar dos cosas: a 31 de octubre, n-able indicaba que no se conocían ataques reales ni código funcional publicado, y Anthropic no explica por qué hace falta MPTCP. Tres matices más:
ListenConfig usa MPTCP por defecto donde el sistema lo admite. Muchas herramientas de infraestructura están escritas en Go.Para ver si tienes alguno:
ss -Mln
sysctl net.mptcp.enabledEl orden de prioridad real es otro: que algo escuche con MPTCP y esté expuesto a Internet es lo más urgente, pero todo lo demás hay que parchearlo igualmente. A 4 de noviembre no constaba que CISA lo tuviera en su catálogo de vulnerabilidades explotadas, lo que tampoco es garantía de nada.
En el kernel, según el registro del CVE:
| Rama | Corregido desde |
|---|---|
| 5.10 | 5.10.272 |
| 5.15 | 5.15.223 |
| 6.1 | 6.1.190 |
| 6.6 | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.56 |
| 7.2 | 7.2.10 |
| 7.3 y posteriores | Incluido |
Pero las distribuciones numeran a su manera y aplican sus propios parches, así que lo que manda es su aviso, no el número de uname -r comparado con esta tabla:
| Sistema | Situación a 4-nov-2026 |
|---|---|
| Proxmox VE 9 | Corregido desde 7.0.14-25-pve. La versión más reciente es la 7.0.14-28 |
| Debian 13 | Corregido en 6.12.113-1 (DSA-6568-1) |
| Debian 12 | Corregido en 6.1.190-1 (DLA-4841-1) |
| Ubuntu 22.04, 24.04 y 26.04 | Vulnerable, trabajo en curso, con mitigación publicada |
| Red Hat Enterprise Linux | Crítico, según su boletín, con correcciones en marcha |
Hay un caso curioso. Ubuntu marca como pendiente su kernel 7.0.0-43, y Proxmox construye el suyo sobre una variante de esa base, la 43.43i1, que según su repositorio incluye correcciones adicionales. El personal de Proxmox confirma en el foro que el commit de la corrección está incluido a partir de la -25. Es decir, el «Vulnerable» de la página de Ubuntu no se aplica a un host Proxmox con ese kernel. Lo que hay que comprobar en él es:
uname -r
pveversion -v | grep proxmox-kernelSi sigues en un kernel anterior o en la rama de PVE 8, no hemos encontrado confirmación equivalente: compruébalo en los avisos de seguridad de Proxmox.
Ubuntu y Red Hat publican la misma mitigación: descartar el tráfico TCP entrante sobre IPv4 con opciones IP, que el tráfico normal no usa. La hemos validado con nft en Debian 13 y carga sin errores:
cat > cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}
EOF
nft -c -f cve-2026-98432.nft && nft -f cve-2026-98432.nft
nft list table inet cve_2026_98432Tres avisos importantes:
nftables.Sobre MPTCP, puedes apagarlo con sysctl -w net.mptcp.enabled=0, y en programas Go con GODEBUG=multipathtcp=0. Pero son medidas que quitan la vía demostrada, no el fallo. No lo pudimos ensayar en nuestro kernel de pruebas, que viene sin MPTCP, así que valídalo antes.
Un kernel nuevo exige reiniciar, y eso es lo que retrasa a todo el mundo. Lo haríamos así:
uname -r, no apt.uname -r y quita la regla temporal, si la pusiste.El tiempo importa más que antes. Que un modelo de IA escriba este exploit apunta a que la ventana entre el parche y el ataque se acorta, y Anthropic recomienda a quienes defienden revisar su propio código. Si reiniciar te cuesta tanto que siempre vas tarde, merece la pena mirar qué permite actualizar el kernel sin apagar las cargas, y revisar tu línea base de seguridad.
¿Me afecta si no uso MPTCP? Sí. El exploit de Anthropic lo necesita, pero el fallo está en TCP sobre IPv4. Tu riesgo inmediato es menor, pero hay que parchear igualmente.
¿Qué versión de Proxmox VE lo corrige? El kernel 7.0.14-25-pve y posteriores, según el personal de Proxmox en su foro. Hay que reiniciar el nodo para que se aplique.
¿Afecta a IPv6? El registro y la corrección se refieren a IPv4, y la mitigación solo filtra IPv4. Si tu host usa las dos pilas, hay que parchear igualmente.
¿Cómo sé si mi kernel está corregido?
Con uname -r y el aviso de tu distribución. No compares solo con la tabla del kernel, porque las distribuciones aplican parches sin cambiar de rama.
¿Las VMs quedan protegidas al parchear el host? No. Cada máquina virtual ejecuta su kernel y necesita su propia actualización. Los contenedores LXC sí usan el del host.
¿La regla de nftables es suficiente? No. Ubuntu y Red Hat indican que reduce el riesgo, pero no lo elimina. Es una medida temporal hasta instalar el kernel corregido.
¿Tienes hipervisores y máquinas que no sabes con qué kernel corren? En Cloud Privado llevamos el parcheo y los reinicios de plataformas gestionadas, con Proxmox en centros de datos en España y sin que esto te quite el sueño cada vez que sale un 9,8.
¿Proxmox en producción sin llevarlo tú?
Si prefieres no cargar con la operación, dinos qué tienes y qué te falta. Te contamos qué opciones hay para llevarlo gestionado.
Del jueves 12 al sábado 14 de noviembre, Microsoft 365 dejó a miles de empresas sin Outlook, sin Teams y con los administradores sin acceso al panel. Qué se sabe de la causa, por qué el SLA no compensa una parada así y seis medidas de continuidad que conviene revisar ahora.
Valkey se vende como reemplazo directo de Redis, y lo era en 2024. Hoy depende de la versión de la que vengas. Hemos probado copias, réplicas y carga de datos entre Redis 7.2, Redis 8 y Valkey 9 en Docker: un archivo de Redis 8 impide arrancar a Valkey, y al revés. Qué cambia en licencia, qué trae cada paquete y cómo migrar sin sorpresas.
DeepSeek ha publicado dsh-superagent, un prototipo abierto que separa al agente que reparte el trabajo de los que lo hacen. Hemos leído su código y sus documentos: cómo viaja una petición, qué miden de verdad sus experimentos, qué permisos tiene y qué cambia si quieres montarlo en infraestructura propia.