Copy Fail: el bug aburrido que ha cambiado las reglas (y cPanel, de propina)
👻 La Newsletter de @weareDMNTRs 👻
Esta semana la hemos acabado trabajando a tope. Y no porque tocara, sino porque el miércoles, al abrir el correo, ya estaba ahí: CVE-2026-31431, apodada Copy Fail. Una vulnerabilidad en el kernel de Linux que llevaba "durmiendo" desde 2017, que afecta a literalmente todas las distribuciones mainstream desde entonces, y para la que existe un PoC público de 732 bytes.
Sí. Setecientos treinta y dos bytes que convierten un usuario sin privilegios en dueño de cualquier máquina vulnerable. Mismo binario, sin modificar, funcionando en Ubuntu, en Amazon Linux, en RHEL, en SUSE, en Debian, en lo que le pongas delante. Una hora antes éramos un equipo gestionando una semana normal, una hora después, éramos un equipo parcheando servidores contra reloj.
Y por si fuera poco, esta vulnerabilidad no ha venido sola. La misma semana se ha sumado una vulnerabilidad en cPanel que también ha dado bastante guerra a mucha gente que conocemos. Dos golpes seguidos, en infraestructura crítica y en un panel que está, literalmente, en cientos de miles de servidores en todo el mundo. Una semana negra, sin medias tintas. Y aquí estamos, escribiendo esto el viernes, todavía con el café frío al lado del teclado.
Vamos por partes, porque lo que ha pasado esta semana cuenta una historia más grande que dos parches.
Copy Fail no es un bug exótico. Es, casi, lo contrario: es un bug aburrido. Un fallo lógico en una optimización introducida en 2017 en algif_aead, el módulo que expone la API criptográfica del kernel al espacio de usuario a través de AF_ALG. La pincelada técnica para quien la entienda, y para quien no, no pasa nada, sigue leyendo: el bug permite, encadenando AF_ALG con splice(), una escritura controlada de 4 bytes en la page cache del kernel. La page cache es la zona de memoria donde Linux mantiene copias rápidas de los archivos que tiene abiertos. Si consigues escribir ahí, dentro de la página de un binario setuid como /usr/bin/su, lo que ejecuta el siguiente que lo invoque ya no es exactamente lo que hay en disco. Es lo que tú has querido que sea. El binario en disco no se ha tocado. El hash es el mismo. Pero cuando el sistema lo lee, lo lee desde memoria, y en memoria has metido tú lo que te ha dado la gana.
Esta es la parte que da vértigo. No es que sea un bug oculto en un módulo oscuro que nadie usa. Es un bug en código que está presente en todas las distribuciones y que evade las herramientas tradicionales de detección de integridad porque el archivo en disco nunca cambia. Un Tripwire, un AIDE, un escaneo de hashes, todos pasan limpios. Y mientras tanto: "I am root".
En nuestro caso hemos parcheado todos los servidores afectados en una sola mañana, sin impacto al cliente. Lo digo sin pecho hinchado, lo digo porque es exactamente lo que tendría que ser normal y, mirando alrededor, no lo es. Hay equipos que esta semana han ido a ciegas, sin inventario claro de qué versión corre dónde, sin ventanas de mantenimiento pactadas, sin un proceso para empujar parches a escala. Hay quien todavía hoy, domingo, no sabe si está cubierto. Hay quien ni siquiera sabe que tiene que mirarlo.
Y entonces toca la pregunta incómoda. ¿Cuántas vulnerabilidades como Copy Fail existirán todavía, ahora mismo, en el código fuente del kernel de Linux? Un código que, por cierto, no para de crecer. Más subsistemas, más drivers, más capas de compatibilidad, más optimizaciones "in-place" introducidas un viernes por la tarde de hace nueve años por alguien con buena fe que estaba arreglando otra cosa. El kernel de Linux tiene del orden de 40 millones de líneas. Si Copy Fail ha sobrevivido nueve años en una ruta criptográfica core, leído por cientos de reviewers, ¿cuántos primos hermanos tiene esperando? Y si esto lo decimos del kernel de Linux, que es, probablemente, el código más auditado del mundo, ¿qué decimos del resto? ¿De Windows, cuyo código fuente no se audita públicamente? ¿De los kernels propietarios de los grandes fabricantes de hardware de red, los firmwares de los routers que tenemos en casa, los blobs binarios que ejecutan los teléfonos? Si en lo que se ve hay esto, lo que no se ve es un agujero del que mejor no asomarse.
Lo realmente nuevo de Copy Fail no es el bug. El bug es, repito, aburrido. Lo nuevo es cómo se ha encontrado. Lo dice la propia gente de Theori en su web: Copy Fail lo descubrió Xint Code, un sistema basado en LLMs para auditar código, en aproximadamente una hora de escaneo contra el subsistema crypto/ del kernel. Una hora. Una IA. ¡A tomar por culo el mundo!
El mismo escaneo, dicen, sacó otros bugs de severidad alta que todavía están en disclosure coordinado. O sea que puede que nos vengan semanas entretenidas.
Y, lo peor, es que este es solo uno de los modelos que están haciendo esto. En las últimas semanas no paran de bombardearnos con lo que viene: el aluvión de vulnerabilidades que se va a desencadenar gracias a poder estudiar el código fuente con modelos como Mythos, como el nuevo GPT, como Xint, como los que vendrán en los próximos seis meses. Estamos delante de un cambio cualitativo en cómo se descubren bugs, no cuantitativo. Antes hacía falta un investigador con tiempo, ojo y suerte, ahora hace falta un prompt y muchos tokens.
Y la pregunta está clara: ¿estamos preparados para esto? Sinceramente, no. Nosotros, que esta semana hemos parcheado muchos servidores en una mañana, no lo estamos. Y la mayoría del tejido productivo, pymes, administraciones, ese servidor que monta el sobrino del jefe en un VPS y lleva ocho años funcionando porque "funciona", ese tejido no está preparado ni de lejos.
Hasta ahora, el ritmo al que aparecían vulnerabilidades críticas era humano: el ritmo de los investigadores humanos. A ese ritmo, parchear cuando pudieras era una estrategia razonable. La probabilidad de que el bug que tú no parcheaste el martes le importe a alguien antes del viernes era baja. Esa probabilidad va a cambiar. Y va a cambiar rápido.
El otro tema, el que abre la madriguera de conejo, es saber si alguien conocía Copy Fail antes. ¡Joder que llevaba nueve años en producción! Nueve años en un módulo criptográfico expuesto a espacio de usuario en todas las distribuciones. Una primitiva limpia, sin race conditions, sin offsets dependientes del kernel, que evade detección de integridad por diseño.
Si tú fueras una agencia con presupuesto y paciencia y este bug se te hubiera cruzado en algún momento entre 2017 y 2026, ¿lo habrías reportado? ¿O lo habrías guardado en un cajón? No tengo respuesta a esto. Nadie la tiene, salvo quien la tenga. Lo que sí sabemos es que la asimetría existe: hay actores con motivos, con recursos y con la disciplina operativa para sentarse encima de un 0-day durante años, y los hay sin ella. Y cada vez que sale a la luz un bug de este perfil, silencioso, fiable, universal, la pregunta es legítima.
La trampa de esta madriguera es que no tiene fondo. Si empiezas a tirar del hilo, acabas en un sitio donde no puedes confiar plenamente en nada de lo que ejecutas. Y eso es ingobernable. No puedes auditar tú solo el kernel, no puedes reescribir tu stack, no puedes irte a vivir al monte. Lo que sí puedes hacer, y lo que esta semana ha vuelto a recordarnos, es bajar el coste de reaccionar: Tener inventario, tener automatización, tener procesos de parcheo que se ejecuten en horas, no en semanas. Asumir que vas a tener que parchear a ciegas, contra reloj, varias veces al año, y que la próxima quizá no te dé margen para empezar a desayunar tranquilo.
Porque creo, sinceramente, que lo que hemos visto esta semana es el ensayo general. Un bug, encontrado por una IA en una hora, publicado con PoC funcional, afectando a todo lo que importa. La próxima vez serán dos. Y la siguiente, cinco. Y en algún momento será uno que sí sea remoto, sin necesidad de cuenta local, en un servicio que está expuesto en internet en todas partes. Y ese día, los que esta semana tardaron tres días en parchear cPanel, no van a tardar tres días. Van a tardar más. O no podrán parchear nunca, porque su sistema ya no existirá.
Nos vemos la semana que viene. Si todo va bien, con menos servidores parcheados.
¡Feliz Domingo!
🔗 Newsletter patrocinada por: 🔗
Protecting what matters most
🔊 Llámalo podcast... 🔊
Todos los episodios aquí: https://go.ivoox.com/sq/2343562
Y fin...
Si has llegado hasta aquí, enhorabuena: ya sabes más de la salud de la infraestructura que la mayoría de comités de dirección que la pagan. Úsalo con responsabilidad, o al menos con resignación, que es lo que nos queda.
Nosotros nos vamos a desconectar un rato, lo cual en nuestro oficio significa mirar el móvil cada veinte minutos en vez de cada cinco. Si te ha gustado, comparte, responde, o simplemente quédate por aquí.
Volvemos la semana que viene, salvo que el kernel decida lo contrario.
Similar newsletters
There are other similar shared emails that you might be interested in: