Vulnerabilidad crítica de omisión de autenticación en cPanel: qué sucedió, 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 revelaba una vulnerabilidad de omisión de autenticación que afectaba a todas las versiones compatibles de cPanel/WHM. Ya está disponible un parche. cPanel ha implementado actualizaciones para todas las versiones compatibles. Ejecute /scripts/upcp en todos los servidores cPanel de inmediato. El aviso recomienda dos medidas de mitigación, pero la mayoría de la información publicada en las primeras horas tras la divulgación solo mencionaba una de ellas.
Este artículo explica en qué consiste 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 de nuestra plataforma.
Lo que reveló cPanel
Recientemente se identificó una vulnerabilidad crítica en el software cPanel relacionada con una vulnerabilidad de autenticación de inicio de sesión. Esta vulnerabilidad afecta a todas las versiones de cPanel compatibles. Actualmente, estamos desarrollando un parche para todas las versiones compatibles de cPanel/WHM para solucionar este problema y garantizar la integridad del producto. Mientras tanto, bloquear el acceso a los puertos TCP 2083/2087 mediante un firewall evitará el acceso no autorizado, pero también restringirá el acceso al panel de control. Además, recomendamos deshabilitar los subdominios de servicio (también conocidos como subdominios proxy).
Los datos clave del informe:
- Todas las versiones compatibles actualmente se ven afectadas: 110, 118, 124 y 130 (tanto las versiones LTS como las versiones actuales)
- No se proporcionó número CVE, ni identificación de la SEC, ni se atribuyó la autoría del investigador en el momento de la divulgación, lo cual es inusual para cPanel, cuyos avisos recientes han revelado la identidad del descubridor en cuestión de horas
- Aún no hay ningún parche disponible. El proveedor está desarrollando uno.
- Se requieren dos medidas de mitigación, no una
Por qué bloquear los puertos 2083 y 2087 por sí solo no es suficiente
Este es el punto en el que la mayoría de los proveedores se equivocaron en sus comunicaciones iniciales. El aviso menciona primero el bloqueo de puertos, pero también recomienda explícitamente deshabilitar los subdominios de servicio. Estas dos medidas no son alternativas opcionales: abordan dos vías de ataque diferentes al mismo código vulnerable.
La función "Subdominios de servicio" de cPanel (también llamada Subdominios proxy) crea automáticamente registros DNS y reglas de proxy inverso de Apache que hacen que el panel sea accesible a través de subdominios web estándar:
| Subdominio | Proxies para |
|---|---|
| cpanel.tudominio.com | localhost cpsrvd en el puerto 2083 |
| whm.tudominio.com | localhost cpsrvd en el puerto 2087 |
| correo web.tudominio.com | localhost cpsrvd en el puerto 2096 |
| webdisk.tudominio.com | cpsrvd localhost en el puerto 2078 |
El proxy inverso se ejecuta dentro de Apache en el puerto 443, el mismo puerto que utilizan sus sitios web, un puerto que no puede bloquear sin dejar inactivos todos los sitios de sus clientes en el servidor. Este es el flujo de la solicitud:
- Se recibe una solicitud en
https://cpanel.yourdomain.com/login/ - Apache coincide con el host virtual del proxy en el puerto 443 (no bloqueado por su 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 cortafuegos bloquea las conexiones externas al puerto 2083. El proxy Apache se conecta internamente desde el propio servidor, evitando por completo el cortafuegos. Bloquear el puerto 2083 impide el acceso directo, pero no la ruta del proxy. Se requieren ambas medidas para cerrar ambas rutas.
Si la actualización de estado de su proveedor de hosting solo menciona el bloqueo de puertos de cPanel, pregúnteles si también ejecutaron el comando para deshabilitar el subdominio proxy. La ruta del proxy permanece abierta hasta que se complete este segundo paso. Un servidor con bloqueo de puertos pero con subdominios proxy activos aún es accesible a través del puerto 443.
Cómo respondió RemarkableCloud
Nuestro equipo de seguridad supervisa los avisos de los proveedores en tiempo real. En cuanto se publicó el aviso de cPanel, comenzamos a implementar ambas medidas de mitigación en toda nuestra infraestructura. Todos los clientes de RemarkableCloud estaban protegidos incluso antes de que la mayoría de los proveedores publicaran una actualización en su página de estado.
Esto es lo que significa "gestión completa" en la práctica. No recibió ningún correo electrónico de advertencia solicitándole que tomara medidas. No necesitó conectarse por SSH a su servidor ni ejecutar ningún comando. Nuestro equipo aplicó ambas capas de mitigación (restricciones de puertos y desactivación del subdominio proxy) en toda la flota antes de que esta vulnerabilidad tuviera tiempo suficiente para ser explotada.
Ejecutamos ambas medidas de mitigación en paralelo en todos los servidores mediante comandos verificados, confirmamos que el valor de tweaksetting era 0 en cada host y realizamos comprobaciones aleatorias del DNS para confirmar que se habían eliminado los registros del subdominio proxy. Toda la flota quedó protegida en minutos, no en horas.
Para que conste: los clientes de RemarkableCloud que utilizan RemarkablePanel no se ven afectados por esta vulnerabilidad. RemarkablePanel se basa en la plataforma Enhance, un código fuente completamente independiente de cPanel/WHM. Este aviso se aplica específicamente a los servidores que ejecutan el software cPanel.
El manual completo de mitigación
Para los proveedores de alojamiento y los administradores de servidores que necesiten aplicar esto por sí mismos, aquí tienen 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 la medida más conservadora 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 | Correo web HTTP |
| 2096 | Correo web HTTPS |
| 2077 | WebDAV HTTP (cpdavd) |
| 2078 | WebDAV HTTPS (cpdavd) |
Para CSF en un solo host, elimine los ocho puertos de su lista TCP_IN. Para un firewall perimetral, bloquee todo el rango de tráfico entrante desde internet. Durante un período de omisión de autenticación sin parchear, incluso una IP de origen de administrador que llegue al panel representa un riesgo innecesario. Use SSH para operaciones de emergencia hasta que se confirme la instalación del parche.
Desactive los subdominios de servicio en todos los servidores cPanel
Esta es la mitigación de carga. Sin este paso, el bloqueo de puertos es incompleto. Ejecute lo siguiente como root en cada servidor cPanel:
Qué hace cada paso:
- whmapi1 set_tweaksetting: desactiva la creación automática de nuevos registros de subdominio proxy.
- /scripts/proxydomains remove: elimina los registros DNS existentes cpanel.*, whm.*, webmail.*, webdisk.* en todas las zonas.
- /scripts/rebuildhttpdconf: regenera la configuración de Apache sin las secciones de host virtual del proxy.
- /scripts/restartsrv_httpd: recarga controlada de Apache (o LiteSpeed en hosts LSWS)
La cadena de comandos es idempotente: ejecutarla dos veces no causa ningún problema. En un servidor con un gran número de dominios, la reescritura de zona tarda entre 30 y 60 segundos. La operación completa se finaliza en menos de dos minutos.
Verifique que las medidas de mitigación estén implementadas:
No revierta ninguna de las medidas de mitigación hasta que haya confirmado que la versión parcheada de cPanel está instalada en todos los servidores de su flota. Un servidor con subdominios proxy reactivados y una versión de cPanel sin actualizar expone todas las cuentas de clientes en ese servidor. Espere a que cPanel publique el informe de servicio técnico oficial antes de revertir cualquiera de las capas.
Lo que aún desconocemos
El aviso del proveedor es intencionalmente escaso en detalles técnicos, lo cual es práctica habitual durante un período en el que aún no se han publicado parches. Algunas preguntas abiertas al momento de redactar este informe:
- El identificador CVE y SEC. cPanel asignará identificadores cuando publique el Aviso de Seguridad Dirigido (TSR). Los avisos críticos recientes de cPanel (CVE-2025-66429, SEC-575) incluyeron firmas a las pocas horas de su divulgación; este no, lo cual es significativo.
- Se desconoce si se elude la autenticación de dos factores. El aviso no lo aclara. El problema SEC-575 de 2024 eludió la autenticación de dos factores mediante fuerza bruta. Se desconoce si este método de elusión de la autenticación también omite la capa de autenticación de dos factores hasta que se publique el informe técnico.
- Explotación activa en la práctica. En las primeras horas posteriores a la divulgación, no hay informes públicos confirmados de explotación activa. Esto cambiará una vez que se publique una prueba de concepto, lo que suele ocurrir entre 24 y 72 horas después de una advertencia crítica sobre software ampliamente implementado.
¿Qué hacer ahora mismo?
El parche ya está disponible. Actualice todos sus servidores cPanel inmediatamente:
Una vez que la versión parcheada se confirme en todos los servidores, las medidas de mitigación se pueden revertir de forma segura:
No revierta ninguna de las medidas de mitigación hasta que la versión parcheada esté confirmada en todos los servidores de su flota. Un solo servidor sin parchear con los subdominios proxy reactivados es suficiente para exponer todas las cuentas de clientes que contenga.
El punto más amplio
Este incidente ilustra algo importante sobre lo que realmente significa "hosting gestionado". Todos los entornos de hosting basados en cPanel del mundo quedaron expuestos por esta advertencia. La diferencia entre los proveedores no radica en si existe o no la vulnerabilidad, sino en la rapidez con que el operador responde y si sus clientes tuvieron que tomar alguna medida al respecto.
Nuestros clientes no hicieron nada. No recibieron ningún correo electrónico que requiriera alguna acción. No iniciaron sesión para ejecutar ningún comando. Estaban protegidos incluso antes de que la mayoría de la industria hubiera terminado de redactar sus actualizaciones de estado. Eso representa 25 años de experiencia operativa que dan como resultado un tiempo de respuesta que se mide en minutos, no en horas.
Si utilizas un VPS gestionado con un proveedor que te envió instrucciones para aplicar esta medida de mitigación por tu cuenta, conviene reflexionar sobre ello. Un servidor gestionado debe gestionarse, especialmente cuando se produce una vulnerabilidad crítica a las 19:39 UTC de un lunes por la noche.
El alojamiento gestionado significa que nosotros nos encargamos de las emergencias. No usted.
Se ha descubierto una vulnerabilidad crítica. Todos los clientes de RemarkableCloud están protegidos en minutos. No se requiere ninguna acción por parte de los clientes. Eso es lo que significa una gestión integral.
Ver planes de Cloud Cube
