Vulnerabilidad crítica de omisión de autenticación en cPanel: qué ocurrió, qué significa y cómo respondió RemarkableCloud
A las 19:39 UTC del 28 de abril de 2026, cPanel publicó un aviso de seguridad crítico que revela una vulnerabilidad de omisión de autenticación que afecta a todas las versiones de cPanel/WHM con soporte activo. Ya hay un parche disponible. cPanel ha publicado actualizaciones para todas las versiones compatibles. Ejecuta /scripts/upcp en cada servidor cPanel de inmediato. El aviso recomienda dos mitigaciones, y la mayoría de la cobertura pública difundida en las primeras horas tras la divulgación solo mencionó una.
Este artículo explica qué es la vulnerabilidad, por qué bloquear únicamente los puertos 2083 y 2087 no es suficiente, el plan de mitigación completo y cómo respondió RemarkableCloud para cada cliente en nuestra plataforma.
Qué reveló cPanel
Recientemente se identificó una vulnerabilidad crítica en el software cPanel relacionada con un exploit de inicio de sesión por autenticación. Esto afecta a todas las versiones de cPanel con soporte activo. Actualmente estamos desarrollando activamente un parche para todas las versiones compatibles de cPanel/WHM a fin de corregir esto y garantizar la integridad del producto. Mientras tanto, usar un firewall para bloquear el acceso a los puertos TCP 2083/2087 impedirá el acceso no autorizado, aunque también restringirá cualquier otro acceso al panel de control. Además, recomendamos deshabilitar los Subdominios de Servicio (también conocidos como Proxy Subdomains).
Los puntos clave del aviso:
- Todas las versiones con soporte activo están afectadas: 110, 118, 124 y 130 (tanto la rama LTS como la Current)
- Sin número de CVE, sin SEC ID y sin atribución a un investigador en el momento de la divulgación, lo cual es inusual en cPanel, cuyos avisos recientes han identificado al descubridor en pocas horas
- Aún no hay parche disponible. El proveedor lo está desarrollando.
- Se requieren dos mitigaciones, no una
Por qué bloquear solo los puertos 2083 y 2087 no es suficiente
Este es el punto que la mayoría de los proveedores comunicó mal en sus avisos iniciales. El texto del advisory menciona primero el bloqueo de puertos, pero también recomienda explícitamente deshabilitar los Subdominios de Servicio. Esas dos mitigaciones no son alternativas opcionales: abordan dos rutas de ataque diferentes hacia el mismo código vulnerable.
La función "Subdominios de Servicio" de cPanel (también llamada Proxy Subdomains) crea automáticamente registros DNS y reglas de proxy inverso de Apache que hacen accesible el panel a través de subdominios web estándar:
| Subdominio | Redirige a |
|---|---|
| cpanel.tudominio.com | localhost cpsrvd en el puerto 2083 |
| whm.tudominio.com | localhost cpsrvd en el puerto 2087 |
| webmail.tudominio.com | localhost cpsrvd en el puerto 2096 |
| webdisk.tudominio.com | localhost cpsrvd en el puerto 2078 |
El proxy inverso corre dentro de Apache en el puerto 443, el mismo puerto que usan tus sitios web, el puerto que no puedes bloquear sin dejar inactivos todos los sitios de clientes del servidor. Este es el flujo de la solicitud:
- Una solicitud llega a
https://cpanel.tudominio.com/login/ - Apache la intercepta en el vhost proxy del puerto 443 (no bloqueado por tu firewall)
- Apache reenvía la solicitud internamente a
https://127.0.0.1:2083/login/ - cpsrvd procesa la solicitud a través del mismo código de autenticación vulnerable
El firewall bloquea las conexiones externas al puerto 2083. El proxy de Apache se conecta internamente desde el propio servidor, evitando el firewall por completo. Bloquear el 2083 detiene el acceso directo. No detiene la ruta del proxy. Ambas mitigaciones son necesarias para cerrar ambas vías.
Si el aviso de estado de tu proveedor de hosting solo mencionó el bloqueo de puertos de cPanel: pregúntales si también ejecutaron el comando para deshabilitar los subdominios proxy. La ruta del proxy permanece abierta hasta que ese segundo paso se complete. Un servidor con bloqueo de puertos pero con subdominios proxy activos sigue siendo accesible a través del puerto 443.
Cómo respondió RemarkableCloud
Nuestro equipo de seguridad monitorea los avisos de los proveedores en tiempo real. En el momento en que cPanel publicó el advisory, comenzamos a aplicar ambas mitigaciones en toda nuestra infraestructura. Todos los clientes de RemarkableCloud estaban protegidos antes de que la mayoría de los proveedores hubiera publicado siquiera una actualización en su página de estado.
Esto es lo que significa "totalmente administrado" en la práctica. No recibiste un correo de advertencia pidiéndote que tomaras alguna acción. No necesitaste conectarte por SSH a tu servidor para ejecutar un comando. Nuestro equipo aplicó ambas capas de mitigación (restricción de puertos y deshabilitación de subdominios proxy) en toda la flota antes de que esta vulnerabilidad tuviera tiempo real de ser explotada.
Ejecutamos ambas mitigaciones en paralelo en todos los servidores usando comandos verificados, confirmamos que el valor de tweaksetting devolvió 0 en cada host, y realizamos comprobaciones puntuales en DNS para confirmar que los registros de subdominios proxy habían sido eliminados. Toda la flota quedó asegurada en minutos, no en horas.
Para que conste: los clientes de RemarkableCloud que usan RemarkablePanel no están afectados por esta vulnerabilidad en absoluto. RemarkablePanel está construido sobre la plataforma Enhance, una base de código completamente independiente de cPanel/WHM. Este aviso aplica específicamente a los servidores que ejecutan software cPanel.
El plan de mitigación completo
Para proveedores de hosting y administradores de servidores que necesiten aplicarlo por su cuenta, aquí está la mitigación completa de dos capas. Ambas capas son obligatorias.
Bloquea todos los puertos relacionados con cPanel en el firewall
El aviso menciona los puertos 2083 y 2087, pero el soporte de cPanel y los principales proveedores han confirmado que el enfoque más conservador es bloquear los ocho puertos del panel. cpdavd y webmail se ejecutan dentro del mismo proceso cpsrvd que el código de inicio de sesión vulnerable.
| Puerto | Servicio |
|---|---|
| 2082 | cPanel HTTP |
| 2083 | cPanel HTTPS |
| 2086 | WHM HTTP |
| 2087 | WHM HTTPS |
| 2095 | Webmail HTTP |
| 2096 | Webmail HTTPS |
| 2077 | WebDAV HTTP (cpdavd) |
| 2078 | WebDAV HTTPS (cpdavd) |
Para CSF en un host individual, elimina los ocho puertos de tu lista TCP_IN. Para un firewall perimetral, bloquea el rango completo de entrada desde internet. Durante una ventana de omisión de autenticación sin parchear, incluso una IP de administrador que alcance el panel representa un riesgo innecesario. Usa SSH para operaciones de emergencia hasta que se confirme la instalación del parche.
Deshabilita los Subdominios de Servicio en cada host cPanel
Esta es la mitigación principal. Sin este paso, el bloqueo de puertos es incompleto. Ejecuta lo siguiente como root en cada servidor cPanel:
Qué hace cada paso:
- whmapi1 set_tweaksetting: deshabilita la creación automática de nuevos registros de subdominios proxy
- /scripts/proxydomains remove: elimina los registros DNS existentes de cpanel.*, whm.*, webmail.*, webdisk.* en todas las zonas
- /scripts/rebuildhttpdconf: regenera la configuración de Apache sin las estrofas del vhost proxy
- /scripts/restartsrv_httpd: recarga de Apache sin interrupción (o LiteSpeed en hosts LSWS)
La cadena de comandos es idempotente: ejecutarla dos veces no causa ningún daño. En un servidor con un gran número de dominios, la reescritura de zonas tarda entre 30 y 60 segundos. La operación completa finaliza en menos de dos minutos.
Verifica que la mitigación esté aplicada:
No revertir ninguna mitigación hasta confirmar que la versión parcheada de cPanel está instalada en todos los servidores de tu flota. Un servidor con subdominios proxy reactivados y una versión de cPanel sin actualizar expone todas las cuentas de clientes de ese servidor. Espera el TSR oficial de cPanel antes de revertir cualquiera de las capas.
Lo que aún no sabemos
El aviso del proveedor es intencionalmente escaso en detalles técnicos, lo cual es una práctica estándar durante una ventana activa sin parche. Algunas preguntas abiertas al momento de redactar este artículo:
- El CVE y el SEC ID. cPanel asignará identificadores cuando publique el Targeted Security Release (TSR). Los advisories críticos recientes de cPanel (CVE-2025-66429, SEC-575) incluyeron autoría en pocas horas de la divulgación; este no, lo cual es notable.
- Si la autenticación de dos factores también es omitida. El advisory no lo aclara en ningún sentido. El problema SEC-575 de 2024 evadió la 2FA mediante fuerza bruta. Si esta omisión de autenticación también saltea la capa 2FA es desconocido hasta que se publique el TSR.
- Explotación activa en la práctica. En las primeras horas tras la divulgación, no hay informes públicos confirmados de explotación activa. Esto cambiará una vez que se publique un proof-of-concept, lo que suele ocurrir entre 24 y 72 horas después de un advisory crítico sobre software ampliamente desplegado.
Qué hacer ahora mismo
El parche está disponible. Actualiza cada servidor cPanel de inmediato:
Una vez confirmada la versión parcheada en todos los servidores, las mitigaciones pueden revertirse de forma segura:
No revertir ninguna mitigación hasta que la versión parcheada esté confirmada en todos los servidores de tu flota. Un servidor sin parchear con subdominios proxy reactivados es suficiente para exponer todas las cuentas de clientes en él.
El punto más importante
Este incidente ilustra algo fundamental sobre lo que realmente significa el hosting administrado. Cada entorno de hosting basado en cPanel en el mundo quedó expuesto por este advisory hoy. La diferencia entre proveedores no está en si la vulnerabilidad existe: está en la velocidad de respuesta del operador y en si sus clientes tuvieron que hacer algo al respecto.
Nuestros clientes no hicieron nada. No recibieron un correo de acción requerida. No iniciaron sesión para ejecutar un comando. Estaban protegidos antes de que la mayoría de la industria terminara de redactar sus actualizaciones de estado. Eso son 25 años de experiencia operativa produciendo tiempos de respuesta medidos en minutos, no en horas.
Si estás en un VPS administrado con un proveedor que te envió instrucciones para aplicar esta mitigación tú mismo, eso merece reflexión. Un servidor administrado debería estar administrado, especialmente cuando una vulnerabilidad crítica aparece a las 19:39 UTC un lunes por la noche.
El hosting administrado significa que nosotros gestionamos las emergencias. No tú.
Vulnerabilidad crítica divulgada. Todos los clientes de RemarkableCloud protegidos en minutos. Cero acciones requeridas de los clientes. Eso es lo que significa totalmente administrado.
Ver planes Cloud Cube
