Script de Validación Defensiva CVE-2026-23111

Descripción general

CVE-2026-23111 es una vulnerabilidad del kernel de Linux en nf_tables que puede ser explotada para la escalada local de privilegios por un usuario sin privilegios en sistemas donde los espacios de nombres de usuario (user namespaces) y nftables están disponibles.[1][2] Los avisos públicos de proveedores y gobiernos la describen como un problema local que afecta a las distribuciones Linux y enfatizan la aplicación de parches como la solución principal.[3][4]

Este repositorio contiene un script de validación defensiva diseñado para ayudar a evaluar si un host expone las condiciones técnicas asociadas con esta CVE sin proporcionar un exploit de escalada de privilegios. Comprueba las condiciones relevantes del kernel y del entorno de ejecución, carga opcionalmente el módulo nf_tables para realizar pruebas funcionales completas, intenta una ruta de validación controlada sin privilegios usando unshare y nft, recopila trazas de diagnóstico locales y clasifica el host en veredictos operativos como probablemente seguro, bloqueado por política local, o ruta expuesta disponible.[1][5]

En qué consiste la CVE

Según el NVD, CVE-2026-23111 es una vulnerabilidad de nf_tables en el kernel de Linux resuelta como una corrección de un error lógico en netfilter y es explotable para la escalada local de privilegios desde un usuario sin privilegios a través de los espacios de nombres de usuario y nftables en configuraciones afectadas.[1] El aviso de seguridad de Ubuntu describe la misma ruta de explotación de alto nivel y realiza el seguimiento de los estados de los paquetes afectados y corregidos por versión.[2]

Red Hat afirma que un usuario local con privilegios bajos podría explotar el problema para causar una denegación de servicio o potencialmente lograr una escalada de privilegios, y documenta una ruta de mitigación basada en impedir que el módulo nf_tables se cargue cuando eso sea operativamente aceptable.[3] La guía a nivel nacional del Centro Canadiense de Ciberseguridad también remite a las organizaciones afectadas a las actualizaciones de los proveedores y menciona la regeneración del initramfs cuando se utilizan mitigaciones de bloqueo de módulos.[4]

Qué hace el script

El script está pensado para la evaluación defensiva de exposición, no para la explotación. Está diseñado para:

• Identificar el kernel en ejecución, la familia de distribución y los ajustes relevantes de endurecimiento del entorno de ejecución.
• Comprobar si CONFIG_USER_NS y CONFIG_NF_TABLES parecen estar presentes.[1]
• Inspeccionar kernel.unprivileged_userns_clone y user.max_user_namespaces para estimar si los espacios de nombres de usuario sin privilegios están disponibles.
• Detectar si existe una denegación estricta de modprobe (install nf_tables /bin/false) o una lista negra débil para el módulo nf_tables.
• Revisar el changelog del RPM del kernel del proveedor en busca de una entrada de backport de CVE-2026-23111 (solo familia RHEL).
• Obtener la huella de /proc/kallsyms para el símbolo vulnerable (nft_map_catchall_activate) frente al símbolo posterior al parche (nft_catchall_set_activate) antes de cualquier interacción con el módulo.
• Cargar opcionalmente nf_tables mediante modprobe cuando se especifica (ver más abajo), y descargarlo automáticamente al salir.

El script almacena los registros en un subdirectorio del directorio del script y los elimina de forma predeterminada a menos que se use --keep-logs.

Política de carga de módulos

De forma predeterminada, el script nunca carga nf_tables. Si el módulo no está ya cargado cuando el script se inicia, todas las pruebas funcionales de nft se omiten y el veredicto se deriva únicamente de la versión del kernel, la huella de kallsyms, la configuración de modprobe, el changelog del RPM y la evidencia de política sysctl/LSM.

Este valor predeterminado conservador evita ampliar involuntariamente la superficie de ataque en hosts de producción. Para habilitar las pruebas funcionales completas en un sistema controlado o instrumentado, use --allow-load-module como root (ver más abajo).

Uso

# Default — no module loading, policy-evidence-only verdict
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Full functional test — loads (and unloads) nf_tables, requires root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Opciones

Cuándo usar --allow-load-module

Use --allow-load-module cuando necesite el veredicto de mayor confianza en una VM de prueba aislada, que no sea de producción o creada específicamente para ello. Escenarios típicos:

• Se está validando un kernel dentro del rango vulnerable antes de implementar la corrección del proveedor.
• El sistema de prueba tiene KASAN u otra instrumentación habilitada y desea observar las trazas del kernel.
• El módulo no está en uso en el host de destino y se requiere una verificación completa de extremo a extremo de la ruta como evidencia de auditoría.

No use --allow-load-module en hosts de producción donde nf_tables esté bloqueado intencionalmente o donde cargarlo violaría una política de endurecimiento.

Controles de seguridad para --allow-load-module

Antes de intentar cargar el módulo, el script aplica las siguientes comprobaciones y sale con un error si alguna falla:

1. Una denegación estricta de modprobe (install nf_tables /bin/false) no debe estar presente en /etc/modprobe.d/.
2. modprobe debe estar disponible en el sistema.
3. El script debe ejecutarse como root (uid 0).

Si el script carga el módulo correctamente, se llama a modprobe -r nf_tables al salir mediante la trampa cleanup(), independientemente de cómo termine el script (con éxito, con error o con CTRL+C).

Modelo de veredictos

El script utiliza veredictos operativos en lugar de resultados de explotación:

Estos veredictos están pensados para respaldar la priorización de parches y el triaje defensivo, no para sustituir la validación del estado de los paquetes del proveedor.

Cobertura de versiones del kernel

El script compara el kernel en ejecución con los puntos de corrección upstream documentados:

Mitigación recomendada

La acción principal recomendada es instalar la actualización del kernel corregido por el proveedor y reiniciar con el kernel corregido.[2][3][4] Debido a que la explotación depende de la superficie de ataque local del kernel, un endurecimiento adicional puede reducir la exposición mientras se programa o valida la aplicación del parche.[5][6]

Acciones prioritarias

1. Aplique el parche al kernel siguiendo el aviso oficial de la distribución y reinicie con la versión corregida.[2][3][4]
2. Restrinja los espacios de nombres de usuario sin privilegios cuando los requisitos del negocio lo permitan, porque la ruta de ataque documentada depende de que estén disponibles para usuarios sin privilegios.[1][5][6]
3. Deshabilite o bloquee la carga de nf_tables si el sistema no requiere la funcionalidad de nftables y el cambio se ha validado por su impacto operativo.[3][4]
4. Limite las capacidades de red privilegiadas, como las rutas de acceso que implican CAP_NET_ADMIN, y reduzca el número de cuentas que pueden manipular el estado del firewall.[5]

Ejemplos de pasos de endurecimiento

Restrinja los espacios de nombres de usuario sin privilegios:

echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-cve-2026-23111.conf
echo 'user.max_user_namespaces=0' >> /etc/sysctl.d/99-cve-2026-23111.conf
sysctl --load /etc/sysctl.d/99-cve-2026-23111.conf

Bloquee la carga del módulo nf_tables cuando sea operativamente seguro:

echo 'install nf_tables /bin/false' > /etc/modprobe.d/disable-nf_tables.conf
rmmod nf_tables 2>/dev/null || true

Si se utiliza una mitigación basada en la carga de módulos, algunas guías recomiendan regenerar el initramfs para que el módulo bloqueado no se cargue durante el arranque temprano.[4]

Nota específica de Ubuntu

Ubuntu documenta las restricciones basadas en AppArmor para los espacios de nombres de usuario sin privilegios como una forma de reducir la superficie de ataque, más que como un sustituto completo de las correcciones del kernel.[6] Un host puede parecer menos expuesto en las pruebas de ejecución porque la ruta de ataque está bloqueada localmente, mientras que la remediación a largo plazo aún requiere instalar el paquete del kernel corregido por el proveedor.[2][6] El script valida la efectividad de las restricciones de AppArmor intentando una invocación real de unshare --user y comprobando si CAP_NET_ADMIN es funcional dentro de un espacio de nombres de usuario+red.

Nota específica de Red Hat

Red Hat enumera explícitamente impedir que el módulo nf_tables se cargue como una mitigación para CVE-2026-23111 cuando ese cambio es apropiado para el entorno.[3] El script detecta esta configuración mediante check_modprobe_deny() y distingue entre una denegación estricta (install nf_tables /bin/false, que bloquea la carga bajo demanda) y una lista negra débil (que no la bloquea). En los sistemas de la familia RHEL, el script también inspecciona el changelog del RPM del kernel en ejecución en busca de una entrada de backport de CVE-2026-23111, lo que permite un veredicto confirmado por el proveedor independientemente del número de versión upstream.

Referencias oficiales

• NVD: Detalle de CVE-2026-23111 [1]
• Seguridad de Ubuntu: CVE-2026-23111 [2]
• Seguridad de Red Hat: CVE-2026-23111 [3]
• Aviso del Centro Canadiense de Ciberseguridad: AL26-011 [4]
• Resumen de la restricción de espacios de nombres de usuario en AppArmor de Ubuntu: Comprensión de la restricción de espacios de nombres de usuario en AppArmor [6]

Alcance y seguridad

Este README y el script que lo acompaña están pensados para la validación defensiva, el inventario y la planificación de mitigaciones. No sustituyen las directrices del proveedor, la verificación a nivel de paquetes ni los procesos estándar de gestión de parches, y no deben utilizarse como sustituto de la aplicación de las correcciones oficiales descritas en los avisos enlazados.[2][3][4]

📚 Repositorio Educativo de Investigación en Seguridad

Un repositorio para aprender, probar e investigar conceptos de ciberseguridad en entornos controlados.

⚠️ Aviso de seguridad y legal

Propósito

Este repositorio es solo para investigación de seguridad educativa y autorizada.

Está diseñado para ayudar a los usuarios a aprender sobre:

• Vulnerabilidades de seguridad
• Conceptos de sandbox y aislamiento
• Prácticas de codificación segura y defensiva

Solo uso autorizado

Use este repositorio solo en entornos donde tenga permiso, como:

• Laboratorios personales o máquinas virtuales
• Entornos Docker o aislados
• Pruebas de penetración autorizadas
• Formación en ciberseguridad o investigación académica

El uso no autorizado o ilegal está estrictamente prohibido.

Sin responsabilidad

El autor y los colaboradores no son responsables de ningún daño, uso indebido, problema legal o pérdida causada por este proyecto.

Al usar este repositorio, usted acepta que:

• Usted es responsable de sus propias acciones
• Lo utilizará de forma legal y ética
• El proyecto se proporciona sin garantía

Uso ético

Este proyecto está pensado para:

• Investigación de seguridad defensiva
• Educación en ciberseguridad
• Concienciación sobre vulnerabilidades
• Investigación de sistemas y software seguros

Por favor, siga las prácticas de divulgación responsable y cumpla con todas las leyes aplicables.

Contacto

Para divulgación responsable o colaboración, contacte con el mantenedor del repositorio a través de GitHub.