Mi sitio WordPress está hackeado: qué hacer, en 10 pasos
Par AIFORYA — 26 de julio de 2026 — 12 min de lecture
En esta página (15)
Si lee esto en plena urgencia, empiece por aquí: no borre nada, no reinstale nada todavía. El error más caro de la primera media hora no es limpiar mal: es borrar las huellas antes de haber entendido por dónde entró el atacante. Sin esa información limpiará, y volverá a infectarse en los días siguientes, casi siempre por la misma puerta.
Esta guía da los diez pasos en orden, con lo que hay que comprobar en cada uno. Está escrita para quien gestiona su sitio sin ser administrador de sistemas. Calcule de dos a cuatro horas para un caso sencillo; más si el sitio es grande o el alojamiento es compartido y lento.
Las señales que le han traído aquí son probablemente una de estas: el sitio redirige a los visitantes a una página desconocida, Google muestra «Este sitio puede dañar tu ordenador», han aparecido páginas en otro idioma en los resultados de búsqueda, el acceso a la administración está bloqueado, o su proveedor ha suspendido la cuenta. Todas llevan al mismo protocolo.
Contenido
- Paso 0: los primeros cinco minutos
- Paso 1: guardar el estado infectado
- Paso 2: cortar el acceso sin romperlo todo
- Paso 3: recuperar el control de las cuentas
- Paso 4: cerrar todas las sesiones abiertas
- Paso 5: encontrar lo que se ha modificado
- Paso 6: buscar las puertas traseras
- Paso 7: limpiar o restaurar
- Paso 8: cerrar la puerta de entrada
- Paso 9: levantar el aviso de Google
- Paso 10: la obligación que se olvida — los datos personales
- Evitar la reincidencia
Paso 0: los primeros cinco minutos
Tres reflejos, en este orden.
No toque nada desde el equipo que podría estar comprometido. Si su ordenador está infectado, cambiar las contraseñas desde ahí equivale a entregárselas al atacante. Use otro equipo, o un teléfono.
No borre los registros. Los registros de acceso de su proveedor (a menudo entre 7 y 30 días de retención) son lo único que le dirá por dónde entró. Pídalos de inmediato si su plan no le da acceso: caducan.
Avise a su proveedor de alojamiento. Muchos tienen un equipo dedicado y, sobre todo: si su servidor envía spam, lo cortarán sin avisar. Haberlos informado cambia esa conversación.
Paso 1: guardar el estado infectado
Contraintuitivo y, aun así, imprescindible. Haga una copia completa —archivos y base de datos— del estado actual, infectado, y guárdela fuera de línea.
Tres razones: es su red de seguridad si la limpieza rompe el sitio; es la única huella aprovechable para entender el ataque; y si hay datos personales implicados, es lo que le permitirá documentar lo ocurrido (véase el paso 10).
Nómbrela con claridad, con la fecha y la palabra «INFECTADO», y no la restaure nunca por error.
Paso 2: cortar el acceso sin romperlo todo
Si el sitio sirve redirecciones o contenido malicioso, cada visitante adicional empeora su situación a ojos de Google y de su proveedor.
El gesto correcto es la página de mantenimiento a nivel de servidor, no borrar el sitio. Usted conserva el control del contenido, los visitantes ven un mensaje honesto, y los buscadores reciben un código HTTP 503 (indisponibilidad temporal) que no destruye su posicionamiento, a diferencia de un sitio que responde con errores durante días.
Paso 3: recuperar el control de las cuentas
Cambie todas las contraseñas, desde un equipo limpio, en este orden: alojamiento, FTP/SFTP, base de datos, cuentas de administrador de WordPress, correo asociado. Un solo olvido basta para volver a empezar.
Después abra la lista de usuarios de WordPress y busque lo que no debería estar: un administrador que no reconoce, una cuenta creada hace poco, o una cuenta existente cuyo rol ha pasado a administrador. No las borre de inmediato: anote antes su correo y su fecha de registro, es información útil sobre la entrada. Luego degrade o elimine.
Compruebe también claves y tokens de acceso: claves API, contraseñas de aplicación, conexiones a servicios de terceros. Son los olvidados clásicos de una limpieza, y siguen siendo válidos tras el cambio de contraseña.
Paso 4: cerrar todas las sesiones abiertas
Cambiar una contraseña no desconecta a quien ya está conectado: su cookie de sesión sigue siendo válida. Un atacante con una sesión abierta la conserva.
La maniobra consiste en regenerar las claves de seguridad de WordPress (las «salts») en el archivo wp-config.php. WordPress ofrece un generador oficial para esos valores. Al sustituirlos, invalida de golpe todas las sesiones existentes, incluida la suya: tendrá que volver a entrar, y el atacante también, salvo que él ya no tiene la contraseña.
Paso 5: encontrar lo que se ha modificado
El objetivo es separar lo que es suyo de lo que se ha añadido.
El núcleo de WordPress es verificable. Los archivos del núcleo tienen huellas oficiales publicadas por el proyecto: cualquier desviación señala un archivo modificado. La mayoría de las herramientas de análisis hacen esa comparación automáticamente: es la comprobación más fiable de que dispone, porque no se apoya en una lista de firmas de virus sino en una referencia exacta.
Dónde mirar primero: wp-config.php, el .htaccess de la raíz (y los de las subcarpetas), index.php, la carpeta wp-content/uploads —ningún archivo .php tiene motivo para vivir ahí— y la carpeta wp-content/mu-plugins, que carga código automáticamente sin aparecer nunca en la lista de extensiones.
Ordenar por fecha de modificación es su mejor aliado: liste los archivos modificados en los días anteriores al incidente. Un archivo de la plantilla modificado el día en que empezó todo, sin que usted tocara nada, le da el punto de partida.
Paso 6: buscar las puertas traseras
Es el paso que se salta, y el que explica las reinfecciones.
Una puerta trasera es un fragmento de código que permite volver incluso después de la limpieza. Sobrevive a un cambio de contraseña y, a menudo, a una actualización. Los sitios habituales:
- Una extensión o plantilla que usted nunca instaló; mire también las plantillas inactivas, rara vez inspeccionadas.
- Una tarea programada que reinstala el código malicioso. Liste las tareas programadas de WordPress y busque las que no correspondan a nada conocido.
- Una cuenta de administrador discreta, creada varios días antes del incidente visible.
- Código inyectado directamente en la base de datos, a menudo en la tabla de opciones o en las entradas.
Mientras la puerta trasera siga ahí, toda limpieza es temporal. Si no está seguro, es el momento de recurrir a un profesional: no es un fracaso, es una decisión de coste.
Paso 7: limpiar o restaurar
Dos vías, y la elección depende de una sola pregunta: ¿tiene una copia de seguridad anterior a la infección?
Si la tiene, restáurela, pero sepa que la restauración por sí sola nunca basta. Devuelve el sitio al estado en que estaba con el fallo que permitió la entrada. Hay que restaurar y después aplicar el paso 8 de inmediato, antes de volver a publicarlo. Una restauración sin corrección es una cuenta atrás.
Si no la tiene, la limpieza se hace por capas: sustituya el núcleo de WordPress por un archivo oficial nuevo, reinstale cada extensión y cada plantilla desde su fuente oficial en lugar de parchear archivos uno a uno, y conserve a mano solo wp-content/uploads, después de haberlo purgado de cualquier archivo ejecutable.
Una palabra sobre las copias, ya que son el eje de este paso: una copia que nunca ha probado no es una copia, es una intención. El día del incidente es el peor momento para descubrir que estaba incompleta.
Paso 8: cerrar la puerta de entrada
La limpieza trata las consecuencias. Este paso trata la causa, y es el único que impide la repetición.
- Actualice todo: el núcleo, las extensiones, las plantillas y la versión de PHP. Una versión de PHP que ya no recibe correcciones de seguridad es una decisión, no una fatalidad: su proveedor casi siempre permite cambiarla.
- Elimine lo que no usa. Cada extensión inactiva y cada plantilla sin uso siguen siendo código presente en el disco, y por tanto explotable. Una extensión desactivada no es una extensión ausente.
- Revise los permisos de los usuarios. Un redactor no necesita ser administrador. La mayoría de las intrusiones pasan por una cuenta que tenía más permisos de los necesarios.
Paso 9: levantar el aviso de Google
Si su sitio ha sido marcado, limpiarlo no basta: el aviso permanece hasta que solicite una revisión.
En Search Console, abra la sección de problemas de seguridad. Indica el tipo de compromiso detectado y, a menudo, URL de ejemplo: úselas para comprobar que no se ha dejado nada. Después solicite la revisión describiendo lo que ha corregido: una solicitud precisa pasa más rápido que una vaga.
Cuente con unos días. Solicite la revisión solo cuando esté realmente limpio: un rechazo alarga el plazo.
Aproveche para revisar los propietarios de su propiedad en Search Console: un atacante que se añade como propietario mantiene visibilidad sobre su sitio mucho después de la limpieza.
Paso 10: la obligación que se olvida — los datos personales
Si su sitio albergaba cuentas de clientes, pedidos, formularios o una lista de correo, un hackeo no es solo un incidente técnico: es potencialmente una violación de datos personales.
En Europa, el RGPD obliga al responsable del tratamiento a notificar a la autoridad de control competente en un plazo de 72 horas desde que tiene constancia, salvo que sea improbable que la violación suponga un riesgo para las personas afectadas, y a informar a estas directamente cuando el riesgo sea alto. El plazo empieza cuando usted tiene conocimiento, no cuando todo está reparado.
Este párrafo no es asesoramiento jurídico y no sustituye a su delegado de protección de datos ni a su asesoría. Lo que importa: no archive el asunto como puramente técnico sin plantearse la pregunta, y documente lo que ha constatado y hecho, que es exactamente para lo que sirve la copia del estado infectado del paso 1.
Evitar la reincidencia
Un sitio limpiado sin cambiar de prácticas es un sitio que volverán a tomar. Tres medidas cubren la inmensa mayoría de los casos reales, y no cuestan casi nada.
La doble autenticación en las cuentas con privilegios. Es la medida que deja inservible el robo de contraseñas, que sigue siendo la vía de entrada más banal.
La protección de la página de acceso. Limitación de intentos, bloqueo tras fallos repetidos, vigilancia de las direcciones que insisten: los ataques automatizados son torpes y masivos, y se detienen ante una puerta que cuenta.
La vigilancia de la integridad de los archivos. Es lo que marca la diferencia entre descubrir el incidente usted mismo en unas horas y enterarse por un cliente o por un aviso de Google tres semanas después. El coste de un hackeo no es proporcional a su gravedad técnica: es proporcional al tiempo que ha pasado inadvertido.
Los cuatro errores que más cuestan
- Borrarlo todo y empezar de cero sin haber entendido la entrada. Pierde la información y el fallo sigue ahí.
- Restaurar una copia y volver a publicar de inmediato. El fallo se restaura con el resto.
- Cambiar las contraseñas sin invalidar las sesiones. El atacante sigue conectado.
- Limpiar solo lo que se ve. Las redirecciones visibles son el síntoma; la puerta trasera es la enfermedad.
FAQ
1. ¿Cuánto se tarda en limpiar un WordPress hackeado? De dos a cuatro horas en un caso sencillo con una copia sana. Un día o más sin copia, o si la infección es antigua y se ha extendido a la base de datos. La parte más larga casi nunca es la limpieza: es encontrar la puerta de entrada.
2. ¿Puedo simplemente reinstalar WordPress encima?
Eso sustituye los archivos del núcleo, lo cual ayuda, pero no toca ni las extensiones, ni las plantillas, ni la base de datos, ni los archivos depositados en uploads, que es donde se esconden la mayoría de las puertas traseras. Es un paso, no una solución.
3. Mi proveedor dice que es culpa mía. ¿Es cierto? En alojamiento compartido, el origen también puede ser un sitio vecino o un fallo del servidor. Dicho esto, en la gran mayoría de los casos observados la entrada se produce por un componente obsoleto o una contraseña débil, es decir, por algo que está en su mano. Pida los registros de acceso: zanjan la cuestión mejor que la discusión.
4. ¿Debo avisar a mis visitantes? Si han podido quedar expuestos datos personales, la pregunta no es solo comercial sino normativa: véase el paso 10. Fuera de ese caso, la transparencia casi siempre sale más barata que el silencio descubierto después.
5. ¿Cómo sé que se ha acabado de verdad? Tres señales: los archivos del núcleo vuelven a coincidir con las huellas oficiales, no queda ninguna tarea programada desconocida, y no reaparece nada al cabo de varios días. La tercera es la que más cuenta: una reinfección suele producirse en la misma semana.
6. ¿Puede volver a pasar? Sí, si no se ha tratado la causa. No, en la práctica, si ha hecho el paso 8 y ha puesto doble autenticación, protección de acceso y vigilancia de integridad. Los ataques automatizados buscan blancos fáciles; siguen su camino.
Para profundizar en la prevención en vez de la reparación, lea nuestra guía para proteger WordPress frente a los ataques automatizados.