La seguridad del alojamiento web se decide en las horas posteriores a que se haga pública una vulnerabilidad. No es la lista de características lo que la determina. En este artículo te explicamos cómo gestionó InMotion Hosting la vulnerabilidad CVE-2026-41940, un zero-day crítico de cPanel . Te contamos qué medidas de protección se activan automáticamente sin que tengas que hacer nada, qué es lo que sigue siendo tu responsabilidad en cada tipo de plan y las preguntas que debes hacerle a cualquier proveedor de alojamiento antes de que aparezca la próxima vulnerabilidad crítica.
El alojamiento web seguro depende de lo rápido que tu proveedor pueda eliminar el riesgo una vez que se hace pública una vulnerabilidad crítica. En la práctica, para ello se necesitan tres cosas. El proveedor bloquea el servicio vulnerable en el perímetro de la red en cuestión de horas. Aplica los parches a todos los servidores sin esperar a que los clientes lo hagan. Y da instrucciones claras al pequeño grupo que necesita ayuda práctica. Cuando cPanel reveló el CVE-2026-41940 el 28 de abril de 2026, InMotion Hosting cumplió con estos tres requisitos. De los 144 870 clientes potencialmente expuestos, el 99 % siguió protegido sin interrupción del servicio.
¿Por qué el «plazo de aplicación de parches» es la cifra más importante en la seguridad del alojamiento web?
Los atacantes han cambiado su método de acceso preferido. El Informe de Investigaciones sobre Fugas de Datos de Verizon de 2026 reveló que el aprovechamiento de vulnerabilidades, junto con el uso de credenciales robadas, se situó como el principal vector de acceso inicial —algo inédito en la historia del informe—, alcanzando el 31 % de los casos de acceso inicial. Los defensores, por su parte, han hecho lo contrario. El tiempo medio para aplicar todos los parches aumentó a 43 días, frente a los 32 del año anterior.
Cuarenta y tres días serían un problema incluso si los atacantes esperaran a que hubiera parches. Pero no lo hacen. El informe «M-Trends 2026» de Mandiant sitúa el tiempo medio estimado para aprovechar una vulnerabilidad en menos siete días, lo que significa que los ataques suelen empezar antes de que se publique una solución.
WordPress Los sitios web se enfrentan a plazos aún más ajustados. El informe «State of WordPress Security in 2026» de Patchstack sitúa la mediana ponderada del tiempo hasta la primera explotación en cinco horas. El mismo informe reveló que el 46 % de las vulnerabilidades de WordPress no tenían ninguna solución disponible cuando se dieron a conocer.
Imagina al dueño de una tienda que actualiza los plugins todos los viernes por la mañana. Ese dueño sigue un ciclo semanal, mientras que los atacantes lo hacen cada hora. Hay algunas capas que están totalmente fuera del alcance del dueño: el panel de control, el kernel de Linux y la red. Para esas, la única ventana de parches que cuenta es la del servidor.
¿Cómo fue realmente la respuesta ante una vulnerabilidad de día cero en cPanel (CVE-2026-41940)?
CVE-2026-41940 es una vulnerabilidad que permite eludir la autenticación previa en cPanel y WHM, con una puntuación CVSS de 9,8. Los investigadores de watchTowr Labs descubrieron que encadena tres fallos distintos en la forma en que cPanel gestiona los inicios de sesión y las sesiones. Un atacante que pudiera acceder a un servidor vulnerable no necesitaba nombre de usuario, contraseña ni código de autenticación de dos factores (2FA) para conseguir acceso de root. Según los datos de Shodan, alrededor de 1,5 millones de instancias de cPanel expuestas a Internet estaban en peligro.
La vulnerabilidad ya se estaba aprovechando antes de que la mayoría de la gente supiera que existía. Los investigadores ya habían informado de indicios de que se estaba explotando a finales de febrero de 2026, unos dos meses antes de que cPanel lanzara un parche. La CISA fijó entonces el 3 de mayo como fecha límite para que las agencias federales corrigieran el problema.
| Fecha | Hito |
|---|---|
| A finales de febrero de 2026 | Más tarde, los investigadores localizaron en esta ventana las primeras pruebas de la vulnerabilidad |
| 28 de abril | cPanel publica el parche; InMotion cierra los puertos afectados en el perímetro de la red en las tres regiones de centros de datos en cuestión de horas y empieza a aplicar los parches de forma automática |
| 30 de abril | La CISA añade CVE-2026-41940 a su catálogo de vulnerabilidades explotadas conocidas |
| 1 de mayo | InMotion publica su informe técnico de seguimiento con los pasos de verificación para los administradores de servidores |
| 13 de mayo | cPanel lanza una segunda actualización que cubre cinco CVE más; InMotion la aplica a los entornos gestionados ese mismo día |
¿Cómo lograron mantener las páginas web en línea gracias a dos vías paralelas?
La primera medida eliminó la superficie de ataque. El equipo de operaciones de red de InMotion cerró los puertos de gestión de cPanel, WHM, Webmail y WebDisk (2082, 2083, 2086, 2087, 2095, 2096, 2077 y 2078) en el perímetro de la red de los centros de datos del este y el oeste de EE. UU. y de Europa. Las páginas web, las aplicaciones, las bases de datos y el correo electrónico funcionan en puertos estándar, así que siguieron funcionando. El Panel de gestión de cuentas (AMP) también siguió estando disponible.
La segunda vía solucionó el fallo subyacente. Los ingenieros perfeccionaron los scripts automatizados para implementar la actualización oficial de cPanel en todos los servidores que cumplían los requisitos. Solo reabrieron el acceso a los puertos en cada servidor una vez que se confirmó que se trataba de una versión parcheada. Algunos servidores no pudieron recibir la actualización debido a la restricción de versión o a que la versión de cPanel había llegado al final de su ciclo de vida. Esos servidores permanecieron bloqueados, y el equipo se puso en contacto directamente con sus propietarios. A algunos de esos clientes se les trasladó a un hardware nuevo y recibieron los datos del nuevo servidor y las listas de comprobación para la migración.
«Para la mayoría de nuestros clientes con servicios gestionados, todo se resolvió sin que tuvieran que mover un dedo. En el caso de ese pequeño grupo cuyos entornos requerían atención directa, nuestro equipo se puso en contacto de forma proactiva para explicarles claramente los siguientes pasos y siguió al tanto del asunto hasta que todo quedó resuelto. Esa responsabilidad activa es precisamente lo que debería caracterizar a una relación de alojamiento gestionado». John Joseph, director de Éxito del Cliente, InMotion Hosting
¿Sigue siendo « cPanel » un panel de control fiable?
Sí. Cualquier software que se ejecute en cientos de miles de servidores conectados a Internet va a ser objeto de un intenso interés por parte de los investigadores, y parte de esa investigación sacará a la luz errores críticos. La cifra de 1,5 millones mide el alcance de cPanel. No es una señal de que cPanel sea especialmente vulnerable. cPanel lanzó una corrección y publicó un script de indicadores de compromiso para los administradores. Tu vulnerabilidad depende de la rapidez con la que tu proveedor de alojamiento actúe ante lanzamientos como ese.
¿Cómo ayuda una red privada propia a acelerar la protección contra amenazas de día cero?
La mayoría de los proveedores protegen un servicio vulnerable añadiendo reglas de cortafuegos en cada servidor. Eso funciona, pero es lento. El tiempo que se tarda en conseguir una cobertura total aumenta con el número de servidores, y cada servidor tiene que estar accesible y en buen estado para aceptar la regla. Como InMotion funciona con hardware propio y una red privada, puede aplicar el bloqueo de una sola vez en el perímetro de cada región. El tráfico de ataque ni siquiera llega al servidor.
| Factor | Bloque del borde de la red | Bloqueo por servidor |
|---|---|---|
| Cuándo se aplica la norma | Antes de que el tráfico llegue a cualquier servidor | En el cortafuegos de cada servidor |
| ¿Quién puede solicitarlo? | El proveedor que gestiona la red | Un administrador en cada servidor |
| Tiempo hasta la cobertura total | Un cambio por región | Aumenta según el número de servidores |
| Servidores fijados, obsoletos o que se pasan por alto | Se cubre automáticamente | Es fácil pasarlo por alto |
| Repercusión en el tráfico de la web | Ninguna cuando solo se cierran los puertos de gestión | Ninguna, si está bien configurado |
«Como somos dueños y gestionamos nuestra propia infraestructura de red global, nuestro equipo de operaciones de red bloqueó el acceso externo a los puertos vulnerables en el perímetro de nuestra red a las pocas horas de que se hiciera pública la información». Erik Soroka, director de TI y operaciones del centro de datos, InMotion Hosting
Esto nunca lo verás en una página de precios. Y, sin embargo, es lo que determina si la exposición dura horas o días.
¿Qué medidas de seguridad se ejecutan automáticamente en un servidor gestionado?
La respuesta de « cPanel » no fue algo puntual. Ahora hay otras medidas de protección activas en toda la flota de InMotion sin que los clientes tengan que configurar nada.
Actualizaciones del panel de control el mismo día. El 13 de mayo de 2026, cPanel publicó correcciones para otras cinco vulnerabilidades clasificadas como «Alta». InMotion aplicó esa actualización en todos los entornos gestionados: Shared, WordPress, Reseller, VPS y Dedicated el mismo día del lanzamiento, y los clientes no tuvieron que hacer nada.
Medidas de mitigación a nivel del kernel antes de que se implementaran las correcciones del desarrollador original. La vulnerabilidad «Dirty Frag» se dio a conocer el 7 de mayo de 2026. Combina dos fallos del kernel de Linux (CVE-2026-43284 y CVE-2026-43500), lo que permite a un usuario local sin privilegios obtener privilegios de root en la mayoría de las principales distribuciones. Esto es importante en los servidores de alojamiento, ya que una cuenta de un sitio web comprometida puede convertirse en un «usuario local». InMotion impidió que los módulos del kernel afectados se cargaran en toda su flota de servidores dedicados. Los clientes de VPS quedaron protegidos automáticamente a nivel de los nodos subyacentes.
Protección de aplicaciones en tiempo de ejecución. En agosto de 2026, InMotion implementó Monarx ThreatShield en todo su parque de servidores. ThreatShield se ejecuta dentro del motor PHP y supervisa lo que hace realmente el código a medida que se ejecuta. Esa capa es importante porque las pruebas de Patchstack revelaron que las defensas tradicionales, como los WAF y ModSecurity, solo bloqueaban el 12 % de los ataques dirigidos a vulnerabilidades conocidas de WordPress que ya se habían explotado.
Detección y eliminación de malware. La protección contra malware de Monarx, con mitigación automática, está incluida en el plan Premier Care para servidores VPS y dedicados. También está disponible como complemento.
¿Qué tareas de seguridad te ofrece tu plan de alojamiento?
La seguridad del alojamiento gestionado sigue repartiendo las responsabilidades entre tú y tu proveedor de alojamiento. Dónde se traza la línea divisoria depende de tu plan.
| Tipo de plan | Actualizaciones del panel de control y del sistema operativo | Lo que tienes |
|---|---|---|
| Compartido, WordPress, Distribuidor | InMotion lo aplica automáticamente | WordPress núcleo, plugins, temas, contraseñas, cuentas de usuario y mantenimiento de las cuentas de los clientes para revendedores |
| VPS gestionado, servidor dedicado gestionado | InMotion lo aplica automáticamente | La capa de aplicación, las credenciales y el software personalizado que instales |
| VPS y servidores dedicados autogestionados | InMotion te ofrece consejos sobre parches y asistencia las 24 horas del día, los 7 días de la semana | Todo lo anterior, además de comprobar el estado de los parches, las actualizaciones del kernel y del sistema operativo, y las reglas del cortafuegos |
¿Por qué la autenticación de dos factores no impidió este ataque?
Esto sorprende a muchos propietarios de sitios web. El exploit CVE-2026-41940 marcaba la sesión como «verificada con 2FA» antes de que apareciera ninguna solicitud de 2FA. Hasta que se aplicaron los parches a los servidores, bloquear los puertos era la única defensa fiable. Mantén la 2FA activada de todas formas. El uso indebido de credenciales sigue representando una parte importante de las filtraciones, y la 2FA detiene la mayoría de ellas. Pero no confíes en que la 2FA te proteja de un fallo que se salta el inicio de sesión por completo.
¿Qué hábitos de seguridad siguen dando sus frutos?
- Cambia tus credenciales cada vez que haya un aviso del panel de control. Cambia tus contraseñas de cPanel, WHM y las bases de datos. Considera que cualquier credencial almacenada en archivos dentro de tu directorio raíz web está expuesta.
- Elimina los plugins que no uses. Los plugins representaron el 91 % de las vulnerabilidades de WordPress en 2025. Los plugins de pago del marketplace tenían tres veces más vulnerabilidades conocidas que habían sido explotadas que los gratuitos.
- Activa la autenticación de dos factores (2FA) para las cuentas de cPanel, WordPress (administrador) y de correo electrónico.
- Guarda las copias de seguridad en un lugar distinto al servidor que protegen.
- Comprueba si hay inicios de sesión y cuentas que no reconozcas. Tras recibir un aviso, revisa el registro de «Último inicio de sesión» de cPanel, así como tus cuentas FTP, cuentas de correo electrónico y claves SSH.
¿Qué deben comprobar los propietarios de servidores autogestionados?
Si gestionas tu propio VPS o servidor dedicado, comprueba la versión de cPanel a través de SSH:
/usr/local/cpanel/cpanel -VSi el resultado no coincide con una versión parcheada, fuerza la actualización y reinicia el servicio « cPanel »:
/scripts/upcp --force
/scripts/restartsrv_cpsrvd --hardA continuación, ejecuta el script de detección de indicadores de compromiso que aparece en el aviso oficial decPanel. La lista de comprobación completa la encontrarás en nuestro artículo técnico de seguimiento.
¿Qué preguntas deberías hacerle a tu proveedor de alojamiento web sobre la seguridad?
Pregunta esto antes de contratar o renovar el servicio, no cuando se produzca el próximo incidente:
- ¿Se puede bloquear un servicio vulnerable en el perímetro de la red en todos los centros de datos sin que afecte al tráfico de la web? Una buena respuesta debe indicar cuál es el mecanismo y cuánto tiempo lleva.
- ¿Cuál es tu plazo objetivo para corregir las vulnerabilidades de la lista KEV de la CISA? Las agencias federales tardaron unos tres días en solucionar la CVE-2026-41940, mientras que la mediana del DBIR es de 43 días. Pregunta a tu proveedor cómo es su proceso.
- ¿Tienen que hacer algo los clientes con servicio gestionado cuando se lanza una actualización del panel de control o un parche del kernel? En un plan gestionado, la respuesta suele ser no.
- ¿Qué pasa con los servidores que no pueden instalar el parche? Busca un plan que cubra las versiones fijadas y el software al final de su ciclo de vida, no solo los casos más sencillos.
- ¿Quién se pone en contacto conmigo si mi entorno necesita una intervención manual, y cómo? Una comunicación proactiva con pasos concretos a seguir es mejor que una página de estado genérica.
- ¿Tu equipo de asistencia es interno y está disponible las 24 horas del día, los 7 días de la semana, en caso de que surja algún incidente? Los técnicos de InMotion completan más de 280 horas de formación antes de pasar al Nivel 1, y la antigüedad media en el equipo de asistencia es de más de cinco años.
- ¿Qué se ejecuta en la capa de aplicación para detener los ataques antes de que haya un parche? La protección en tiempo de ejecución cubre ese periodo previo a la publicación de una corrección, en el que los parches por sí solos no bastan.
¿Qué se adapta mejor a tus necesidades de seguridad: un VPS gestionado o un servidor dedicado gestionado?
El alojamiento gestionado es la mejor opción en tres situaciones. Tu web genera ingresos cada hora que está en línea. Eres una agencia a cargo de las webs de tus clientes. O nadie de tu equipo tiene tiempo para estar pendiente de los avisos de cPanel y las vulnerabilidades del kernel. En cada uno de estos casos, el valor principal son las correcciones que llegan sin que el cliente tenga que hacer nada.
El alojamiento VPS gestionado cubre la mayoría de las páginas web de empresas individuales y las tiendas de WooCommerce en expansión. Los servidores dedicados gestionados son ideales para cargas de trabajo con mucho tráfico, agencias que gestionan docenas de páginas web de clientes y equipos que necesitan aislamiento a nivel de hardware. Si tienes un administrador de sistemas competente y quieres control total de root, un plan autogestionado te vendrá bien, siempre y cuando alguien se encargue de la lista de parches.
En cualquiera de los dos planes gestionados, Premier Care añade la protección contra malware Monarx y almacenamiento dedicado para copias de seguridad (300 GB en VPS, 500 GB en servidor dedicado). También incluye asistencia técnica avanzada prioritaria para el producto en VPS y una hora al mes de asesoramiento de InMotion Solutions en el servidor dedicado.
Se avecina la próxima vulnerabilidad crítica (CVE). Elige un proveedor de alojamiento que ya haya demostrado que puede solucionar el problema en cuestión de horas. Habla con nuestro equipo para encontrar el plan gestionado más adecuado para tu carga de trabajo.