Fragnesia: una LPE determinista que entrega root en Linux sin condición de carrera.

// 01 — RESUMENQué es Fragnesia.

Fragnesia es la vulnerabilidad CVE-2026-46300 (CVSS 7.8) reportada por William Bowling del equipo V12 Security. Vive en el subsistema XFRM ESP-in-TCP del kernel Linux y permite que un usuario local sin privilegios modifique contenido de archivos read-only en el page cache y obtenga root de forma determinista.

A diferencia de Dirty Frag y Copy Fail, Fragnesia no depende de una condición de carrera: es un bug lógico que entrega una primitiva de escritura arbitraria byte-a-byte sobre páginas de cache. El PoC público corrompe el binario /usr/bin/su en memoria y entrega una shell root inmediata en distribuciones mayores.

Fragnesia convierte cualquier foothold local — un job de CI, un container, una credencial SSH — en root del host con un exploit determinista, sin esperar timing. BlackDoor Research · 14 de mayo de 2026

// 02 — IMPACTOPor qué importa más que Dirty Frag.

El patrón Copy Fail → Dirty Frag → Fragnesia es la misma familia: escritura ilícita sobre el page cache vía rutas zero-copy mal acotadas. Lo nuevo en Fragnesia es la fiabilidad. Las cadenas anteriores requerían condiciones de carrera o módulos específicos cargados; esta entrega root en el primer intento.

• Distros afectadas: AlmaLinux, Amazon Linux, CloudLinux, Debian, Gentoo, Red Hat Enterprise Linux, SUSE y Ubuntu, según el reporte original.
• Runners self-hosted: un pipeline que ejecuta código de terceros pasa de riesgo aislado a compromiso completo del runner — y de los secretos que pase por él.
• Kubernetes multi-tenant: si un pod logra ejecutar código arbitrario, romper la barrera con el nodo deja de ser hipotético.
• SaaS con ejecución de código: notebooks, sandboxes, evaluadores de código y plugins son ahora prioridad alta.
• Workstations Linux: dev boxes con acceso a kubeconfigs, llaves SSH y credenciales productivas heredan el mismo riesgo.

// 03 — PRIORIZACIÓNQué revisar primero.

El triage es el mismo que para Dirty Frag, pero con menos margen: el exploit es determinista, no hay carrera que pueda fallar.

1. CI/CD self-hosted que procesa pull requests externos, builds de proveedores o artefactos no firmados.
2. Nodos Kubernetes con cargas multi-equipo, multi-cliente o ambientes compartidos en el mismo kernel.
3. Hosts con cuentas shell: bastiones, hosting compartido, sandboxes de soporte, accesos de proveedores.
4. Hosts con IPsec/xfrm habilitado: si ya aplicaste mitigaciones por Dirty Frag, valida que sigan vigentes.
5. Workstations de SRE, DevOps y administradores con material sensible montado o cacheado.

// 04 — MITIGACIÓNQué hacer hoy.

La solución correcta es aplicar el kernel corregido de tu distribución y reiniciar. Mientras los backports llegan, las medidas reportadas son las mismas que para Dirty Frag, más algunas defensas adicionales que reducen la superficie:

• Bloquear módulos vulnerables: esp4, esp6 y funcionalidad xfrm/IPsec donde no se use. Evalúa el impacto sobre VPNs antes de aplicar masivamente.
• Restringir user namespaces no privilegiados: AppArmor en Ubuntu/Debian permite acotar parcialmente el vector.
• Reducir acceso shell local: retira cuentas innecesarias en bastiones, hosting y servidores con terceros.
• Hardening de containers: revisa seccomp, capabilities, --privileged, hostPID/hostNetwork y montajes sensibles.
• Monitoreo de escalada: sube prioridad a alertas de cambios de UID inesperados y ejecución anómala de binarios setuid.

# Mitigación temporal — bloqueo de módulos asociados a la cadena
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall xfrm_user /bin/false\n' > /etc/modprobe.d/fragnesia.conf
rmmod esp4 esp6 2>/dev/null || true

# Ubuntu / Debian: restringir user namespaces no privilegiados
sysctl -w kernel.unprivileged_userns_clone=0

# Validar kernel activo después del parcheo
uname -r

No ejecutes el PoC público en producción. Si necesitas validar exposición, usa un entorno representativo, aislado y con autorización explícita.

// 05 — VALIDACIÓNQué mirar después.

Después del parche o mitigación, revisa la ventana de exposición y reduce probabilidad de repetición. La superposición con Dirty Frag amplía la ventana sospechosa hasta el 7 de mayo de 2026.

• Shells y procesos: shells privilegiadas inesperadas, escaladas de UID, ejecución anómala de su, sudo o binarios setuid.
• Integridad de binarios críticos: verifica con rpm -Va, debsums o controles AIDE/Tripwire si /usr/bin/su u otros archivos clave fueron alterados en RAM (el page cache no persiste, pero los efectos sí).
• Jobs de CI/CD: revisa builds no confiables ejecutados desde el 7 de mayo de 2026 en runners persistentes.
• Pods y nodos K8s: reconstruye imágenes y nodos efímeros que ejecutaron código de terceros.
• Módulos cargados: confirma con lsmod | grep -E 'esp4|esp6|xfrm' que los bloqueos quedaron efectivos tras reboot.