Intersect, una organización basada en Cardano, instó a los operadores de pools de stake a aplicar actualizaciones y reiniciar sus block producers y servidores relay a medida que estén disponibles las correcciones para una vulnerabilidad crítica en el kernel de Linux.
En su actualización del 30 de octubre, Intersect indicó a los operadores que verifiquen los kernels en ambos tipos de servidores e instalen el kernel corregido de su distribución tan pronto como se publique. La vulnerabilidad, CVE-2026-98432, tiene una puntuación CVSS 3.1 de 9.8, o crítica, de kernel.org.
La vulnerabilidad afecta el manejo del kernel de las conexiones TCP IPv4 entrantes. Puede provocar que el kernel acceda a memoria después de que se haya liberado. Boletín de seguridad de Red Hat indica que un atacante remoto sin credenciales podría explotar la condición de carrera para ejecutar código; su descripción de vulnerabilidad también identifica bloqueos del sistema y corrupción de memoria como riesgos.
Para Cardano, la advertencia cubre tanto las máquinas que producen bloques como los relés que las conectan a la red más amplia. La documentación del operador de Cardano recomienda mantener los productores de bloques conectados únicamente a sus propios relés o a relés de confianza para protegerlos de internet. El aviso de Intersect no informa sobre explotaciones contra Cardano ni cuantifica cuántas piscinas ejecutan kernels vulnerables.
Parches y medidas provisionales
El rastreador de Ubuntu, actualizado por última vez el 30 de octubre, enumera sus kernels estándar para Ubuntu 22.04, 24.04, 26.04 y 26.10 como vulnerables, con soluciones en desarrollo. El boletín de Red Hat del 30 de octubre lista RHEL 8, 9 y 10 como afectados y afirma que está acelerando las correcciones.
AlmaLinux dijo el 30 de octubre que los kernels parcheados para sus versiones 8, 9 y 10 estaban disponibles en los repositorios de prueba, antes del lanzamiento en producción. Indicó que en ese momento no había ningún kernel RHEL corregido. El error se remonta a Linux 4.4, mientras que las correcciones upstream han sido incorporadas a las ramas estables mantenidas.
El ataque demostrado utilizó Multipath TCP, o MPTCP. Los investigadores de Anthropic dijeron que su prueba de concepto podía enviar paquetes a un servidor Linux con un oyente MPTCP y ejecutar comandos como root, sin credenciales ni interacción del usuario. Pero el Equipo de Seguridad de Go advirtió que la vulnerabilidad subyacente no es específica de MPTCP, por lo que los sistemas sin esos oyentes también podrían ser vulnerables.
AlmaLinux recomienda desactivar MPTCP donde no sea necesario y reiniciar los servicios con oyentes MPTCP existentes: cambiar la configuración sola detiene solo la creación de nuevos sockets MPTCP.
Red Hat también ofrece una mitigación de firewall que filtra paquetes TCP IPv4 entrantes que contienen opciones de IP. Advierte a los operadores que prueben la regla contra sus cargas de trabajo antes de implementarla y señala que el filtrado puede reducir la exposición, pero no puede prevenir completamente la explotación. Ambos proveedores enfatizan que las medidas provisionales no reemplazan la instalación de un kernel corregido; Intersect indica explícitamente a los operadores que reinicien después de actualizar.