Los CVE del kernel Linux se disparan: cómo Host.it parchea en caliente sin reiniciar los servidores

Se han sumado dos fenómenos, y conviene separarlos. El primero es administrativo. Desde febrero de 2024 el kernel Linux es una CVE Numbering Authority: muchos issues que antes vivían en listas de correo o en commits ahora salen con un ID público. El catálogo se alargó incluso sin una epidemia súbita de bugs nuevos.

El segundo es técnico, y es lo que ha cambiado el ritmo en los últimos meses. El fuzzing (syzkaller y compañía) lleva años. Lo que ha cambiado es la ayuda de la IA en la búsqueda: agentes que exploran superficies, reducen falsos positivos, ayudan a escribir reproductores y cierran el círculo hasta la publicación. Más ojos automáticos, más CVE. «Gracias» a la IA, en sentido estricto: más vulnerabilidades descubiertas y comunicadas, no un kernel de pronto más frágil.

Qué no es (y qué es) un CVE de kernel

Un CVE de kernel no es un plugin que se pulsa en el panel. Es un identificador de un defecto del sistema operativo bajo WordPress, Joomla, la tienda, el correo. La gravedad se lee caso a caso: no todos los ID son explotables en hosting compartido, y no todos exigen un reinicio inmediato. Lo que ha cambiado es la cadencia: la cola de parches a evaluar ya no es un evento mensual.

La superficie que ve la agencia es CMS, plugins, PHP, certificados. La que puede usar un atacante incluye también el kernel, los drivers, los namespaces, la red. No tenéis que convertiros en hackers de kernel. Tenéis que saber quién parchea qué, en cuánto tiempo y con qué impacto en el uptime.

Tres planos, tres responsabilidades

• Aplicación. Core, temas, plugins: vuestro oficio, o un canon que vendéis. Staging, copias, ventana de verificación.
• Sistema. Kernel, libc, hipervisor: oficio del hoster. Si solo parchea reiniciando, cada CVE serio se vuelve un corte programado.
• Contrato con el cliente. ¿Quién responde si la tienda cae en rebajas? Si no está escrito, lo pagáis en reputación.

Para una agencia con cincuenta o doscientos sitios el kernel es invisible mientras funciona. Se vuelve visible la noche en que diez clientes reciben un timeout a la vez. No es «seguridad en abstracto»: es continuidad del servicio que habéis vendido.

El parche clásico del kernel es fácil de explicar y caro de vivir: instalas, reinicias, esperas a que suban los servicios, compruebas PHP, base de datos y cola de correo. En un servidor es una ventana. En un parque es un calendario de cortes.

Qué paga el cliente (y qué pagáis vosotros)

• Minutos de sitio caído. Un e-commerce en campaña de anuncios no distingue «mantenimiento de kernel» de «hosting poco fiable».
• Ventanas nocturnas. Si cada aviso pide un reboot, las noches se multiplican. El equipo interno o el proveedor tienen que cubrirlas.
• Tickets en cascada. Incluso un reinicio limpio genera alertas de monitorización y llamadas. Cuesta más que el parche.

La alternativa no es ignorar los CVE. Es separar la corrección del reboot: aplicar el parche en memoria cuando se puede, y reservar el reinicio para cuando hace falta un kernel nuevo, no para cada ID publicado un lunes por la mañana.

En Host.it la estrategia está pensada para el uptime de los Clientes, no para la comodidad del calendario interno. Cuando llega un aviso de kernel relevante, aplicamos la corrección en caliente (live / hot patch): el código vulnerable en ejecución se sustituye sin un ciclo de apagado. Los sitios siguen accesibles. No es magia y no elimina todos los reinicios de la vida de un servidor: elimina la necesidad de reiniciar sin parar solo para seguir el ritmo de los CVE.

Qué hacemos, en la práctica

• Evaluación. No todos los CVE de kernel impactan igual en nuestro stack. Priorizamos los que tocan la exposición real de los servicios.
• Parche en tiempo real. Donde el live patching cubre el defecto, la corrección entra en producción sin downtime de hipervisor ni de máquina.
• Reinicio solo cuando hace falta. Un kernel nuevo, una dependencia que el parche en caliente no cubre, una ventana planificada: el reboot sigue siendo una herramienta, no la respuesta por defecto.
• Observabilidad. Vigilamos que los servicios sigan sanos tras el parche. El uptime lo medimos, no lo declaramos en un manifiesto: véase transparencia de uptime.

Vale para la infraestructura de hosting, cloud y VPS: el cliente final no tiene que aprender qué es un live patch. Tiene que encontrar el sitio encendido. Si gestionáis el parque como agencia, la diferencia se ve en los tickets que no llegan. Detalles en seguridad Host.it y en los VPS.

El CVE de kernel es un tema incómodo en reunión mientras lo contáis como tecnología. Se vuelve una partida de tarifa si lo traducís a continuidad, responsabilidad y canon.

• Cláusula de uptime honesta. No prometáis el 100%. Explicad que las actualizaciones de seguridad del sistema no coinciden con ventanas de sitio apagado en cada aviso. Es un motivo concreto para quedarse con un hoster que parchea en caliente.
• Informe de mantenimiento. Una línea en el informe mensual: «kernel actualizado, sin downtime por reboot». El cliente no entiende el CVE; entiende que alguien hizo el trabajo sin cerrarle la tienda.
• Hosting como gobernanza. Con Host Bucket aisláis clientes, revendéis con vuestra marca y mantenéis infraestructura italiana. El parche del kernel no es un extra: forma parte de la fiabilidad que estáis vendiendo.

Ninguna de estas tres cosas la hace un prompt. Las hace una agencia que ha elegido dónde corren los sitios y sabe explicarlo.

Los CVE del kernel Linux seguirán llegando, en parte porque el numerado es más amplio, en parte porque la IA ayuda a encontrarlos antes. Quien responde con un reboot a cada ID acumula downtime. Quien ignora los avisos acumula riesgo. La tercera vía es la que usamos en Host.it: parche en tiempo real, reinicios solo cuando hacen falta, uptime como restricción.

Si gestionáis sitios para terceros, esta es la conversación que hay que tener con el hoster, no con el CMS. Para hablar de vuestro parque: contactadnos. Para el programa de revendedores: hosting para agencias web.