Vulnerabilidad crítica de bypass de autenticación en cPanel: qué pasó, qué significa y cómo respondió RemarkableCloud
Actualizado: 28 de abril de 2026. El parche ya está disponible. Ejecuta /scripts/upcp en todos los servidores cPanel de inmediato. Ambas mitigaciones pueden revertirse una vez confirmada la actualización.
Última hora · 28 de abril de 2026
28 de abril de 2026 8 min de lectura Equipo de Seguridad de RemarkableCloud
Vulnerabilidad crítica de bypass de autenticación en cPanel: qué pasó, 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 revelando una vulnerabilidad de bypass de autenticación que afecta cada versión actualmente soportada de cPanel/WHM. El parche ya está disponible. cPanel ha publicado actualizaciones para todas las versiones soportadas. Ejecuta /scripts/upcp en cada servidor cPanel de inmediato. El aviso recomienda dos mitigaciones, y la mayoría de la cobertura pública publicada en las primeras horas tras la revelación solo mencionó una de ellas.
Este artículo cubre qué es la vulnerabilidad, por qué bloquear los puertos 2083 y 2087 por sí solo no es suficiente, el playbook completo de mitigación, y cómo respondió RemarkableCloud para cada cliente de nuestra plataforma.
Qué reveló cPanel
Aviso oficial de cPanel: 28 de abril de 2026
Recientemente se identificó una vulnerabilidad crítica en el software de cPanel relacionada con un exploit de inicio de sesión de autenticación. Esto afecta a todas las versiones actualmente soportadas de cPanel. Actualmente estamos construyendo activamente un parche para todas las versiones soportadas de cPanel/WHM para atender esto y asegurar la integridad del producto cPanel. Mientras tanto, usar un firewall para bloquear el acceso a los puertos TCP 2083/2087 evitará el acceso no autorizado, pero también restringirá todo otro acceso al panel de control. Además, también recomendamos deshabilitar los Service Subdomains (también llamados Proxy Subdomains).
Los hechos clave del aviso:
- Todas las versiones actualmente soportadas están afectadas: 110, 118, 124 y 130 (ambas ramas, LTS y Current)
- Sin número CVE, sin SEC ID y sin atribución de investigador al momento de la revelación, algo inusual en cPanel, cuyos avisos recientes han nombrado al descubridor en cuestión de horas
- Sin parche disponible aún. El vendor está construyendo uno.
- Se requieren dos mitigaciones, no una
Por qué bloquear los puertos 2083 y 2087 por sí solo no es suficiente
Esta es la parte que la mayoría de los proveedores hizo mal en sus comunicaciones iniciales. El texto del aviso menciona primero el bloqueo de puertos, pero también recomienda explícitamente deshabilitar los Service Subdomains. Esas dos mitigaciones no son alternativas opcionales: atienden dos rutas de ataque distintas hacia el mismo código vulnerable.
La característica “Service Subdomains” de cPanel (también llamada Proxy Subdomains) crea automáticamente registros DNS y reglas de proxy inverso de Apache que hacen el panel accesible vía subdominios web estándar:
| Subdominio | Hace proxy hacia |
|---|---|
| cpanel.tudominio.com | cpsrvd en localhost en el puerto 2083 |
| whm.tudominio.com | cpsrvd en localhost en el puerto 2087 |
| webmail.tudominio.com | cpsrvd en localhost en el puerto 2096 |
| webdisk.tudominio.com | cpsrvd en localhost 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 tumbar cada sitio de cliente del servidor. Este es el flujo de la solicitud:
- Una solicitud llega a
https://cpanel.tudominio.com/login/ - Apache empata el vhost de proxy en el 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 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 rutas.
⚠
Si la actualización de estado de tu proveedor de hosting solo mencionó bloquear los puertos de cPanel: pregúntales si también ejecutaron el comando para deshabilitar los proxy subdomains. La ruta del proxy sigue abierta hasta que ese segundo paso se completa. Un servidor con bloqueo de puertos pero con proxy subdomains activos sigue siendo alcanzable a través del puerto 443.
Cómo respondió RemarkableCloud
Tiempo desde la publicación del aviso hasta que todos los clientes quedaron protegidos
Minutos
Nuestro equipo de seguridad monitorea los avisos de vendors en tiempo real. En el momento en que se publicó el aviso de cPanel, empezamos a desplegar ambas mitigaciones en toda nuestra infraestructura. Cada cliente de RemarkableCloud quedó protegido antes de que la mayoría de los proveedores hubiera siquiera publicado una actualización en su página de estado.
Esto es lo que “totalmente administrado” significa en la práctica. No recibiste un correo de advertencia pidiéndote actuar. No necesitaste entrar por SSH a tu servidor y ejecutar un comando. Nuestro equipo aplicó ambas capas de mitigación (restricciones de puertos y deshabilitación de proxy subdomains) en toda la flota antes de que esta vulnerabilidad tuviera tiempo significativo de ser explotada.
Ejecutamos ambas mitigaciones en paralelo en todos los servidores usando comandos verificados, confirmamos que el valor del tweaksetting devolviera 0 en cada host, e hicimos verificaciones de DNS para confirmar que los registros de proxy subdomains habían sido removidos. La flota completa quedó asegurada en minutos, no 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 separada de cPanel/WHM. Este aviso aplica específicamente a servidores corriendo software cPanel.
El playbook completo de mitigación
Para proveedores de hosting y administradores de servidores que necesiten aplicar esto por su cuenta, este es el proceso completo de mitigación en dos capas. Ambas capas son necesarias.
1
Bloquea todos los puertos relacionados con cPanel en el firewall
El aviso nombra el 2083 y el 2087, pero el soporte de cPanel y los proveedores grandes han confirmado que el enfoque conservador es bloquear los ocho puertos del panel. cpdavd y el webmail corren dentro del mismo proceso cpsrvd que el código de login 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 solo host, quita los ocho puertos de tu lista TCP_IN. Para un firewall perimetral, bloquea el rango completo entrante desde internet. Durante una ventana de bypass de autenticación sin parche, incluso una IP de admin alcanzando el panel es riesgo innecesario. Usa SSH para operaciones de emergencia hasta confirmar que el parche está instalado.
2
Deshabilita los Service Subdomains en cada host cPanel
Esta es la mitigación que carga el peso. Sin este paso, el bloqueo de puertos está incompleto. Ejecuta lo siguiente como root en cada servidor cPanel:
whmapi1 set_tweaksetting key=proxysubdomains value=0 &&
/scripts/proxydomains remove &&
/scripts/rebuildhttpdconf &&
/scripts/restartsrv_httpd
Qué hace cada paso:
- whmapi1 set_tweaksetting: deshabilita la creación automática de nuevos registros de proxy subdomain
- /scripts/proxydomains remove: remueve 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 de proxy
- /scripts/restartsrv_httpd: recarga con gracia de Apache (o LiteSpeed en hosts LSWS)
La cadena de comandos es idempotente: correrla dos veces no causa daño. En un servidor con muchos dominios, la reescritura de zonas toma de 30 a 60 segundos. La operación completa termina en menos de dos minutos.
Verifica que la mitigación está en su lugar:
whmapi1 get_tweaksetting key=proxysubdomains | grep value
Salida esperada: value: 0
dig @localhost cpanel.algundominiodecliente.com
Salida esperada: NXDOMAIN
💡
No reviertas ninguna de las dos mitigaciones hasta haber confirmado que el build parchado de cPanel está instalado en cada servidor de tu flota. Un servidor con proxy subdomains rehabilitados y una versión de cPanel sin actualizar expone cada cuenta de cliente de ese servidor. Espera el TSR oficial de cPanel antes de revertir cualquiera de las dos capas.
Lo que aún no sabemos
El aviso del vendor es intencionalmente escaso en detalle técnico, lo cual es práctica estándar durante una ventana activa sin parche. Algunas preguntas abiertas al momento de escribir:
- El CVE y el SEC ID. cPanel asignará identificadores cuando publique el Targeted Security Release (TSR). Los avisos críticos recientes de cPanel (CVE-2025-66429, SEC-575) llevaron atribución en cuestión de horas tras la revelación; este no, lo cual es notable.
- Si la autenticación de dos factores se elude. El aviso no lo dice en ningún sentido. El problema SEC-575 de 2024 eludía el 2FA vía fuerza bruta. Si este bypass de autenticación también se salta la capa de 2FA es desconocido hasta que se publique el TSR.
- Explotación activa en el mundo real. En las primeras horas tras la revelación, no hay reportes públicos confirmados de explotación activa. Esto cambiará una vez que se publique una prueba de concepto, lo que típicamente ocurre entre 24 y 72 horas después de un aviso crítico en software ampliamente desplegado.
Qué hacer ahora mismo
El parche está disponible. Actualiza cada servidor cPanel de inmediato:
/scripts/upcp
Confirma que la versión parchada está instalada antes de revertir las mitigaciones
Una vez confirmada la versión parchada en todos los servidores, las mitigaciones pueden revertirse con seguridad:
Revertir Capa 2: rehabilitar los proxy subdomains
whmapi1 set_tweaksetting key=proxysubdomains value=1 &&
/scripts/proxydomains add &&
/scripts/rebuildhttpdconf &&
/scripts/restartsrv_httpd
Revertir Capa 1: quitar los bloqueos de puertos del firewall
No reviertas ninguna mitigación hasta que el build parchado esté confirmado en cada servidor de tu flota. Un solo servidor sin parche con proxy subdomains rehabilitados basta para exponer cada cuenta de cliente que contiene.
El punto más amplio
Este incidente ilustra algo importante sobre lo que “hosting administrado” significa en realidad. Cada entorno de hosting basado en cPanel del mundo quedó expuesto por este aviso hoy. La diferencia entre proveedores no es si la vulnerabilidad existe: es qué tan rápido responde el operador y 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. Quedaron protegidos antes de que la mayoría de la industria terminara de escribir sus actualizaciones de estado. Eso son 25 años de experiencia operativa produciendo un tiempo de respuesta medido en minutos, no horas.
Si estás en un VPS administrado con un proveedor que te envió instrucciones para aplicar esta mitigación tú mismo, vale la pena reflexionarlo. Un servidor administrado debería estar administrado, especialmente cuando una vulnerabilidad crítica cae a las 19:39 UTC un lunes por la noche.