Security on KnightLi Blog

SSRF de alta gravedad en Next.js CVE-2026-44578: alcance e indicaciones de actualización

Sun, 17 May 2026 17:27:13 +0800

Next.js divulgó en mayo de 2026 una vulnerabilidad SSRF de alta gravedad: CVE-2026-44578.

Según el aviso de seguridad de GitHub / Vercel GHSA-c4j6-fc7j-m34r y el registro de NVD, el problema afecta a aplicaciones Next.js autoalojadas que usan el servidor Node.js integrado y están expuestas a solicitudes WebSocket upgrade maliciosas. Un atacante podría hacer que el servidor proxifique solicitudes hacia destinos internos o externos arbitrarios, exponiendo servicios internos o endpoints de metadata en la nube.

Los despliegues alojados en Vercel no están afectados. Las versiones corregidas son 15.5.16 y 16.2.5.

Resumen rápido

Si ejecutas Next.js en tus propios servidores, contenedores, Kubernetes, ECS, VPS, bare metal o PaaS autogestionado, revisa esto primero.

Rangos afectados:

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

Casos no afectados o de menor riesgo:

Aplicaciones desplegadas en Vercel.
Aplicaciones actualizadas a 15.5.16, 16.2.5 o versiones posteriores.
Escenarios donde no se expone el servidor Node.js integrado.
Entornos donde el proxy inverso o balanceador ya bloquea WebSocket upgrades innecesarios y el tráfico saliente está restringido.

Orden recomendado de respuesta:

Confirmar la versión de next que realmente corre en producción.
Actualizar las aplicaciones autoalojadas a una versión corregida cuanto antes.
Si no puedes actualizar de inmediato, bloquear WebSocket upgrades innecesarios en el proxy inverso o balanceador.
Restringir el acceso de los servidores de aplicación a metadata cloud, paneles internos y servicios internos sensibles.
Revisar solicitudes WebSocket upgrade recientes y logs de acceso interno.

Qué es la vulnerabilidad

CVE-2026-44578 es una vulnerabilidad Server-Side Request Forgery, o SSRF.

El riesgo central de SSRF es que el atacante no accede directamente a sistemas internos, sino que induce a tu servidor a enviar solicitudes en su nombre. Los servidores suelen estar más cerca de redes privadas, plataformas cloud y servicios internos, por lo que si se convierten en proxy pueden alcanzar recursos que el atacante no podría tocar desde fuera.

En este caso de Next.js, el problema está en la ruta de manejo de WebSocket upgrade. El aviso indica que aplicaciones autoalojadas que usan el servidor Node.js integrado pueden ser forzadas, mediante solicitudes WebSocket upgrade construidas especialmente, a proxificar solicitudes hacia destinos internos o externos arbitrarios.

Los puntos de riesgo incluyen:

Servicios HTTP internos.
Paneles de administración.
Direcciones de metadata cloud.
Servicios internos de contenedores o clústeres.
APIs internas accesibles solo desde el servidor.

La puntuación CVSS v3.1 es 8.6 High, con este vector:

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

Esto significa que el ataque es de red, de baja complejidad, no requiere privilegios ni interacción del usuario, y afecta principalmente a la confidencialidad.

Por qué el autoalojamiento es más peligroso

El aviso afirma explícitamente que los despliegues alojados en Vercel no están afectados.

El foco real son los despliegues autoalojados. La razón es simple: sus entornos de red varían mucho. Algunos exponen directamente el origin server; otros están detrás de Nginx, Traefik, Ingress, Cloudflare, ALB o gateways propios; otros corren en VMs cloud, redes de contenedores o clústeres Kubernetes.

Si esos entornos no restringen el tráfico saliente, el proceso Next.js podría alcanzar:

Direcciones de metadata cloud como 169.254.169.254.
Rangos de IP privados.
Servicios expuestos solo dentro de una VPC.
Redis, Elasticsearch, Prometheus, Grafana y otros componentes internos.
Kubernetes Services, Pods o endpoints de administración.

Por eso el peligro de SSRF no está solo en Next.js, sino en qué puede alcanzar desde la red donde vive.

Cómo saber si estás afectado

Primer paso: revisar la versión de next.

En el directorio del proyecto:

`1`	`npm ls next`

`1`	`pnpm why next`

También puedes inspeccionar:

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

Si la versión cae dentro de estos rangos, hay que actuar:

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

Segundo paso: revisar el modelo de despliegue.

Presta atención a:

Servicios de producción iniciados con next start.
Servidores Node.js personalizados que alojan Next.js.
Imágenes Docker que arrancan directamente un servidor Next.js.
Autoalojamiento en Kubernetes / ECS / VPS / bare metal.
Un origin de Next.js todavía accesible detrás de un proxy inverso.
Redes de aplicación que pueden acceder a servicios internos o metadata cloud.

Si la aplicación está desplegada en Vercel, el aviso oficial indica que no está afectada por esta vulnerabilidad. Aun así, conviene mantener Next.js actualizado, porque versiones cercanas pueden incluir otros parches de seguridad.

A qué versión actualizar

Las versiones corregidas oficiales son:

15.5.16
16.2.5

Ejemplo de actualización:

`1`	`npm install next@15.5.16`

O si usas 16.x:

`1`	`npm install next@16.2.5`

pnpm:

`1`	`pnpm add next@15.5.16`

`1`	`pnpm add next@16.2.5`

Después, reconstruye y publica:

1
2

npm run build
npm run start

O sigue tu flujo CI/CD para reconstruir y publicar la imagen Docker.

Si tu proyecto está fijado en 14.x o 15.x, no conviene saltar apresuradamente a 16.x solo por este parche. Es más seguro actualizar primero a la línea 15.5.16, probar y publicar, y luego planificar una migración de versión mayor.

Mitigaciones temporales

Si no puedes actualizar de inmediato, la idea principal del aviso es: no exponer el origin server directamente a redes no confiables; si WebSocket upgrade no es necesario, bloquearlo en el proxy inverso o balanceador; y restringir en lo posible el tráfico saliente del origin.

Medidas posibles:

No exponer directamente el origin server de Next.js.
Filtrar WebSocket upgrades innecesarios en Nginx, Ingress, ALB, Cloudflare u otros puntos de entrada.
Si el negocio no usa WebSocket, rechazar solicitudes con semántica de upgrade.
Aplicar restricciones de egress para impedir acceso a metadata cloud y rangos internos sensibles.
Usar modos de metadata más seguros ofrecidos por la nube, por ejemplo servicios de metadata que requieren token.
Añadir autenticación y aislamiento de red a paneles administrativos, bases de datos, cachés y sistemas de monitoreo.

Las reglas de proxy inverso son mitigaciones temporales, no sustituyen la actualización. Una vulnerabilidad del framework debe resolverse finalmente con una versión corregida.

Revisión operativa

Como este problema afecta sobre todo a la confidencialidad, la pregunta clave es si el servidor fue usado para alcanzar recursos internos.

Revisa:

Logs web con Upgrade, Connection, Host, rutas o IPs de origen anómalas.
Logs del proxy inverso o balanceador con WebSocket upgrades inusuales.
Conexiones salientes anómalas cerca del servicio Next.js.
Logs de acceso a metadata cloud o uso de credenciales.
Accesos anómalos a servicios internos de administración, monitoreo, caché o búsqueda.
Uso inusual de credenciales temporales IAM, access keys o tokens.
Procesos, descargas o movimientos laterales sospechosos en contenedores o hosts.

Si sospechas explotación:

Conserva logs y evidencia.
Rota credenciales cloud, API keys, contraseñas de bases de datos y session secrets que pudieran haberse expuesto.
Revisa llamadas API recientes en la cuenta cloud.
Comprueba registros de acceso a servicios internos.
Reconstruye contenedores o hosts afectados.
Revisa controles de egress y protección de metadata.

No es lo mismo que el RCE de React/Next.js

Un punto fácil de confundir: CVE-2026-44578 es un SSRF en WebSocket upgrade de Next.js, no el RCE previo relacionado con React Server Components.

Su impacto central es hacer que el servidor solicite direcciones internas o externas elegidas por el atacante. El riesgo principal es exposición de información y exploración de recursos internos.

Los problemas RCE de React Server Components son riesgos de ejecución de código, con consecuencias y rangos de parche distintos.

Por eso no basta con leer “Next.js tiene una vulnerabilidad”. Hay que mapear el CVE concreto con versiones afectadas, modelo de despliegue y versiones corregidas.

Equipos que deben priorizarlo

Prioridad máxima:

Sitios Next.js de producción autoalojados.
Despliegues en VMs cloud, contenedores, Kubernetes o redes internas.
Servidores de aplicación que pueden acceder a servicios de metadata cloud.
Servidores de aplicación que alcanzan paneles internos, bases de datos, cachés o monitoreo.
Origin servers next start expuestos directamente.
Versiones antiguas de next sin proceso claro de actualización.

Prioridad relativamente menor:

Aplicaciones desplegadas completamente en Vercel.
Aplicaciones ya actualizadas a versiones corregidas.
Origins no expuestos directamente, con la capa de entrada bloqueando WebSocket upgrades innecesarios.
Control estricto de salida que impide alcanzar recursos internos sensibles.

Pero “menor prioridad” no significa que no haya que actualizar. Next.js es un componente muy expuesto, y mantener versiones antiguas del framework acumula riesgo.

Checklist para equipos de desarrollo

Puedes seguir esta lista:

Confirmar la versión de next en todos los repositorios.
Identificar todos los despliegues autoalojados, no solo los proyectos en Vercel.
Marcar servicios que usan next start o el servidor Node.js integrado.
Actualizar a 15.5.16, 16.2.5 o posterior.
Reconstruir y publicar imágenes de producción.
Bloquear WebSocket upgrades innecesarios en la capa de entrada.
Restringir acceso de servidores de aplicación a metadata cloud y rangos internos sensibles.
Revisar solicitudes upgrade anómalas recientes y acceso saliente.
Rotar credenciales que pudieran haberse expuesto.
Incluir actualizaciones de seguridad de Next.js en el proceso de actualización de dependencias.

Resumen

CVE-2026-44578 es una vulnerabilidad SSRF de alta gravedad en Next.js que merece atención rápida.

No afecta a despliegues alojados en Vercel, pero sí cubre muchas aplicaciones Next.js autoalojadas: desde 13.4.13 hasta antes de 15.5.16, y desde 16.0.0 hasta antes de 16.2.5. El punto de activación está en el manejo de WebSocket upgrade. Un atacante puede hacer que el servidor proxifique solicitudes hacia direcciones internas o externas, exponiendo servicios internos o endpoints de metadata cloud.

La corrección directa es actualizar a 15.5.16 o 16.2.5. Las mitigaciones temporales son no exponer directamente el origin server, bloquear WebSocket upgrades innecesarios y restringir el tráfico saliente del servidor de aplicación.

Para equipos de operaciones, lo importante no es solo la puntuación CVE, sino qué puede alcanzar tu servidor Next.js desde su posición en la red. En SSRF, el impacto real suele depender de los recursos internos y permisos cloud detrás del servidor.

Referencias:

Dirty Frag, Copy Fail y Fragnesia: comparación de tres fallos recientes de escalada local en Linux

Fri, 15 May 2026 13:24:04 +0800

En las últimas semanas han aparecido varias vulnerabilidades de escalada local de privilegios en el kernel de Linux: Dirty Frag, Copy Fail y Fragnesia. Parecen parte de una misma familia porque el resultado final es parecido: un usuario local con pocos privilegios podría convertirse en root.

Pero desde el punto de vista operativo no conviene tratarlas como una sola vulnerabilidad. Sus módulos de entrada, rutas de activación, mitigaciones y ritmos de parcheo son distintos. Una lectura más precisa es que exponen un riesgo común en la frontera compleja entre la caché de páginas de Linux, splice, socket buffers y rutas criptográficas.

Este artículo solo analiza riesgos y respuesta. No incluye pasos reproducibles de explotación.

Qué Es Cada Vulnerabilidad

Dirty Frag: CVE-2026-43284

Dirty Frag apunta principalmente a un problema de escritura en la caché de páginas dentro de la ruta de red del kernel de Linux. En los análisis públicos suele aparecer junto con dos problemas: el lado xfrm-ESP, CVE-2026-43284, y el lado rxrpc, CVE-2026-43500.

CVE-2026-43284 está relacionado con el descifrado in-place cuando ESP maneja fragmentos skb compartidos. La clave no es que el atacante modifique directamente un archivo en disco, sino que el kernel escribe en páginas compartidas que no debería modificar y termina afectando el contenido del archivo en la caché de páginas.

Desde operaciones, lo importante es recordar que Dirty Frag toca esp4, esp6 y rxrpc, un conjunto de módulos del kernel y rutas del subsistema de red. Está ligado a IPsec, ESP y RxRPC, por lo que la mitigación temporal también gira alrededor de esos módulos.

Copy Fail: CVE-2026-31431

Copy Fail es una vulnerabilidad de escalada local de privilegios en el kernel de Linux divulgada por Theori / Xint Code. Su entrada no está en la ruta de red de IPsec, sino en la API criptográfica de espacio de usuario del kernel alrededor de algif_aead / AF_ALG.

Las explicaciones públicas la atribuyen a una optimización in-place introducida en 2017. En algunos casos, el kernel no copiaba datos como se esperaba y colocaba páginas de la caché en una ruta de destino escribible. Un atacante puede combinar AF_ALG con splice() para realizar una pequeña escritura controlada sobre páginas respaldadas por la caché.

Su riesgo está en la alta explotabilidad y en el impacto sobre varias distribuciones principales. A diferencia de Dirty Frag, la mitigación temporal de Copy Fail se centra en restringir o desactivar algif_aead, y en limitar la creación de sockets AF_ALG en entornos de contenedores y CI.

Fragnesia: CVE-2026-46300

Fragnesia es otra vulnerabilidad de escalada local de privilegios en el kernel de Linux divulgada por V12 Security, dentro de una superficie de ataque parecida a Dirty Frag. No es el mismo bug que Dirty Frag, pero sigue girando alrededor de módulos relacionados con IPsec ESP / rxrpc y efectos de escritura en la caché de páginas.

AlmaLinux la describe como el tercer problema de local-root en la misma zona amplia del código. El punto clave es que skb_try_coalesce() no conservaba correctamente el marcador de fragment compartido al combinar fragmentos de socket buffer, lo que podía permitir que la ruta de recepción XFRM ESP-in-TCP descifrara in-place sobre páginas externas de la caché.

En resumen, Fragnesia está más cerca de Dirty Frag. Ambas giran alrededor de esp4, esp6, rxrpc, fragmentos skb y rutas de descifrado ESP. Sus mitigaciones temporales también se solapan bastante.

Similitudes: Por Qué Son Peligrosas

El punto común no es que el código exacto esté en el mismo lugar, sino que el resultado del ataque y el modelo de riesgo son muy parecidos.

Primero, las tres son escaladas locales de privilegios. Normalmente el atacante necesita primero ejecutar código local como usuario normal y luego intentar convertirse en root. En un escritorio de un solo usuario no es una intrusión remota de un clic; en servidores multiusuario, CI runners, hosts de contenedores, máquinas de desarrollo compartidas y VPS con SSH expuesto, las entradas de bajo privilegio no son raras.

Segundo, las tres se relacionan con escrituras en la caché de páginas. El atacante no siempre modifica de forma permanente el archivo en disco; puede afectar la copia en memoria. Esto reduce la fiabilidad de las revisiones tradicionales de integridad: el hash del disco puede parecer normal mientras la ruta de ejecución lee contenido contaminado desde la caché.

Tercero, se parecen más a bugs lógicos deterministas que a condiciones de carrera sensibles al tiempo. Los materiales públicos insisten en que no requieren ganar una race condition. Los defensores no deberían subestimar la fiabilidad de explotación por experiencia con fallos más antiguos.

Cuarto, amplifican el riesgo en entornos de contenedores y automatización. Código de bajo privilegio dentro de contenedores, jobs de CI, scripts de compilación o plugins de terceros puede convertir un “problema local” en un problema de plataforma si alcanza las interfaces relevantes del kernel del host.

Diferencias: Una Mitigación No Cubre Todo

La mayor diferencia está en el módulo de entrada.

La entrada crítica de Copy Fail es algif_aead / AF_ALG, parte de la API criptográfica de espacio de usuario del kernel. Su defensa temporal se centra en desactivar o restringir algif_aead, y usar seccomp para impedir que los contenedores creen sockets AF_ALG.

La entrada crítica de Dirty Frag está en xfrm-ESP y rxrpc. Está más cerca de las rutas de protocolo y manejo de socket buffers. La defensa temporal suele considerar desactivar esp4, esp6 y rxrpc, pero eso puede afectar IPsec, VPN, túneles o capacidades de red relacionadas.

Fragnesia también está en una zona cercana a Dirty Frag, pero el problema concreto es que skb_try_coalesce() no conservaba el marcador de fragment compartido. Es más bien otra rama de la superficie de riesgo de Dirty Frag, no un problema de la API criptográfica de Copy Fail.

Por eso, haber tratado Copy Fail no significa que Dirty Frag y Fragnesia estén cubiertas. Del mismo modo, desactivar esp4 / esp6 no elimina automáticamente Copy Fail. Hay que confirmar por separado el estado de parches y la estrategia de mitigación.

Cómo Evaluar la Exposición

Para estas vulnerabilidades no basta con mirar el nombre de la distribución ni la versión mayor del kernel. Las distribuciones hacen backport de correcciones, los proveedores cloud mantienen ramas propias del kernel y las distribuciones empresariales pueden llevar parches adicionales.

Un orden más seguro es:

Revisar el aviso de seguridad de la distribución y el changelog del paquete del kernel.
Confirmar si el paquete de kernel actual corrige el CVE correspondiente.
En servidores cloud, hosts de contenedores y nodos de CI, revisar también avisos del proveedor o de la plataforma.
Para mitigaciones temporales, confirmar si el negocio depende del módulo afectado.
Después de actualizar el kernel, programar reinicio y comprobar que el kernel en ejecución cambió.

La trampa más común es “el paquete está actualizado, pero la máquina no se reinició”. Las vulnerabilidades del kernel no son como actualizaciones de servicios de espacio de usuario. Hasta arrancar con el nuevo kernel, el kernel viejo puede seguir ejecutándose.

Prioridad Operativa

Los sistemas más urgentes no son todas las máquinas Linux por igual. Hay que empezar donde es más probable que exista ejecución de código con pocos privilegios.

Entornos de prioridad alta:

Servidores de login multiusuario
CI / CD runners
Máquinas de compilación y empaquetado de artefactos
Hosts de contenedores y nodos Kubernetes
Máquinas de desarrollo compartidas
Servidores cloud y VPS con SSH expuesto
Plataformas que ejecutan scripts, plugins o colas de tareas de terceros
Máquinas con vulnerabilidades web, contraseñas débiles o señales históricas de compromiso

Las máquinas cerradas, de un solo usuario y sin entrada externa de ejecución de código siguen teniendo riesgo si son vulnerables, pero normalmente pueden ir después.

Cómo Entender la Mitigación Temporal

La mitigación temporal no reemplaza al parche. Su valor es reducir la exposición cuando no se puede reiniciar de inmediato o mientras se esperan paquetes de la distribución.

Para Copy Fail, el foco está en algif_aead y AF_ALG. Si el negocio no usa la interfaz criptográfica AF_ALG del kernel, se puede evaluar desactivar el módulo relacionado. En contenedores, conviene revisar primero las políticas seccomp para que cargas no confiables no puedan crear libremente el socket correspondiente.

Para Dirty Frag y Fragnesia, el foco está en esp4, esp6 y rxrpc. Si el sistema no depende de IPsec ESP, VPN relacionadas, túneles o RxRPC, se puede evaluar una desactivación temporal. No debe hacerse a ciegas en producción porque esos módulos pueden sostener cargas de red reales.

El camino final sigue siendo actualizar el kernel. La mitigación temporal reduce superficie de ataque, pero no demuestra que el sistema sea completamente seguro.

Qué Nos Dicen Estos Tres Fallos

La advertencia importante no es solo el número de CVE. Estos fallos se concentran en rutas del kernel muy complejas: zero-copy, splice, socket buffers, caché de páginas, interfaces criptográficas y optimizaciones de pila de protocolos.

Estas rutas dan grandes beneficios de rendimiento, pero también vuelven más difícil mantener los límites de propiedad. Si un fragment está compartido, si una página puede escribirse in-place o si una optimización realmente solo reduce copias se convierte en parte del límite de seguridad.

Para equipos de seguridad y operaciones, las conclusiones son prácticas:

Tratar la escalada local de privilegios como un amplificador de entradas ya existentes de bajo privilegio.
Los contenedores no son una frontera natural de aislamiento frente a vulnerabilidades del kernel.
Las revisiones de integridad no pueden mirar solo el contenido del disco.
CI, máquinas de compilación y plataformas de plugins deben ser activos de alta prioridad.
En parches de kernel hay que verificar tanto “instalado” como “en ejecución”.

Resumen

Dirty Frag, Copy Fail y Fragnesia son eventos recientes de alta prioridad en la escalada local de privilegios de Linux, pero no son tres nombres del mismo fallo.

Copy Fail pasa por la ruta criptográfica algif_aead / AF_ALG. Dirty Frag pasa por xfrm-ESP y rxrpc. Fragnesia, en una superficie cercana a Dirty Frag, vuelve a disparar riesgo de escritura en la caché de páginas por el manejo de marcadores de fragmentos skb.

La respuesta más sólida es actualizar el kernel según los avisos de la distribución y reiniciar. En sistemas que no puedan actualizarse de inmediato, evaluar la desactivación temporal de módulos o reglas seccomp más estrictas según la entrada real de cada vulnerabilidad. Priorizar entornos multi-tenant, CI, hosts de contenedores y desarrollo compartido.

Referencias:

Notas de Theori sobre Copy Fail: https://github.com/theori-io/copy-fail-CVE-2026-31431
Aviso de CERT-EU sobre Copy Fail: https://cert.europa.eu/publications/security-advisories/2026-005/
Notas de AlmaLinux sobre Dirty Frag: https://almalinux.org/blog/2026-05-07-dirty-frag/
Notas de AlmaLinux sobre Fragnesia: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
Notas del PoC de V12 Security sobre Fragnesia: https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300): impacto y mitigación de una escalada local de privilegios en el kernel de Linux

Fri, 15 May 2026 13:18:01 +0800

El kernel de Linux acaba de sumar otra vulnerabilidad de escalada local de privilegios en una superficie de ataque cercana a Dirty Frag: Fragnesia (CVE-2026-46300).

Según la divulgación de V12 Security, Fragnesia es una vulnerabilidad local de Linux. El atacante no necesita privilegios elevados previos en el host. Si puede ejecutar código local, podría aprovechar un fallo lógico en el subsistema XFRM ESP-in-TCP del kernel para modificar, byte a byte, contenido de archivos de solo lectura a través de la caché de páginas y terminar obteniendo un root shell.

Fuente:

Notas del PoC de V12 Security: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

Este artículo no cubre pasos reproducibles de explotación. Se centra en los riesgos y la respuesta operativa.

Relación con Dirty Frag

V12 Security clasifica Fragnesia dentro de la familia de vulnerabilidades Dirty Frag. No es el mismo bug que Dirty Frag, sino otro problema en una superficie de ataque relacionada: XFRM ESP-in-TCP en el kernel de Linux.

XFRM es el marco del kernel de Linux para procesar IPsec. ESP-in-TCP está relacionado con transportar tráfico ESP cifrado sobre TCP. El problema de Fragnesia está en la lógica de fragmentos de página compartidos y la combinación de socket buffers: en ciertas condiciones, el kernel puede perder la pista de que un fragment sigue compartido y dejar una zona de escritura controlable.

Este tipo de fallo recuerda a Dirty Pipe / Dirty Frag y otros problemas de escritura en la caché de páginas. El código concreto no es el mismo, pero el efecto vuelve a caer sobre la copia en caché de un archivo de solo lectura.

Por Qué Es Grave

Fragnesia es peligrosa por tres razones.

Primero, es una escalada local de privilegios. Si un atacante ya puede ejecutar código como usuario normal, podría elevarse a root. Esto es especialmente sensible en servidores multiusuario, hosts de contenedores, CI runners, máquinas de desarrollo compartidas, VPS y entornos que exponen acceso shell.

Segundo, no depende de una condición de carrera tradicional. Las notas de V12 describen una ruta que fuerza el procesamiento ESP-in-TCP sobre páginas de archivo ya incorporadas a un socket buffer mediante splice, lo que permite influir byte a byte en el contenido de la caché de páginas. Eso hace que el riesgo sea práctico, no solo teórico.

Tercero, modifica la caché de páginas, no el archivo en disco. El ejemplo público usa /usr/bin/su como objetivo. Tras una explotación correcta, el archivo en disco no queda modificado de forma permanente; el cambio vive en la memoria. Las revisiones que solo comparan hashes o integridad del disco pueden no ver nada extraño.

Ese es el punto incómodo para los administradores: el archivo parece intacto, pero al ejecutar la copia contaminada desde la caché de páginas puede activarse la escalada.

Alcance Conocido

V12 Security indica que los kernels afectados por Dirty Frag y sin los parches relevantes del 13 de mayo de 2026 también están afectados por Fragnesia. Los entornos verificados públicamente incluyen Ubuntu 22.04, Ubuntu 24.04 y kernels como 6.8.0-111-generic.

Hay dos matices importantes.

Primero, no basta con mirar la versión mayor de la distribución. Que Ubuntu 22.04 / 24.04 esté afectado depende del estado real de parches del kernel, no solo del nombre de la distribución.

Segundo, no conviene confiar únicamente en las restricciones predeterminadas de AppArmor para namespaces de usuario sin privilegios. En Ubuntu pueden elevar la barrera, pero la divulgación las trata como un problema adicional de bypass, no como una corrección del fallo.

La forma fiable de decidir sigue siendo revisar los avisos de seguridad de la distribución y las actualizaciones del paquete del kernel.

Mitigación Temporal

Si un sistema no puede actualizar el kernel de inmediato, primero hay que evaluar si depende de los módulos de protocolo relacionados.

La mitigación indicada por V12 es la misma que para Dirty Frag: si el sistema no depende de IPsec ESP ni de RxRPC, se puede evaluar desactivar módulos como esp4, esp6 y rxrpc. Esto puede afectar capacidades de red, así que no debe aplicarse a ciegas en producción. Antes hay que confirmar si el negocio usa IPsec, VPN, túneles o funciones relacionadas del kernel.

Un orden de respuesta más seguro es:

Confirmar si la distribución ya publicó una actualización de seguridad del kernel.
Instalar primero el parche del kernel y programar el reinicio.
Si no se puede actualizar de inmediato, evaluar la desactivación temporal de módulos.
Priorizar sistemas multiusuario y entornos de CI / compilación.
Revisar cuentas locales innecesarias, shell, superficie de escape de contenedores y entradas de ejecución de bajo privilegio.

No hay que tratar la desactivación de módulos como corrección final. Es una reducción temporal de exposición.

Si Se Sospecha Explotación

Una característica de Fragnesia es la contaminación de la caché de páginas. V12 señala que, tras la explotación, la copia del archivo objetivo en la caché puede contener contenido inyectado, y ejecuciones posteriores pueden seguir comportándose de forma anómala hasta que la página sea expulsada o el sistema se reinicie.

Si se sospecha que el sistema fue explotado, conviene al menos:

Preservar logs y registros de auditoría cuanto antes.
Revisar inicios de sesión locales anómalos, actividad de usuarios de bajo privilegio, procesos sospechosos y rastros de root shell.
Limpiar la caché de páginas relevante o reiniciar directamente.
Actualizar a un kernel corregido.
Verificar binarios críticos, pero sin depender solo de hashes del disco.
Rotar credenciales y claves potencialmente expuestas.

En servidores de producción, es mejor tratarlo como un posible incidente de escalada local de privilegios, no solo como una actualización rutinaria.

Qué Máquinas Priorizar

La prioridad no debe repartirse por igual entre todas las máquinas Linux. Hay que empezar por los lugares donde un atacante tiene más probabilidades de obtener ejecución de código con pocos privilegios.

Entornos de mayor prioridad:

Servidores de login multiusuario
CI / CD runners
Máquinas de compilación
Máquinas de desarrollo compartidas
Hosts de contenedores
VPS y servidores cloud
Nodos de borde con SSH expuesto
Plataformas que ejecutan scripts o plugins de terceros

Las máquinas cerradas, de un solo usuario y sin entrada externa de ejecución de código siguen teniendo riesgo si son vulnerables, pero la urgencia puede ser menor.

Resumen

Fragnesia merece atención no por tener un nombre nuevo, sino porque vuelve a llevar la escalada local de privilegios en Linux a una frontera compleja: la caché de páginas y los subsistemas de red del kernel.

Para administradores, lo importante no es estudiar los detalles de explotación, sino confirmar el estado de parches del kernel, evaluar si se depende de ESP / RxRPC, actualizar primero las máquinas más expuestas y entender que “el archivo en disco no cambió” no significa “el sistema no fue afectado”.

Si el sistema está afectado, la respuesta final sigue siendo instalar cuanto antes la actualización del kernel ofrecida por la distribución. Desactivar módulos temporalmente es solo una medida puente, no un reemplazo del parche.