🔧
🛠 Guía Técnica de Parcheo

Cómo parchear CVE-2026-41940 en cPanel paso a paso y verificar si el servidor fue comprometido

Comandos exactos para SysAdmins: desde la verificación de versión hasta la auditoría forense post-parche. Con las versiones corregidas, los paths relevantes y las comprobaciones de integridad necesarias.

🗓 Mayo 2026⏱ 11 min lectura 🎯 SysAdmins · DevOps · IT Ops
🔴 Antes de empezar: no existe solución alternativa completa — solo el parche

Bloquear puertos y detener cpsrvd son medidas de contención temporales. La única corrección definitiva es actualizar cPanel a una versión con el fix aplicado. Este artículo cubre el proceso completo para servidores autoadministrados (VPS, dedicados). Si usas hosting gestionado, la responsabilidad del parche recae en el proveedor — pero necesitas su confirmación por escrito.

📋 Versiones afectadas y versiones con fix

Rama cPanelÚltima versión vulnerablePrimera versión con fixEstado
11.136.x (Release)11.136.0.4 y anteriores11.136.0.5✓ Fix disponible
11.134.x11.134.0.19 y anteriores11.134.0.20✓ Fix disponible
11.132.x11.132.0.28 y anteriores11.132.0.29✓ Fix disponible
11.126.x11.126.0.53 y anteriores11.126.0.54✓ Fix disponible
11.118.x11.118.0.62 y anteriores11.118.0.63✓ Fix disponible
11.110.x11.110.0.96 y anteriores11.110.0.97✓ Fix disponible
11.86.x (RELEASE)11.86.0.40 y anteriores11.86.0.41✓ Fix disponible
WP Squared136.1.6 y anteriores136.1.7✓ Fix disponible
Versiones anteriores a 11.40No soportadas oficialmente — sin parche⚠ Migrar urgente

🚀 Proceso completo de parcheo en 5 fases

1
Verificar la versión instalada actualmente
Antes de cualquier acción — confirmar la versión exacta

Identifica la versión instalada y compárala con la tabla de versiones con fix. Este paso determina si ya estás parcheado o si necesitas actualizar.

Verificar versión cPanel
# Método 1 — comando cpanel
/usr/local/cpanel/cpanel -V
# Salida esperada: 11.136.0.5 (u otra versión con fix)

# Método 2 — archivo de versión
cat /usr/local/cpanel/version

# Método 3 — vía WHM API
whmapi1 version
# Busca "version" en el output JSON
2
Aplicar el parche vía upcp
Actualización forzada al tier de parches de seguridad

El comando upcp es el actualizador oficial de cPanel. El flag --force obliga la actualización incluso si el servidor tiene las actualizaciones automáticas desactivadas. Este proceso puede tardar entre 5 y 20 minutos según la velocidad de red del servidor.

Aplicar parche — ejecutar como root
# Actualización forzada — no interrumpir el proceso
/scripts/upcp --force

# Para servidores con TIER específico configurado, verificar:
cat /etc/cpupdate.conf
# Asegúrate de que TIER no está fijado a una versión sin parche

# Si la actualización falla por configuración, forzar tier de release:
echo 'TIER=release' > /etc/cpupdate.conf
/scripts/upcp --force
3
Post-parche: purgar sesiones y reiniciar cpsrvd
Eliminar sesiones inyectadas activas y reiniciar el daemon

Tras aplicar el parche, cualquier sesión inyectada que permanezca activa en el sistema debe eliminarse. También es necesario reiniciar los servicios de cPanel para cargar la versión corregida.

Purga de sesiones y restart de servicios
# Purgar todos los archivos de sesión existentes
rm -f /var/cpanel/sessions/raw/*
rm -f /var/cpanel/sessions/cache/*

# Reiniciar cpsrvd (el daemon principal de cPanel)
/etc/init.d/cpanel restart
# O en sistemas con systemd:
systemctl restart cpanel

# Verificar que el servicio está corriendo
systemctl status cpanel
pgrep -a cpsrvd

# Verificar versión post-parche
/usr/local/cpanel/cpanel -V
# Debe mostrar una versión con fix (ej: 11.136.0.5)
4
Ejecutar el script oficial de detección de compromiso
Verificar si el servidor fue explotado antes del parche

cPanel publicó un script oficial de detección de IoCs para CVE-2026-41940. Independientemente de si el parche ya estaba aplicado, este script debe ejecutarse en todos los servidores que estuvieron expuestos durante la ventana del zero-day (23 Feb – 28 Abr 2026).

Script de detección oficial cPanel
# Descargar y ejecutar el script oficial de detección
curl -sSL https://raw.githubusercontent.com/CpanelInc/Security-CVE-2026-41940/main/detect.sh | bash

# Verificación manual de IoCs adicionales:

# 1. Buscar web shells PHP recientes
find /home /var/www -name "*.php" -newer /var/cpanel/version -ls 2>/dev/null | grep -v ".cpanel"

# 2. Cuentas root adicionales en /etc/passwd
awk -F: '($3 == 0) {print $1}' /etc/passwd

# 3. SSH authorized_keys modificadas
find /home /root -name "authorized_keys" -newer /var/cpanel/version 2>/dev/null

# 4. Archivos de ransomware
find / -name "*.sorry" -type f 2>/dev/null
5
Habilitar actualizaciones automáticas de seguridad
Prevenir que esto vuelva a ocurrir por tener auto-updates desactivados

Una de las causas principales por las que muchos servidores quedaron sin parche durante la ventana del zero-day fue tener las actualizaciones automáticas desactivadas. cPanel permite configurar actualizaciones automáticas exclusivamente para parches de seguridad, sin aplicar releases mayores de forma automática.

Configurar auto-updates de seguridad
# Ver configuración actual de updates
cat /etc/cpupdate.conf

# Activar actualizaciones automáticas en WHM vía API
whmapi1 set_autossl_metadata autossl_provider=cPanelAutoSSL

# O directamente en /etc/cpupdate.conf:
UPDATES=daily
TIER=release
RPMUP=daily

# Verificar que el cron de updates está activo
crontab -l | grep upcp
# Debe mostrar algo como: 30 2 * * * /scripts/upcp --cron > /dev/null 2>&1

🔒 Medidas de hardening adicionales post-parche

  • ✓Rotar las credenciales root y las de todos los revendedores WHM. Aunque no exista evidencia de compromiso, si el servidor estuvo expuesto durante la ventana del zero-day, las credenciales deben tratarse como potencialmente comprometidas y rotarse en su totalidad.
  • ✓Revisar e invalidar todos los API tokens de WHM. En WHM > Setup Remote Access Key, genera una nueva clave y revoca la anterior.
  • ✓Restringir el acceso a los puertos de cPanel/WHM por IP en el firewall. Si solo un rango de IPs conocido debe acceder al panel, implementa una lista blanca de IPs para los puertos 2083 y 2087 en el firewall del host.
  • ✓Habilitar 2FA en todas las cuentas WHM/cPanel. Con el vector actual parchado, el segundo factor de autenticación es una capa defensiva efectiva frente a futuros exploits de credenciales.
  • ✓Configurar logging centralizado. Los logs de cPanel en /usr/local/cpanel/logs/ deben enviarse a un SIEM centralizado externo al servidor, de modo que un compromiso no elimine la evidencia forense.
  • iEvaluar ModSecurity / Imunify360. Estas capas de WAF pueden detectar y bloquear el patrón de inyección CRLF antes de que llegue al daemon, proporcionando una capa adicional de defensa en profundidad para futuros CVEs.

📚 Fuentes