DirtyFrag CVE-2026-43284 Validación de PoC y Detección con auditd

Alcance: Validación de escalada local de privilegios (LPE) en Linux centrada en la ruta XFRM/ESP asociada con CVE-2026-43284.

Este repositorio contiene un informe en inglés y artefactos de evidencia de una validación controlada en laboratorio del PoC público DirtyFrag. El enfoque no es proporcionar una guía de explotación, sino documentar qué fue visible en los registros de auditoría de Linux y cómo esos eventos pueden transformarse en lógica práctica de detección para SOC.

Informe PDF completo:

EN: reports/DirtyFrag_CVE-2026-43284_EN.pdf

PL: reports/DirtyFrag_CVE-2026-43284_PL.pdf

Propósito y alcance

La prueba se realizó para verificar si un usuario local normal podía obtener una shell root en una VM de laboratorio vulnerable y para determinar qué eventos se pueden capturar con auditd.

CVE-2026-43284 se relaciona con el manejo incorrecto de fragmentos de página compartidos durante operaciones ESP/IPsec. Bajo condiciones específicas, un atacante local puede influir en los datos de la caché de páginas y escalar privilegios. Ubuntu Security califica esta vulnerabilidad como CVSS 3.1: 7.8 Alta.

Referencias técnicas:

• Repositorio público del PoC DirtyFrag: https://github.com/V4bel/dirtyfrag
• Ubuntu Security - CVE-2026-43284: https://ubuntu.com/security/CVE-2026-43284
• Blog de Ubuntu - Correcciones disponibles para la vulnerabilidad Dirty Frag de Linux: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

Entorno de prueba

Línea base completa del sistema: evidence/logs/system-info-table.md

Resultado

Antes de la ejecución del PoC, el contexto de prueba era una cuenta de usuario normal. Después de ejecutar ./exp, se obtuvo una shell root y se confirmó con whoami e id.

Recopilación de evidencia

Después de la prueba, los registros de auditd y las salidas de resumen se exportaron a un directorio de evidencia local y se copiaron en este repositorio.

Estructura del repositorio

Lógica de detección con auditd

La detección más útil no es un único evento. La señal más fuerte es la cadena completa observada en una ventana de tiempo corta:

user namespace -> vmsplice/splice -> ESP/XFRM -> su -> root shell with AUID of a normal user

Claves de auditd relevantes

Cadena de eventos reconstruida

Ejemplo de correlación SIEM

IF
  dirty_frag_unshare by auid>=1000
  AND count(dirty_frag_vmsplice + dirty_frag_splice by same exe or pid) >= 3 within 600s
  AND MAC_IPSEC_EVENT / XFRM activity within 1200s
  AND (dirty_frag_su_exec OR execve with euid=0 and auid>=1000) within 1200s
THEN
  alert = "Possible DirtyFrag CVE-2026-43284 Linux LPE"
  severity = high/critical

Recomendaciones para SOC

• Parchee el kernel y fuerce el reinicio con el kernel parcheado después de las actualizaciones.
• Recopile telemetría de llamadas al sistema con auditd, Falco, herramientas basadas en eBPF o EDR.
• No genere alertas únicamente con un evento euid=0; esto también detecta el uso legítimo de sudo.
• Correlacione unshare, vmsplice, splice, la actividad XFRM/ESP, su y la creación de procesos root desde una sesión de usuario normal.
• Considere restringir kernel.unprivileged_userns_clone donde la compatibilidad de aplicaciones lo permita.
• Revise si los módulos ESP/IPsec son necesarios en una clase de host determinada y restrinja la carga innecesaria de módulos cuando corresponda.
• Reenvíe los registros a un recolector remoto o SIEM; después de un LPE, el atacante puede modificar los registros locales.
• Supervise la calidad de auditd: lost debe permanecer en 0 durante las pruebas y la monitorización en producción.
• Mantenga un playbook de triaje de LPE en Linux que cubra el aislamiento del host, la recopilación de registros de auditoría, la verificación del kernel en ejecución y la captura de módulos cargados.

Notas

El estado de auditd recopilado mostró lost=2555, lo que significa que algunos eventos de auditoría pueden haberse descartado. La cadena clave sigue siendo visible, pero las pruebas futuras deberían aumentar el backlog de auditoría y confirmar lost=0 antes de ejecutar el PoC.

El informe se centra intencionalmente en CVE-2026-43284 / XFRM/ESP para evitar mezclar el alcance de detección del SOC con otras rutas relacionadas con DirtyFrag.