Estos días he tenido una sensación que hacía tiempo que no tenía con Linux: la de estar viendo cómo se abre una grieta que probablemente no es un caso aislado. Primero llegó Copy Fail, una vulnerabilidad crítica del kernel que permitía a un usuario local escalar privilegios hasta root. Apenas una semana después aparece DirtyFrag, otra escalada local de privilegios que afecta a subsistemas distintos, con prueba de concepto pública y con una parte de la cadena todavía pendiente de parche completo en algunas ramas cuando empezó a circular la información.
No creo que la conclusión correcta sea “Linux está roto”. Sería injusto y demasiado simple. Linux sigue siendo una de las piezas de software más auditadas, probadas y mantenidas del mundo. Pero sí creo que estamos entrando en una etapa distinta, más incómoda, en la que vamos a descubrir muchas vulnerabilidades antiguas, profundas y difíciles de detectar con las herramientas tradicionales. Y eso obliga a cambiar la forma en la que administramos sistemas.
DirtyFrag y Copy Fail: dos síntomas de un problema mayor
DirtyFrag ha sido descrita por Hyunwoo Kim, conocido como V4bel, como una clase de vulnerabilidades que encadena dos fallos de escritura en la caché de páginas del kernel: uno relacionado con xfrm-ESP, asociado a IPsec, y otro vinculado a RxRPC. La primera parte ha recibido el identificador CVE-2026-43284 y ya cuenta con corrección en mainline; la segunda aparece reservada como CVE-2026-43500 para seguimiento. Según Red Hat, estas vulnerabilidades permiten que un usuario con cuenta local pueda activar los fallos y obtener privilegios de administrador.
El detalle que más debería preocupar a cualquier administrador Linux es que DirtyFrag no se presenta como un exploit frágil basado en una carrera de tiempos difícil de reproducir. Su autor lo describe como un bug lógico determinista, sin necesidad de race condition y con alta tasa de éxito cuando se cumplen las condiciones. En sistemas multiusuario, servidores compartidos, nodos Kubernetes, runners de CI/CD o entornos donde se ejecuta código de terceros, esa diferencia importa mucho.
Copy Fail, por su parte, ya había dejado el aviso. CVE-2026-31431 afecta al subsistema criptográfico del kernel, concretamente a algif_aead, y permite corromper la caché de páginas de archivos legibles, incluidos binarios setuid, lo que puede terminar en ejecución con privilegios de root. Microsoft explicó que el fallo puede ser usado por usuarios sin privilegios para alterar la caché de cualquier archivo legible y escalar privilegios en Linux.
La conexión entre ambos casos no es solo temporal. DirtyFrag y Copy Fail se mueven en una zona técnica parecida: operaciones in-place, page cache, fragmentos compartidos, rutas rápidas de rendimiento y supuestos de propiedad de memoria que, al combinarse mal, permiten escribir donde no debería poder escribirse. Es la misma clase de lección que ya nos dio Dirty Pipe en 2022: un pequeño error en la forma de tratar páginas compartidas puede convertirse en una escalada total de privilegios.
Y aquí es donde creo que debemos mirar más allá del parche concreto. Copy Fail y DirtyFrag no son solo dos CVE para añadir al inventario. Son una señal de que el kernel Linux, como cualquier pieza enorme de software con décadas de evolución, guarda todavía rutas oscuras que pueden contener errores de alto impacto. Algunos nacieron de optimizaciones razonables. Otros de interacciones entre subsistemas. Otros, probablemente, de cambios que parecían seguros por separado, pero no cuando se combinan años después con nuevas rutas de ejecución.
La IA está acelerando el descubrimiento de fallos antiguos
Hace poco escribía sobre Mozilla, Firefox y Claude Mythos Preview. Mozilla corrigió en abril 423 bugs de seguridad en Firefox, una cifra muy superior a la habitual. De ellos, 271 se atribuyeron al uso de Claude Mythos Preview en Firefox 150, dentro de una tubería de análisis propia que combinaba modelos de IA, fuzzing, generación de casos de prueba, triage humano y proceso completo de parcheo.
Lo relevante no era solo la cifra. Mozilla publicó ejemplos de bugs de 15 y 20 años, sandbox escapes y vulnerabilidades que habían sobrevivido durante mucho tiempo a fuzzing y revisión humana. La conclusión que saqué entonces es la misma que refuerzo ahora con Linux: la IA no solo va a encontrar fallos nuevos. Va a encontrar fallos viejos que llevaban años esperando en código crítico.
Copy Fail fue descubierto con ayuda de análisis asistido por IA, según la cobertura técnica publicada sobre el caso. DirtyFrag aparece justo después, motivado por esa misma línea de investigación y dentro de una familia de errores relacionada. Esto no significa que todos los bugs vayan a salir automáticamente ni que la IA sustituya al investigador humano, pero sí cambia la velocidad y la escala del descubrimiento.
Esta es la parte que más me preocupa de cara a lo que viene. Si los equipos defensivos pueden usar IA para encontrar vulnerabilidades antiguas, los atacantes también. La ventaja estará en quién lo haga antes, quién tenga capacidad de parchear más rápido y quién tenga una arquitectura preparada para resistir cuando aparezca una nueva PoC pública.
Durante años hemos trabajado con una idea relativamente cómoda: descubrir un bug profundo en el kernel o en un navegador requería muchísimo conocimiento, tiempo y paciencia. Eso elevaba el coste para el atacante. Ahora ese coste empieza a bajar. No desaparece, pero baja. Y cuando baja el coste de encontrar vulnerabilidades, sube la presión sobre todos los equipos de sistemas, seguridad y desarrollo.
La escalada local ya no es un riesgo menor
Hay una frase que escucho a veces y que me parece peligrosa: “es local, no es tan grave”. En 2026, local no significa lo que significaba hace veinte años. Local puede ser un contenedor comprometido. Un runner de CI que ejecuta código de un pull request. Una aplicación web con ejecución limitada. Un usuario SFTP. Un notebook de datos. Un servicio interno con permisos bajos. Un pod en Kubernetes. Un proceso en una máquina de desarrollo compartida.
Si desde cualquiera de esos puntos un atacante puede convertirse en root, el problema deja de ser menor. Una LPE fiable puede ser la pieza que convierte una intrusión limitada en control completo del host. En entornos cloud, hosting, Kubernetes, laboratorios, plataformas de datos o sistemas multi-tenant, eso puede romper el aislamiento sobre el que se apoya toda la arquitectura.
Por eso DirtyFrag y Copy Fail deberían activar una revisión práctica. No basta con mirar si tenemos “servidores expuestos a Internet”. Hay que mirar qué hosts ejecutan código no confiable, qué nodos tienen contenedores con capacidades amplias, qué runners compilan código de terceros, qué sistemas permiten user namespaces no privilegiados, qué módulos del kernel están cargados y qué kernels están realmente ejecutándose.
La palabra “realmente” es importante. Instalar el paquete del kernel no significa estar protegido. En Linux, si no reinicias o no haces un cambio controlado al kernel corregido, sigues ejecutando el kernel vulnerable. Esto es básico, pero en producción pasa más de lo que queremos admitir. Se actualiza, se deja el reboot para la próxima ventana y el riesgo sigue ahí.
Qué deberíamos hacer desde ya
Lo primero es inventario. Saber qué kernels tenemos, en qué versiones, en qué distribuciones y con qué módulos cargados. Servidores físicos, máquinas virtuales, nodos de contenedores, Proxmox, Kubernetes, runners de CI/CD, bastiones, servidores de desarrollo y entornos de laboratorio. Lo que no está inventariado no se puede parchear bien.
Lo segundo es priorizar. No todos los sistemas tienen el mismo riesgo. Un servidor aislado, sin usuarios locales y con servicios muy controlados, no tiene la misma exposición que un nodo Kubernetes con workloads de terceros o un runner que ejecuta código de ramas externas. Los primeros parches y reinicios deben ir donde una escalada local tenga más opciones de convertirse en compromiso real.
Lo tercero es aplicar mitigaciones temporales solo con criterio. En DirtyFrag se han recomendado bloqueos de módulos como esp4, esp6 o rxrpc, y algunos avisos amplían el foco a módulos relacionados con IPsec. Pero deshabilitar módulos puede romper servicios legítimos. Si una organización usa IPsec, AFS/RxRPC o funciones concretas del kernel, hay que probar antes de aplicar una mitigación a ciegas.
Lo cuarto es parchear y reiniciar. Sin drama, pero con urgencia. En sistemas con alta disponibilidad, esto debería formar parte de una rutina: drenar nodos, migrar cargas, reiniciar de forma escalonada, comprobar uname -r y validar que el kernel en ejecución es el corregido. En sistemas sin alta disponibilidad, toca valorar ventanas extraordinarias cuando la exposición lo justifique.
Lo quinto es endurecer contenedores y CI/CD. Menos contenedores privilegiados. Menos capacidades Linux innecesarias. Menos hostPath. Menos runners compartidos sin aislamiento fuerte. Más seccomp, AppArmor o SELinux. Más separación entre workloads confiables y no confiables. Más cuidado con pipelines que ejecutan código externo.
Y lo sexto, aunque parezca de otro tema, es reforzar copias de seguridad y recuperación. Una escalada a root puede terminar en borrado, cifrado, manipulación de datos o persistencia. Los backups inmutables, las pruebas de restauración, la segmentación y la monitorización siguen siendo esenciales. La IA nos ayudará a encontrar bugs, pero no va a restaurar por nosotros una infraestructura mal preparada.
Lo que viene no será tranquilo
Mi impresión es que DirtyFrag y Copy Fail son solo el principio de una etapa de descubrimiento acelerado. Igual que Mozilla ha usado modelos como Claude Mythos Preview para revisar Firefox a una escala que antes parecía impensable, vamos a ver análisis similares sobre kernels, librerías, hipervisores, herramientas de red, software de backup, paneles de administración, bases de datos y proyectos open source críticos.
Eso es bueno y malo a la vez. Bueno porque podremos cerrar vulnerabilidades antiguas. Malo porque durante un tiempo van a aparecer muchas más, y no todas llegarán con una coordinación perfecta ni con parches listos para todo el mundo. Los embargos se romperán, las PoC circularán rápido y los equipos pequeños tendrán dificultades para seguir el ritmo.
Aquí también hay una cuestión de equidad tecnológica. Las grandes corporaciones ya tienen acceso temprano a modelos, laboratorios, equipos de red team, herramientas internas y capacidad para auditar millones de líneas de código. Las pymes, los proveedores pequeños, los mantenedores open source y muchas empresas medianas no pueden quedarse en desventaja. Si las IAs capaces de encontrar vulnerabilidades profundas solo se abren a unos pocos, la brecha defensiva será enorme.
Necesitamos que estas capacidades lleguen, con controles y responsabilidad, a más organizaciones. No para publicar exploits ni para convertir la seguridad en una carrera de titulares, sino para auditar código, validar parches, revisar dependencias y proteger infraestructuras reales. La seguridad de Internet no depende solo de Microsoft, Google, Amazon, Mozilla o Red Hat. También depende de miles de proyectos pequeños y medianos que sostienen servicios críticos sin grandes equipos detrás.
Linux no está muerto ni roto. Pero el mensaje es claro: ya no podemos administrar sistemas como si el kernel fuese una caja negra intocable que se actualiza cuando toca. El kernel es una superficie viva, compleja y crítica. Y la nueva generación de IA aplicada a seguridad va a mirar dentro con una profundidad que antes estaba reservada a muy pocos investigadores.
La pregunta no es si aparecerán más DirtyFrag o Copy Fail. Aparecerán. La pregunta es si estaremos preparados para responder más rápido, con mejores procesos y con menos improvisación. Porque lo que viene no va de miedo a la IA. Va de usarla antes de que la usen contra nosotros.
Preguntas frecuentes
¿DirtyFrag permite atacar Linux desde Internet directamente?
No directamente. DirtyFrag es una escalada local de privilegios. El atacante necesita ejecutar código en el sistema, pero ese punto inicial puede venir de un contenedor, un runner de CI/CD, una aplicación comprometida o un usuario con permisos limitados.
¿Qué relación tiene DirtyFrag con Copy Fail?
Ambos fallos afectan a zonas sensibles del kernel relacionadas con escrituras indebidas en la caché de páginas y operaciones que no deberían modificar datos compartidos. DirtyFrag se presenta como una extensión de la misma familia conceptual que Dirty Pipe y Copy Fail.
¿Por qué se habla de IA en este contexto?
Porque herramientas avanzadas de IA ya están ayudando a descubrir vulnerabilidades complejas en software crítico. Mozilla ha mostrado cómo Claude Mythos Preview y otros modelos ayudaron a encontrar cientos de bugs en Firefox, y Copy Fail también se ha vinculado a análisis asistido por IA.
¿Qué debería hacer una empresa ahora?
Inventariar kernels, revisar módulos cargados, priorizar sistemas multiusuario o con contenedores, aplicar mitigaciones de proveedor, actualizar y reiniciar, endurecer CI/CD y reforzar backups, monitorización y recuperación.
La entrada DirtyFrag, Copy Fail y el aviso que Linux no puede ignorar aparece primero en Carrero.
