En resumen: Quien quiera cambiar de hoster tras un incidente de seguridad debería asegurar primero las pruebas y aclarar el incidente, después transferir solo datos comprobados a un sistema recién montado y dar de baja el contrato antiguo únicamente al final. Al nuevo proveedor se le elige con criterios de seguridad: procesos de parcheo demostrables, separación entre clientes, acceso a los registros, copias de seguridad e interlocutores claros. Cambiar de hoster tiene sentido cuando faltan confianza o rendimiento, pero no sustituye a la limpieza.
Cuando se ha perdido la confianza
Tras PHP2Shell, muchas empresas viven por primera vez a su hoster bajo presión. Algunas recibieron rápido una información clara sobre el nivel de parcheo. Otras esperaron días una respuesta, recibieron solo fórmulas genéricas o descubrieron que su sitio web funcionaba con una versión de PHP obsoleta. Si además se produce un incidente, el deseo de cambiar es comprensible.
Pero cambiar de hoster no es un paso de la gestión del incidente, sino de la reorganización posterior. Quien lo hace en el orden equivocado se lleva, en el peor de los casos, al atacante y pierde a la vez las huellas que muestran lo ocurrido.
El orden correcto en el cambio
- Asegurar las huellas mientras existan. Los registros, archivos y la base de datos del sistema antiguo deben acabar en una copia antes de borrar o rescindir nada. Pida expresamente al hoster antiguo los registros de acceso y de errores desde el 20 de octubre de 2026 y su plazo de conservación. Cómo proceder lo describe el artículo Asegurar pruebas antes de reinstalar.
- Acotar el incidente. ¿Qué sistemas están afectados, qué accesos se utilizaron, qué datos estaban al alcance? De ello dependen las obligaciones de notificación y lo que puede llevarse.
- Comprobar las obligaciones de notificación. Si pueden verse afectados datos personales, el plazo para una posible notificación según el RGPD empieza con el conocimiento del incidente, no con la mudanza. Los antecedentes figuran en Obligación de notificación del RGPD: 72 horas.
- Montar limpio el sistema nuevo. Versión de PHP compatible, paquetes actualizados y configuración reforzada, antes de transferir el primer archivo.
- Transferir solo lo comprobado. Código de una fuente limpia; base de datos y archivos multimedia tras revisarlos.
- Cambiar todas las credenciales. Base de datos, cuentas de administración, SSH, FTP, claves de API, también las que están en archivos de configuración.
- Conmutar y vigilar. Cambio de DNS y, después, una supervisión más estrecha durante un tiempo.
- Dar de baja el contrato antiguo. Solo cuando los registros y las copias estén asegurados y la nueva explotación funcione de forma estable.
No rescinda el contrato antiguo antes de tener en su poder los registros y las copias de seguridad. Con el fin del contrato, el proveedor puede borrar datos que usted necesita para la aseguradora, las autoridades o su propia investigación.
Qué no debería llevarse
Lo cómodo sería copiar sin más el directorio web completo o una imagen del servidor. Precisamente eso es arriesgado tras un incidente. Las webshells se camuflan como archivos inofensivos, las puertas traseras se esconden en archivos de configuración como .htaccess o .user.ini, y el código inyectado puede estar en el contenido de la base de datos.
Por eso, transfiera el código de la aplicación desde una fuente limpia, por ejemplo el paquete del fabricante en la versión adecuada o su sistema de control de versiones. Los archivos multimedia se trasladan sin ficheros ejecutables y la base de datos, tras una revisión de contenidos sospechosos y de nuevas cuentas de administrador. Lo que se encontró en el sistema antiguo ayuda en esa revisión.
Piense también en todo lo que el proveedor antiguo aloja aparte del sitio web. Los buzones de correo, las entradas DNS, los certificados y los reenvíos se olvidan fácilmente en una mudanza. Reduzca el tiempo de validez de las entradas DNS unos días antes de conmutar, para que el cambio llegue pronto a los visitantes. Si también se traslada el correo, planifique el cambio de los buzones por separado, porque tras un incidente también ahí pueden estar afectadas las credenciales.
Elegir al nuevo hoster según la seguridad
El precio y el espacio de almacenamiento figuran en cualquier oferta. Las preguntas de seguridad decisivas suele tener que hacerlas usted mismo. La siguiente lista ayuda a comparar:
| Criterio | Pregunta al proveedor | Por qué importa |
|---|---|---|
| Proceso de parcheo | ¿Cómo y con qué marco se aplican y reinician las actualizaciones de seguridad de PHP? | PHP2Shell ha demostrado lo importante que es un proceso demostrable |
| Justificante | ¿Recibo bajo petición una confirmación por escrito del nivel de parcheo? | Base de su propia documentación |
| Versiones de PHP | ¿Qué ramas se ofrecen y hasta cuándo? | Las ramas antiguas sin actualizaciones son un riesgo permanente |
| Separación | ¿Funciona cada sitio con su propio usuario y su propio proceso de PHP? | Limita los daños si se ataca a un vecino |
| Registros | ¿Tengo acceso a los registros de acceso y de errores y cuánto tiempo se conservan? | Sin registros no hay esclarecimiento |
| Copias de seguridad | ¿Con qué frecuencia, durante cuánto tiempo, separadas del servidor web, con prueba de restauración? | Restauración tras un incidente |
| Contacto de emergencia | ¿Cómo localizo a una persona competente en caso de incidente? | El tiempo es el factor más escaso en una emergencia |
| Encargo de tratamiento | ¿Existe un contrato conforme al RGPD y una lista de subencargados? | Obligatorio si hay datos personales |
Una plantilla para preguntar por el nivel de parcheo la ofrece la guía Preguntar al hoster por el estado del parche. También sirve para comparar proveedores antes de firmar el contrato.
¿Es otro modelo de explotación la mejor respuesta?
A veces el problema está menos en el hoster que en el modelo de explotación. Quien opera un servidor propio sin mantenimiento regular suele estar mejor atendido con una oferta gestionada bien cuidada. A la inversa, una empresa con TI propia puede ganar control sobre los momentos de parcheo si lo administra ella misma. La ponderación la describe el artículo ¿Hosting gestionado o servidor propio?.
Con independencia del modelo, rige esto: deje por escrito el reparto de tareas. ¿Quién aplica las actualizaciones de PHP, quién reinicia, quién revisa la aplicación, quién avisa a quién en una emergencia? En PHP2Shell, muchos retrasos surgieron justo ahí, porque cada parte creía que la otra se ocupaba.
¿Cómo ayuda PHP SOS en concreto?
- Aseguramos los registros y datos del sistema antiguo y aclaramos qué ocurrió en el incidente.
- Montamos el sistema nuevo con refuerzo de seguridad y transferimos solo contenidos comprobados de fuentes limpias.
- Revisamos las ofertas de nuevos proveedores según los criterios de seguridad y formulamos las preguntas adecuadas.
- En un incidente en curso trabajamos en el marco de nuestra respuesta a incidentes, hasta que el incidente esté cerrado y documentado.
Preguntas frecuentes
¿Debo cambiar de hoster inmediatamente tras un hackeo?
No inmediatamente. Primero hay que asegurar las huellas, acotar el incidente y aclarar la causa. Una mudanza precipitada puede llevarse el código malicioso y destruir pruebas en el proveedor antiguo.
¿Tuvo la culpa el hoster si mi sitio fue atacado a través de PHP2Shell?
Depende del contrato y del momento. En el alojamiento compartido suele ser el hoster quien se ocupa de las actualizaciones de PHP; en servidores propios, el operador. Los parches aparecieron el 21 de octubre de 2026; si se aplicaron y cuándo, solo se puede aclarar con justificantes. Para cuestiones de responsabilidad, consulte a un abogado.
¿Qué datos puedo llevarme al nuevo hoster?
Solo contenidos comprobados: la base de datos tras revisar si hay código inyectado, los archivos multimedia sin ficheros ejecutables y el código de una fuente limpia, como el paquete del fabricante o su sistema de control de versiones. No debería transferir sin revisar imágenes completas del servidor ni directorios web del sistema comprometido.
¿Debo implicar a la protección de datos tras un incidente?
Si pueden verse afectados datos personales, puede existir una obligación de notificación según el RGPD, por lo general en 72 horas. Con el nuevo hoster necesita además un contrato de encargo de tratamiento. Aclárelo con su delegado de protección de datos; esto no es asesoramiento jurídico.