En Occentus vivimos una de esas jornadas que evidencian una realidad cada vez más evidente: en la era de la inteligencia artificial, la ciberseguridad se ha convertido en un factor crítico, urgente y continuo. Las vulnerabilidades se descubren, se publican y pueden ser explotadas cada vez más rápido, reduciendo al mínimo el margen de reacción. Por eso, contar con un servicio gestionado 24/7 ya no es solo una ventaja operativa, sino una necesidad para proteger infraestructuras críticas. En apenas 24 horas se publicaron dos vulnerabilidades de alto impacto que afectaban directamente a entornos ampliamente utilizados en hosting, cloud y servidores Linux: CVE-2026-41940, en cPanel & WHM / WP Squared, y CVE-2026-31431, conocida como Copy Fail, en el kernel de Linux.
Los fallos se descubren más rápido, se publican antes, las pruebas de concepto circulan en menos tiempo y las ventanas de exposición se reducen drásticamente.
La primera alerta llegó el 28 de abril de 2026 a las 12:05 PM CST, cuando cPanel publicó el aviso inicial de seguridad para CVE-2026-41940. El fabricante confirmó un problema de bypass de autenticación que afectaba a cPanel, WHM y DNSOnly en versiones posteriores a la 11.40. En los días siguientes, el aviso fue actualizado con versiones corregidas, instrucciones de actualización y medidas de mitigación para sistemas que no pudieran actualizarse inmediatamente.
Apenas unas horas después, el 29 de abril de 2026, se hizo pública CVE-2026-31431, conocida como Copy Fail. Una vulnerabilidad de escalada local de privilegios en el módulo algif_aead del kernel de Linux, dentro de la API criptográfica de usuario AF_ALG. El fallo permite que un usuario local sin privilegios realice una escritura controlada de 4 bytes sobre páginas respaldadas por la page cache, pudiendo llegar a obtener privilegios de root al atacar binarios setuid como /usr/bin/su.
Una madrugada para controlar miles de máquinas
Ante este escenario, nuestro objetivo fue claro: identificar exposición, priorizar sistemas afectados, aplicar mitigaciones, actualizar servicios y verificar el resultado en todos los servidores gestionados por Occentus durante la misma madrugada del descubrimiento.
No se trataba únicamente de ejecutar comandos. En una operación de este tipo hay que coordinar inventario, validar soluciones, versiones, ventanas de impacto, automatización, validación posterior y trazabilidad. En miles de máquinas, incluso una pequeña diferencia entre distribuciones, versiones de kernel o ramas de cPanel para el caso de su vulnerabilidad puede cambiar completamente la forma correcta de actuar.
CVE-2026-41940: bypass de autenticación en cPanel & WHM
Si bien nuestro parque propio de cPanel no es especialmente grande frente a otras soluciones, si nos vimos en la necesidad de proteger a los clientes de los centros de datos que damos soporte con el fin de evitar daños mucho mayores como se ha visto en los días siguientes.
CVE-2026-41940 afecta a cPanel & WHM y WP Squared. Técnicamente, la vulnerabilidad está relacionada con el flujo de autenticación y la carga/guardado de sesiones. Un bypass de autenticación provocado por una inyección CRLF en los procesos de login y carga de sesión de cPanel & WHM, que puede permitir a un atacante no autenticado obtener acceso administrativo.
cPanel publicó versiones corregidas para varias ramas, incluyendo 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.124.0.35, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20 y 11.136.0.5 o superiores. Ver información oficial en la web de cPanel
Mitigación y actualización aplicada
La acción principal sobre los servidores gestionados por nosotros fue actualizar los servidores cPanel afectados a una versión corregida mediante el script oficial de actualización:
/scripts/upcp --forceTras completar la actualización, se verificó la versión instalada:
/usr/local/cpanel/cpanel -VY se reinició el servicio principal de cPanel:
/scripts/restartsrv_cpsrvd --hardEstas acciones coinciden con las instrucciones oficiales publicadas por cPanel para actualizar, verificar la build y reiniciar cpsrvd.
En servidores con rama fijada o actualizaciones deshabilitadas, se ajustó el tier cuando fue necesario. Por ejemplo, para sistemas que debían pasar a la rama 11.110:
whmapi1 set_tier tier=11.110
/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hardComo medida de contención para sistemas donde no era posible completar la actualización de forma inmediata, cPanel recomendó bloquear el tráfico entrante a los puertos 2083, 2087, 2095 y 2096, o detener temporalmente cpsrvd y cpdavd.
El comando oficial para deshabilitar y detener esos servicios es:
whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && \
whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && \
/scripts/restartsrv_cpsrvd --stop && \
/scripts/restartsrv_cpdavd --stopEn nuestra operación, la prioridad fue siempre actualizar a versión corregida, dejando las medidas de bloqueo o parada de servicios como contención para casos concretos.
Con el fin de proteger a los demás clientes, de decidió además filtrar de forma masiva los puertos 2083, 2087, 2095, y 2096 durante la misma madrugada, de forma que los clientes tuvieran tiempo de reacción para la contención de la vulnerabilidad por su lado.
CVE-2026-31431 / Copy Fail: escalada de privilegios en Linux
Apenas recuperados, la segunda emergencia fue Copy Fail, identificada como CVE-2026-31431 que fué publicada en la misma mañana. A diferencia de CVE-2026-41940, no se trata de un bypass remoto de un panel de control, sino de una vulnerabilidad local en el kernel de Linux. Su impacto operativo es muy alto porque permite que un usuario local sin privilegios eleve permisos a root en sistemas vulnerables. En entornos con contenedores o workloads no confiables, este tipo de fallo puede tener implicaciones especialmente sensibles.
El fallo se encuentra en algif_aead, parte de la interfaz criptográfica AF_ALG. CERT-EU explica que la vulnerabilidad procede de una optimización introducida en 2017 que permite que páginas de la page cache terminen en una scatterlist de destino escribible. Encadenando operaciones sobre sockets AF_ALG con splice(), un usuario local puede realizar una escritura controlada sobre memoria respaldada por page cache.
La inteligencia artificial acelera el descubrimiento de fallos
Uno de los aspectos más relevantes de Copy Fail es cómo fue descubierto. La vulnerabilidad fue localizada con ayuda de herramientas de análisis asistidas por inteligencia artificial, lo que refuerza una tendencia que ya estamos viendo claramente: la IA está acelerando la investigación de vulnerabilidades y sacando a la luz fallos que durante años han pasado desapercibidos.
Esto tiene una doble lectura. Por un lado, mejora la capacidad defensiva de investigadores, fabricantes y equipos de seguridad. Por otro, reduce drásticamente la ventana entre descubrimiento, publicación, prueba de concepto y explotación. Lo que antes podía tardar semanas o meses en analizarse, hoy puede aparecer, documentarse y circular en cuestión de horas.
Por eso la respuesta rápida y controlada frente a amenazas emergentes es más importante que nunca.
Mitigación de Copy Fail
Para CVE-2026-31431, la mitigación depende de cómo esté disponible algif_aead en cada sistema.
En sistemas donde algif_aead está disponible como módulo cargable, se puede bloquear su carga mediante modprobe.d y deshabilitarlo si ya está activo:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || trueLa primera línea bloquea futuras cargas del módulo algif_aead. La segunda intenta retirar el módulo si ya estaba cargado.
Para verificar si sigue cargado:
lsmod | grep algif_aeadSi el comando no devuelve resultados, el módulo no está cargado.
También puede comprobarse si modprobe queda bloqueado correctamente:
modprobe algif_aeadEn un sistema mitigado mediante modprobe.d, ese comando debería fallar.
En Ubuntu, la mitigación también fue distribuida mediante el paquete kmod, que deshabilita el módulo afectado. Canonical indica que Copy Fail afecta a versiones de Ubuntu anteriores a Resolute 26.04 y que la mitigación puede aplicarse actualizando kmod o los paquetes de seguridad correspondientes.
Comandos de mitigación en Ubuntu:
apt update
apt install --only-upgrade kmodO actualización completa del sistema:
apt update
apt upgrade -yCaso especial: CloudLinux, AlmaLinux, Rocky Linux y familia RHEL
Aquí hay un punto técnico importante. En algunos sistemas de la familia RHEL, CloudLinux o AlmaLinux, algif_aead puede estar compilado dentro del kernel y no como módulo cargable. En ese caso, la mitigación con modprobe.d y rmmod no es suficiente, porque modprobe no controla un componente que ya forma parte del kernel. CloudLinux advierte específicamente que en estos casos esos comandos pueden ejecutarse sin errores pero no aplicar realmente la mitigación. (blog.cloudlinux.com)
Para comprobarlo:
modinfo algif_aead | grep filenameSi devuelve algo como:
filename: (builtin)significa que algif_aead está compilado dentro del kernel.
En esos casos, la mitigación pasa por bloquear la inicialización mediante parámetro de arranque. En sistemas con grubby, puede aplicarse así:
grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"Después, es necesario reiniciar para que el parámetro tenga efecto:
rebootY verificar que la mitigación está aplicada:
grubby --info=ALL | grep initcall_blacklist
La salida debe incluir:
initcall_blacklist=algif_aead_init
CloudLinux documenta precisamente esta verificación como forma de confirmar que la mitigación está activa en sistemas donde algif_aead está compilado como builtin. (blog.cloudlinux.com)
Automatización, control y verificación
En una infraestructura gestionada, la diferencia entre una respuesta eficaz y una respuesta caótica está en la capacidad de ejecutar cambios de forma masiva, controlada y verificable.
Durante la madrugada, trabajamos sobre tres ejes:
1. Identificación de exposición
Se inventariaron servidores con cPanel & WHM, versiones afectadas, ramas fijadas, sistemas con actualizaciones deshabilitadas y kernels potencialmente vulnerables.
2. Mitigación y actualización
Se aplicaron actualizaciones de cPanel en servidores afectados, se reiniciaron servicios necesarios y se desplegaron mitigaciones para algif_aead según la distribución y el tipo de kernel.
3. Validación posterior
Se verificaron versiones de cPanel, estado de servicios, carga del módulo algif_aead, parámetros de arranque en sistemas donde correspondía y disponibilidad de los servicios gestionados.
Algunos comandos de verificación utilizados fueron:
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --status
lsmod | grep algif_aead
modinfo algif_aead | grep filename
grubby --info=ALL | grep initcall_blacklist
uname -rLa respuesta rápida ya no es opcional
Estas dos vulnerabilidades reflejan el nuevo ritmo de la ciberseguridad: en la era de la inteligencia artificial, los fallos se descubren antes, se publican más rápido y pueden convertirse en amenazas reales en cuestión de horas.
En Occentus no entendemos la seguridad como una herramienta, sino como una capacidad operativa: detectar, decidir, actuar y verificar sin demora. Por eso, durante la misma madrugada, mitigamos y actualizamos los servidores y servicios gestionados, reduciendo la exposición de nuestros clientes sin comprometer la continuidad.
Hoy, contar con administración gestionada 24/7 ya no es un extra: es la diferencia entre reaccionar tarde o contener el riesgo a tiempo.