Restaurar un sitio WordPress después de un hackeo, sin revivir el problema

Cuando un sitio de WordPress es pirateado, el primer reflejo es restaurar la última copia de seguridad. Suele ser un error: realizada demasiado tarde, ya contiene la puerta trasera; restaurada sin cerrar la brecha, el sitio vuelve a caer en unos días. Esta guía sigue el orden recomendado por WordPress.org, por Cybermalveillance.gouv.fr, el dispositivo nacional de asistencia a las víctimas, y por los equipos de Sucuri, con el caso particular de las claves de UpdraftCentral robadas en octubre de 2026.

Antes de restaurar: cuatro acciones

Poner el sitio fuera de línea. Cybermalveillance.gouv.fr recomienda desconectar primero lo afectado: pide a tu proveedor de alojamiento que coloque el sitio en mantenimiento o bloquee el acceso durante la limpieza.

Conservar las pruebas. Registros del servidor, capturas de pantalla, fecha y hora de lo que hayas visto, últimas acciones realizadas en el sitio: anota todo. Estos elementos sirven para fechar la intrusión y presentar una denuncia si decides hacerlo.

Hacer una copia del estado actual. Archivos y base de datos, fuera del servidor, antes de tocar nada. Es una prueba, no un punto de restauración.

Cambiar los accesos. Contraseñas de los administradores, del FTP o SFTP, de la base de datos y del espacio de alojamiento, y luego las claves secretas de wp-config.php, que desconectan a todos. WordPress.org pide repetirlo después de la limpieza.

Elegir la copia de seguridad adecuada

Fechar la intrusión. Es la pregunta que lo decide todo. Cuatro indicios ayudan: la fecha de creación de cuentas desconocidas, la fecha de los archivos modificados recientemente (el gestor de archivos del alojamiento los ordena por fecha), la primera consulta sospechosa en los registros de acceso, y la fecha de aparición de las páginas de spam en la Search Console.

Las fechas conocidas del otoño de 2026. Para UpdraftCentral, toma una copia de seguridad de antes del 17 de octubre; para la campaña que pasa por Ninja Forms, de antes del 4 de octubre; para Bricksforge, de antes del 7 de octubre; para la vulnerabilidad del núcleo explotada desde el 22 de septiembre, de antes de esa fecha si el sitio no tenía el parche.

Verificar la copia de seguridad antes de usarla. Ábrela y revisa la lista de extensiones y la carpeta wp-content/uploads: una copia de seguridad que ya contenga la extensión sospechosa o un archivo .php en los envíos no te sirve de nada.

Si ninguna copia de seguridad es lo suficientemente antigua. Hay que limpiar sobre el terreno: es más largo, y el resto sigue aplicándose igual.

Restaurar correctamente

El corazón de WordPress, renovado. WordPress.org recomienda reinstalar la misma versión de WordPress mediante FTP o SFTP, no con el botón de reinstalación del panel de administración, que solo sobrescribe los archivos existentes y deja intactos los archivos añadidos. Las carpetas wp-admin y wp-includes se reemplazan completamente por una copia limpia.

Las extensiones y la plantilla, desde su fuente. Sucuri recomienda reinstalarlas desde wordpress.org o desde el sitio del editor, en lugar de restaurarlas desde la copia de seguridad. No reemplace ciegamente la carpeta wp-content ni el archivo wp-config.php: contienen sus contenidos y configuraciones.

Los archivos a revisar. WordPress.org menciona .htaccess y index.php, y en la plantilla, header.php, footer.php y functions.php: ahí es donde suelen ocultarse las redirecciones más frecuentes. En la base de datos, Sucuri recomienda buscar eval, base64_decode, gzinflate y shell_exec, que no deberían aparecer en el contenido de una página.

Justo después: cerrar la puerta

Actualizar inmediatamente. Una copia de seguridad también restaura las versiones antiguas, por lo que la vulnerabilidad por la que el atacante entró sigue presente. WordPress (7.1.3, o la última versión de su rama), la plantilla, todas las extensiones y la versión de PHP en el alojamiento, antes de volver a poner el sitio en línea.

Eliminar nuevamente la clave UpdraftCentral. Una copia de seguridad anterior al 17 de octubre aún contiene la antigua clave: WP Staging recomienda eliminarla justo después de la restauración, luego volver a cambiar las contraseñas y las claves secretas. El procedimiento está en mi guía UpdraftPlus.

Cambiar las contraseñas una segunda vez. Todas, incluyendo la base de datos, como pide WordPress.org.

Levantar las alertas. En la Search Console, una vez que el sitio esté limpio, solicite una revisión desde el informe Problemas de seguridad. Si el alojamiento había suspendido el sitio, envíele un informe de lo realizado.

Después de volver a poner el sitio en línea

Comprender cómo entró el atacante. Sin respuesta a esta pregunta, la misma puerta sigue abierta: extensión desactualizada, contraseña reutilizada, clave UpdraftCentral, cuenta FTP olvidada. WordPress.org coloca este análisis justo antes de fortalecer el sitio.

Una rutina. Una copia de seguridad fuera del servidor cada semana, verificada de vez en cuando con una restauración real en una copia; las actualizaciones cada mes; la autenticación en dos pasos para cada administrador; las extensiones no utilizadas eliminadas.

Los procedimientos. Si el sitio guarda datos personales, la notificación a la CNIL debe hacerse en un plazo de 72 horas desde que haya un riesgo para las personas. La ficha de Cybermalveillance.gouv.fr recuerda que la CNIL considera una defaceación del sitio como una violación de datos personales, y también recomienda presentar una denuncia y buscar ayuda de profesionales.

Preguntas frecuentes

Mi última copia de seguridad es de después del pirateo: ¿qué hacer?
Limpiar sobre la marcha, con el mismo método: núcleo reinstalado desde cero, extensiones y tema desde su fuente original, cuentas y archivos desconocidos eliminados, base de datos revisada. Es más largo que una restauración, y el resultado depende de lo que se haya logrado encontrar: una nueva verificación en las semanas siguientes es indispensable.

¿Cuánto tiempo lleva?
Para un sitio web corporativo con una buena copia de seguridad, cuente medio día de trabajo. Para una tienda en línea o un sitio sin copia de seguridad utilizable, más tiempo.

¿Cuánto cuesta una restauración por un profesional?
En mi caso, la actualización de un sitio comienza en 190 €; la limpieza y la restauración se cotizan tras un diagnóstico gratuito, ya que dependen del estado del sitio y de las copias de seguridad. El detalle está en la página de intervención a distancia.

¿Debo informar a mis clientes?
Si sus datos pudieron ser leídos y el riesgo para ellos es alto, sí: es una obligación, además de la notificación a la CNIL. Un sitio web corporativo sin ningún dato registrado no tiene nada que declarar.

¿Necesitas ayuda?

Empieza por verificar tu sitio gratuitamente, luego sigue las verificaciones que debes hacer hoy. Si el resultado le preocupa, o si no sabe qué copia de seguridad elegir: reviso en menos de 24 horas y le digo lo que veo, sin costo. Si me encarga la restauración, le escribo paso a paso lo que se ha hecho.

Fuentes: FAQ « Mi sitio fue hackeado », WordPress.org, hoja de referencia sobre la defaceación de sitios, Cybermalveillance.gouv.fr, 7 pasos para eliminar un malware de WordPress, Sucuri, limpiar un WordPress pirateado, Sucuri, incidente UpdraftCentral, guía de WP Staging, incidente de octubre de 2026, TeamUpdraft, notificar una violación de datos personales, CNIL.