Qué hacer primero si tu WordPress está hackeado
Limita el acceso público desde el hosting, guarda una copia del estado actual y avisa al proveedor. Después investiga el acceso y prepara una recuperación limpia. Instalar un plugin o restaurar a ciegas puede dejar sin resolver la causa de la infección.
Si ves redirecciones extrañas, contenido que no publicaste, administradores desconocidos o un aviso de seguridad, trata la web como un posible incidente. Una pantalla blanca por sí sola no confirma un hackeo: también puede venir de un error de código. Conserva los indicios y comprueba qué está ocurriendo.
Orden de actuación y qué debes conservar
| Etapa | Acción | Resultado que comprobar |
|---|---|---|
| Contener | Restringir acceso o servir una página estática desde infraestructura fiable | El visitante no recibe el contenido sospechoso |
| Preservar | Guardar archivos, base de datos, registros y fechas observadas | Existe una copia separada para investigar |
| Diagnosticar | Revisar accesos, componentes y cambios | Hay una explicación respaldada por indicios, o incertidumbres anotadas |
| Recuperar | Reponer componentes fiables y cerrar el acceso identificado | La web funciona en un entorno controlado |
| Verificar | Probar rutas, sesiones, cuentas y señales de infección | Las pruebas acordadas pasan y existe seguimiento |
1. Contén el incidente sin borrar el rastro
Pide al hosting que limite el acceso desde una capa ajena a WordPress. Un modo mantenimiento instalado como plugin depende de la aplicación que estás investigando. Guarda una copia de archivos y base de datos en una ubicación separada; no la uses como copia limpia para restaurar.
Anota qué has visto, la hora y las URLs afectadas. Solicita los registros disponibles y conserva las comunicaciones del proveedor. Las fechas de archivos orientan, pero pueden alterarse: no demuestran por sí solas qué es malware ni cuándo empezó el ataque.
2. Revisa accesos y componentes
- Cuentas: identifica administradores, accesos al hosting, SFTP y cuentas técnicas. Conserva los indicios antes de retirar un acceso no autorizado.
- Plugins y temas: comprueba versiones, origen y avisos del proveedor. Una extensión desactualizada es una posible vía, no una conclusión automática.
- Archivos y configuración: revisa cambios en núcleo, plugins, temas, uploads,
mu-pluginsy reglas del servidor. - Base de datos: busca usuarios, opciones, contenidos o enlaces inesperados, comparando con lo que debería existir.
La comparación con archivos oficiales ayuda a localizar cambios. wp core verify-checksums comprueba archivos del núcleo frente a sus checksums oficiales; no acredita que plugins, temas o base de datos estén limpios. Consulta su documentación de WP-CLI antes de ejecutarlo.
Investiga sobre una copia aislada siempre que sea posible. Evita ejecutar tareas o código de la instalación comprometida solo para ver qué hacen.
3. Recupera una versión fiable y cierra el acceso
Valida que la copia elegida sea anterior a los indicios y revisa su contenido; una fecha antigua no garantiza limpieza. Si no hay copia fiable, puede hacer falta reconstruir componentes desde fuentes oficiales y revisar los datos conservados. Reinstalar WordPress no elimina contenido malicioso guardado en la base.
Actualiza o retira el componente afectado, revisa permisos y cambia credenciales desde un equipo de confianza. Si cambias la contraseña de la base de datos, actualiza también la configuración para mantener la conexión. Invalida sesiones y revisa claves de acceso; una contraseña nueva no corrige una vulnerabilidad que sigue abierta.
La guía oficial de WordPress para sitios comprometidos recoge medidas de recuperación. El procedimiento concreto depende de los accesos disponibles y de la extensión del incidente.
4. Comprueba la web antes de reabrirla
- Portada, páginas afectadas y enlaces desde buscadores, también sin sesión.
- Inicio de sesión, usuarios autorizados y ausencia de accesos pendientes de retirar.
- Formularios y entrega de correo; en una tienda, pago, pedidos y devoluciones con datos de prueba.
- Registros y archivos que vuelven a cambiar sin una acción prevista.
- Copias y capacidad de restauración fuera de la instalación afectada.
Documenta qué se ha revisado y qué queda por confirmar. Un escaneo sin alertas es una comprobación más, no una garantía de ausencia de infección.
Si Google muestra un aviso de seguridad
Revisa el informe de problemas de seguridad en Search Console. Cuando hayas solucionado los problemas descritos, solicita revisión explicando los cambios y comprobaciones. No prometas una fecha de retirada del aviso: Google debe completar su revisión. El procedimiento está en la ayuda oficial de Search Console.
Después: evita repetir la misma incidencia
Prepara actualizaciones probadas, control de cuentas, copias separadas y seguimiento de rutas importantes. Tienes el detalle en nuestra guía de mantenimiento WordPress y el alcance del servicio en mantenimiento web.
Si necesitas intervención ahora, cuéntanos qué ocurre en el canal de soporte urgente. Explicaremos qué acceso necesitamos y cómo abordar la recuperación.
Equipo Codanter
Desarrollo web, IA y automatización