SiteGround corrigió 5 vulnerabilidades críticas del kernel de Linux en 48 horas, sin tiempo de inactividad

Las últimas semanas han sido intensas para quienes se dedican a administrar servidores Linux. Entre finales de abril y mediados de mayo, investigadores de seguridad revelaron cinco graves vulnerabilidades del kernel, cada una de las cuales otorgaba a cualquier usuario conectado acceso root completo a la máquina. Varias de ellas incluían código de explotación funcional publicado desde el primer día.

SiteGround aplicó correcciones para todas ellas en nuestra infraestructura de hosting sin reiniciar ningún servidor y sin interrumpir el servicio de ningún cliente.

¿Qué habría significado esto para tus sitios web?

En pocas palabras: si alguna de estas vulnerabilidades se hubiera explotado en un servidor antes de ser parcheada, un atacante que ya tuviera incluso el más mínimo acceso (un plugin de WordPress comprometido, una contraseña FTP filtrada, un script vulnerable) podría haber escalado desde una sola cuenta con privilegios limitados dentro de un sitio hasta obtener el control total del servidor subyacente. A partir de ahí, el procedimiento habitual: leer los archivos de otros usuarios, instalar puertas traseras persistentes, obtener credenciales y penetrar aún más en la red.

Estos no son riesgos teóricos. Existía código de explotación público para cada una de estas vulnerabilidades. Copy Fail, en particular, se estaba utilizando activamente a los pocos días de su divulgación.

¿Qué sucedió realmente?

En orden aproximado, esto es lo que afectó al mundo Linux:

29 de abril, se reveló la vulnerabilidad Copy Fail (CVE-2026-31431): un script de Python de 732 bytes podía convertir a cualquier usuario normal en root en prácticamente todas las distribuciones de Linux lanzadas desde 2017. Sin trucos de sincronización ni conjeturas, solo un fallo lógico en el subsistema criptográfico del kernel. CISA la añadió a su lista de vulnerabilidades explotadas activamente en cuestión de días.

7 de mayo, se reveló la vulnerabilidad Dirty Frag (falla xfrm/ESP, CVE-2026-43284): una vulnerabilidad en el código de red IPsec ESP del kernel que permitía a un atacante escribir datos arbitrarios en la copia en memoria de archivos del sistema de solo lectura. A menudo se la conoce como “Copy Fail 2”.

7 de mayo, se reveló la vulnerabilidad Dirty Frag (falla RxRPC, la segunda parte de la cadena): un fallo relacionado en el módulo de red RxRPC del kernel. En combinación con la vulnerabilidad xfrm/ESP mencionada anteriormente, otorga a un usuario normal acceso root completo.

13 de mayo: Fragnesia / Copy Fail 3.0 (CVE-2026-46300) revelada: el tercer error en tres semanas, de la misma familia que Dirty Frag, también en el subsistema IPsec del kernel. Se publicó una prueba de concepto funcional el mismo día.

14 de mayo: fallo en ssh-keysign / chage pidfd revelado y parcheado por Linus Torvalds: un tipo diferente de error, no una escalada de root, pero permitía que cualquier usuario sin privilegios leyera archivos propiedad de root como /etc/shadow  (los hashes de contraseñas) y claves de host SSH.

Cómo lo solucionamos sin interrupciones del servicio

Las cuatro decisiones que tomamos sobre cómo opera SiteGround hicieron que esto fuera manejable, y teniendo en cuenta lo que está por venir, las cuatro van a ser aún más importantes, no menos.

Monitoreamos constantemente el panorama de amenazas. Nuestro equipo de seguridad monitoriza las listas de correo del kernel, las fuentes CVE y los canales de divulgación las 24 horas del día. Nos enteramos de Copy Fail el mismo día de su divulgación, de Dirty Frag el mismo día de su lanzamiento y de Fragnesia a las pocas horas de que se publicara la prueba de concepto. No hay nada que sustituya a la vigilancia en tiempo real: para cuando estas noticias llegan a los principales medios tecnológicos, el código de explotación suele llevar ya varios días circulando. A medida que el descubrimiento impulsado por IA acelera el ritmo de divulgación, este tipo de monitorización constante se vuelve esencial, no opcional.

Contamos con ingenieros disponibles las 24 horas del día, los 7 días de la semana. Los parches críticos del kernel no esperan al horario laboral, y nosotros tampoco. Para cada una de estas vulnerabilidades, desarrollamos, probamos e implementamos parches en toda nuestra infraestructura en un plazo de 48 horas desde su divulgación pública, generalmente mucho antes de que la mayoría de las distribuciones hubieran lanzado sus paquetes oficiales.

Utilizamos la aplicación de parches al kernel en tiempo real. Esta es la parte más importante para ti. La aplicación tradicional de parches al kernel requiere un reinicio, lo que implica tiempo de inactividad para todos los servicios que se ejecutan en la máquina. La aplicación de parches en tiempo real aplica la solución al kernel en ejecución en memoria, por lo que la vulnerabilidad se corrige sin reiniciar nada. Tus sitios web, bases de datos, correo electrónico y sesiones SSH siguieron funcionando durante todos estos ciclos de parches. Cuando aumenta la frecuencia de los parches, también aumenta el costo de “simplemente reiniciar el servidor”; la aplicación de parches en tiempo real es lo que mantiene ese costo en cero para ti.

Mantenemos nuestros kernels optimizados. Una de las principales razones por las que estos errores son peligrosos es que el código vulnerable viene habilitado por defecto en la mayoría de las distribuciones. Copy Fail residía en la interfaz criptográfica del kernel AF_ALG. Dirty Frag y Fragnesia residían en los módulos esp4, esp6 y rxrpc, código de red IPsec y AFS que la gran mayoría de los servidores web jamás utilizarán. No cargamos módulos del kernel que no necesitamos. Esto significa que una parte importante de la superficie de ataque para estas vulnerabilidades simplemente no existía en nuestras máquinas, lo que nos da margen de maniobra para aplicar la solución adecuada.

El factor IA: y por qué esto es solo el principio

Un detalle en la divulgación de Copy Fail merece especial atención. El error no fue descubierto por un investigador humano que analizó el código durante semanas. Fue detectado por una herramienta de auditoría de código con IA (Xint Code) en aproximadamente una hora de escaneo del subsistema criptográfico del kernel de Linux. El mismo escaneo también reveló “otros fallos de alta gravedad, aún en proceso de divulgación coordinada”, lo que significa que hay más divulgaciones en curso.

Esto supone un cambio radical en la forma de detectar vulnerabilidades. Durante años, el principal obstáculo para descubrir errores críticos del kernel era el número limitado de expertos dispuestos a dedicar meses a leer el código fuente del kernel. Ese obstáculo ha desaparecido. Las herramientas de auditoría con IA ahora pueden escanear subsistemas completos a velocidad de máquina y están encontrando fallos que han permanecido en kernels estables durante casi una década.

En la práctica, esto significa que la frecuencia de divulgación de vulnerabilidades graves seguirá aumentando. Tres exploits universales de acceso root local en tres semanas no son una casualidad, sino un anticipo. Los ciclos de parcheo reactivos que funcionaban cuando se detectaba un fallo crítico del kernel cada seis meses ya no serán efectivos cuando se detecte uno cada dos semanas. La capacidad de detectar, reaccionar y parchear en cuestión de horas, en lugar de días, ya no es un lujo, sino el requisito fundamental para la seguridad.

Conclusión

Linux está atravesando un período inusualmente difícil en cuanto a la seguridad del kernel: tres exploits universales de root local en tres semanas no es normal, y la situación no mejora. Con herramientas de auditoría basadas en IA que ahora escanean el kernel a una velocidad inalcanzable para cualquier equipo humano, prevemos que la tasa de descubrimiento de vulnerabilidades graves seguirá acelerándose. Los errores que han permanecido latentes en kernels estables durante años están saliendo a la luz, subsistema por subsistema.

Lo que podemos prometer es que la forma en que gestionamos estas vulnerabilidades es la misma que utilizamos para todas las vulnerabilidades graves: monitorizar con antelación, aplicar parches rápidamente, solucionar problemas en tiempo real y minimizar la superficie de ataque desde el principio. Tus sitios web permanecen operativos. Los exploits no. Y a medida que la frecuencia de los ataques aumente, esto será aún más importante.