Linux, vulnerabilidades críticas y el problema de las actualizaciones en empresas
Las dos vulnerabilidades más críticas detectadas este último mes en entornos Linux han vuelto a poner sobre la mesa uno de los mayores problemas actuales en infraestructura y ciberseguridad: cómo mantener sistemas seguros sin romper producción.
En Cloud Levante, analizamos técnicamente estos vectores de ataque y, sobre todo, por qué la solución no siempre es tan simple como ejecutar un comando de actualización.
Las dos vulnerabilidades Linux más críticas de este último mes
Esta vulnerabilidad afecta al subsistema criptográfico del kernel de Linux, concretamente al módulo algif_aead. Aunque el fallo existe desde 2017, no fue descubierto ni corregido hasta abril de 2026.
El problema reside en un error de lógica que permite a un usuario sin permisos de administrador modificar de forma controlada una pequeña zona de la memoria temporal del sistema. Al apuntar esa modificación a la zona donde reside un programa crítico —como el comando que gestiona permisos de administrador— el atacante puede alterar temporalmente su comportamiento y obtener acceso total al servidor de forma inmediata. El archivo original en disco no se toca; solo su copia cargada en memoria.
El riesgo en entornos cloud es especialmente alto. En arquitecturas modernas, múltiples contenedores comparten el mismo sistema operativo base del servidor. Un atacante que comprometa un solo contenedor puede escalar hasta tener control total del servidor físico y acceder al resto de aplicaciones que corren en él.
- Actualizar el kernel a las versiones corregidas, disponibles desde el 1 de abril de 2026.
- Como medida temporal, desactivar el módulo afectado con el siguiente comando:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.confEsta es posiblemente la vulnerabilidad más grave de 2026 para el sector del hosting. Afecta a cPanel & WHM, el panel de administración de servidores web más extendido del mundo.
El problema es un fallo en el proceso de inicio de sesión que permite a un atacante manipular la petición de acceso para que el sistema lo identifique directamente como administrador, sin necesidad de introducir contraseña ni superar el doble factor de autenticación. En la práctica, es como si alguien pudiera entrar a tu servidor sin llave y el sistema de alarma ni siquiera se activase.
Una explotación silenciosa durante tres años. Se ha confirmado que este fallo fue aprovechado activamente desde febrero de 2023 hasta que fue corregido el 28 de abril de 2026, sin que la mayoría de afectados lo supiera. Se estima que 1,5 millones de servidores estuvieron expuestos durante ese periodo.
- Actualizar cPanel/WHM a la versión más reciente de forma inmediata.
- Revisar los registros de acceso en busca de sesiones sospechosas creadas entre febrero de 2023 y mayo de 2026.
El problema real: el coste de actualizar
Si los parches están disponibles, ¿por qué seguimos viendo servidores expuestos? La respuesta no es la desidia, sino la incompatibilidad de software.
Aplicar una actualización de seguridad sobre infraestructura de producción no es siempre una operación sencilla:
- Dependencias antiguas. Muchas aplicaciones empresariales solo funcionan con versiones concretas del sistema operativo o de sus librerías. Actualizar para cerrar la brecha puede hacer que el software del cliente deje de funcionar.
- Miedo a cortar el servicio. Actualizar cPanel puede romper configuraciones personalizadas o integraciones que el cliente no puede permitirse perder.
- Software sin mantenimiento. Hay aplicaciones que los propios clientes no pueden actualizar solos. El administrador queda atrapado entre dos opciones igual de malas: dejar el servidor vulnerable o apagar el servicio.
El problema real no es la existencia de la vulnerabilidad, sino que el software antiguo impide aplicar la corrección de seguridad.
Cómo lo abordamos en Cloud Levante
La mayoría de proveedores notifican el riesgo y trasladan la responsabilidad al cliente. Nosotros preferimos ir un paso más allá.
Cuando un cliente no puede aplicar una actualización de seguridad porque algo se lo impide, no nos limitamos a señalarlo: entramos a analizar qué lo impide. Si el bloqueo está en una dependencia de software, la actualizamos y adaptamos para que sea compatible con los parches del sistema, sin interrumpir el servicio. El objetivo es que no tengas que elegir entre funcionar y estar seguro.
"En Cloud Levante no solo le decimos qué está roto, arreglamos el código que le impide actualizar para que su infraestructura sea resiliente por diseño."
Si crees que tu infraestructura puede estar en esta situación, podemos hacer una revisión sin compromiso. Analizamos dependencias, versiones del sistema y vectores de ataque activos.
Solicitar revisión