# ¿Cambiar de CMS tras el hackeo? Cuándo ayuda y cuándo no

> ¿Cambiar de CMS tras un hackeo? Cuándo un sistema nuevo ayuda de verdad, cuándo solo traslada el esfuerzo y cómo migrar contenidos sin código malicioso.

Fuente: https://phpsos.de/es/blog/cms-wechsel-nach-hack/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** cambiar de CMS tras un hackeo solo ayuda si el propio sistema antiguo fue la causa, por ejemplo porque el fabricante ya no entrega actualizaciones de seguridad o porque extensiones importantes ya no se mantienen. Si la causa estuvo en plugins obsoletos, accesos débiles o una vulnerabilidad como PHP2Shell en el PHP subyacente, un cambio solo traslada el esfuerzo. En cualquier caso vale: primero revisar los contenidos y luego migrar; de lo contrario, el código malicioso se muda con ellos.

## Cuando la confianza se ha perdido

Tras una intrusión, el ánimo suele ser claro: «Con este sistema nunca más». Es comprensible. El sitio web ha redirigido a los visitantes a páginas ajenas, Google ha dado la alerta, los clientes han preguntado. Un CMS nuevo se siente como un nuevo comienzo.

Pero la situación de PHP2Shell muestra por qué este reflejo puede llevar a error. La vulnerabilidad está en el intérprete de PHP, no en WordPress, TYPO3, Shopware ni en ningún otro sistema. Según drweb.de, WordPress.org no prevé por ello una actualización propia contra ella. Quien ahora cambia de un CMS en PHP a otro CMS en PHP acaba teniendo la misma dependencia, solo que con otro logotipo. Qué sistemas funcionan con PHP lo muestra el resumen [Qué CMS y sistemas de tienda funcionan con PHP](https://phpsos.de/es/php/cms-und-shops-auf-php/).

## Lo que decide es la causa

Antes de pensar en un cambio, debe estar aclarada la causa de la intrusión. Las puertas de entrada típicas son extensiones obsoletas, contraseñas débiles o reutilizadas, falta de autenticación de dos factores, un servidor sin parchear o instalaciones de prueba olvidadas. Ninguna de estas causas está ligada a un CMS concreto.

Quien no conoce la causa corre el riesgo de llevársela al nuevo sistema. Un equipo que hasta ahora ha aplazado las actualizaciones lo hará igual en el nuevo CMS. Una agencia que usaba cuentas de administrador compartidas lo repetirá si nadie cambia el procedimiento. La pregunta no es tanto «¿qué CMS?» como «¿qué proceso?».

## Cambiar de CMS tras el hackeo: la ponderación

| Criterio | Mantener el CMS actual y reforzarlo | Cambiar a otro CMS |
|---|---|---|
| Causa de la intrusión | Conocida y subsanable, por ejemplo un plugin obsoleto | Está en el propio sistema, por ejemplo falta de actualizaciones del fabricante |
| Mantenimiento del fabricante | Se entregan actualizaciones de seguridad | El fabricante ha dejado de mantenerlo |
| Dependencia de extensiones | Pocas, mantenidas | Muchas extensiones sin mantenimiento activo |
| Esfuerzo | Limpieza, refuerzo, cambio de proceso | Reconstrucción, migración, formación, a menudo nuevo diseño |
| Tiempo hasta un sitio web seguro | Más corto | Más largo, hace falta una solución transitoria |
| Protección frente a vulnerabilidades de PHP | Sin cambios, hay que parchear PHP | Sin cambios, mientras el nuevo sistema use PHP |
| Utilidad a largo plazo | Alta, si se mejoran los procesos | Alta, si el sistema antiguo ya estaba al final |

Si en su situación la mayoría de las filas caen a la izquierda, el cambio apenas compensa. Quedarse, limpiar, reforzar y mejorar el procedimiento de mantenimiento aporta más seguridad por menos dinero. Para los operadores de WordPress, [WordPress y PHP2Shell](https://phpsos.de/es/plattformen/wordpress/) resume los pasos más importantes.

No siempre necesita un proveedor de servicios para esta decisión. Si la causa era inequívoca, por ejemplo un plugin conocido con una vulnerabilidad publicada, y su agencia o su administrador ha reinstalado limpiamente el sitio web, puede decidir usted mismo. La ayuda externa compensa si la causa sigue sin estar clara o podrían estar afectados datos personales.

## Si cambia: no se lleve el código malicioso

Si se decide por un cambio, la migración en sí es un riesgo de seguridad. Los atacantes dejan rastros no solo en archivos, sino también en la base de datos. Estos pasos ayudan a migrar con limpieza:

1. **Asegurar y aislar el sistema antiguo:** copia de seguridad completa como prueba, después sacar el sistema antiguo de la red o dejarlo accesible solo internamente.
2. **Exportar los contenidos de forma selectiva:** textos, estructura de páginas y medios, no la base de datos completa. No trasladar las cuentas de usuario, sino crearlas de nuevo.
3. **Revisar los contenidos:** examinar los textos en busca de scripts inyectados, enlaces ocultos y redirecciones ajenas. Cómo hacerlo lo describe [Revisar la base de datos en busca de código inyectado](https://phpsos.de/es/blog/datenbank-auf-schadcode-pruefen/).
4. **Filtrar los medios:** trasladar solo los tipos de archivo esperados, descartar archivos con dobles extensiones o contenido de script.
5. **Montar limpiamente el sistema nuevo:** desde la fuente original del fabricante, en un servidor con PHP parcheado, con credenciales nuevas y autenticación de dos factores.
6. **Planificar las redirecciones:** redirigir las direcciones antiguas a las nuevas, para que lleguen los buscadores y los visitantes sin que queden abiertas rutas antiguas.

> **Importante:**
> Un cambio de CMS no sustituye a la limpieza del servidor antiguo. Si el sistema antiguo sigue funcionando, por ejemplo como copia olvidada en un subdominio, la puerta trasera permanece abierta.

## La alternativa que a menudo se pasa por alto

Algunas empresas constatan tras un hackeo que ni siquiera necesitan las funciones de un gran CMS. Un sitio web corporativo con pocas páginas que rara vez cambian se las arregla también sin PHP en el servidor. Un generador de páginas estáticas crea archivos HTML terminados que ya no necesitan lógica de programa en el servidor. Qué ventajas e inconvenientes tiene lo describe [Sitios web estáticos: menos PHP, menos superficie de ataque](https://phpsos.de/es/blog/statische-website-alternative/).

A la inversa, para tiendas, portales o sitios web con muchos redactores esto no suele ser una opción. Aquí sigue teniendo sentido un sistema dinámico, y la seguridad nace del mantenimiento, el refuerzo y la vigilancia.

Quien dude de si en el antiguo WordPress acechan todavía accesos ocultos encontrará en [Encontrar puertas traseras en WordPress](https://phpsos.de/es/ratgeber/backdoor-wordpress-finden/) los lugares típicos donde aparecen. Eso ayuda también a decidir si una limpieza es realista.

## ¿Cómo ayuda PHP SOS en concreto?

- Aclaramos primero la causa de la intrusión y le decimos si está en el CMS o en el proceso y el servidor.
- Limpiamos el sistema existente en el marco de la [eliminación de malware](https://phpsos.de/es/leistungen/malware-entfernung/) o lo preparamos como prueba para una reconstrucción.
- En un cambio revisamos los contenidos y medios que se van a trasladar en busca de código malicioso antes de que lleguen al sistema nuevo.
- Montamos el servidor nuevo con PHP parcheado y configuración reforzada.

## Conclusión

Un cambio de CMS tras un hackeo rara vez es la solución, pero a veces sí el momento adecuado. Si el sistema antiguo ya no se mantiene, el nuevo comienzo compensa. Si la causa estuvo en los procesos o en el servidor, trabajar en el proceso aporta más que un logotipo nuevo. En ambos casos vale: primero revisar y luego migrar.


## Preguntas frecuentes

**¿Ayuda un cambio de CMS frente a PHP2Shell?**  
No, mientras el nuevo CMS también funcione con PHP. PHP2Shell está en el intérprete de PHP, no en el CMS. Lo decisivo es el estado del parche de PHP en el servidor, no el sistema que hay encima.

**¿Es WordPress más inseguro que otros CMS?**  
No se puede afirmar de forma general. Muchas intrusiones se deben a extensiones obsoletas, accesos débiles o falta de actualizaciones, y esas causas existen en cualquier sistema. Eso sí, su difusión convierte a un CMS en objetivo más frecuente de escaneos automatizados.

**¿Puedo exportar sin más los contenidos del CMS hackeado?**  
Solo tras revisarlos. La base de datos puede contener scripts inyectados, enlaces ocultos o cuentas de administrador ajenas. Los archivos subidos pueden camuflar código malicioso. Exporte los contenidos de forma selectiva y revíselos antes de importarlos.

**¿Cuándo tiene realmente sentido un cambio de CMS?**  
Cuando el fabricante ya no entrega actualizaciones de seguridad, cuando el sitio web depende de extensiones que ya no se mantienen o cuando el sistema sencillamente ya no encaja con los requisitos actuales. El hackeo es entonces la ocasión, no el motivo.

## Fuentes

- [WordPress.org](https://wordpress.org/)
- [TYPO3](https://typo3.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Dr. Web: PHP2Shell y WordPress](https://www.drweb.de/php2shell-update-php-versionen/)