Cuando una web WordPress ha sido hackeada, la primera hora la dedico a documentar. Primero aseguro las pruebas, después averiguo el vector del ataque y solo entonces elimino el malware, en una copia del sitio y lejos de producción. Los archivos borrados a ciegas borran las huellas del vector, y una copia antigua restaurada sin comprobar la fecha de la infección puede devolver también el código malicioso.
Esta página describe los síntomas de un WordPress hackeado, el orden de mi trabajo después de un incidente, los ataques a tiendas WooCommerce y a sitios en otros sistemas y las obligaciones del RGPD que empiezan a contar desde el momento de la detección. Si quieres hacer la limpieza por tu cuenta, las instrucciones completas con comandos están en la guía para limpiar una web WordPress hackeada.
WordPress hackeado: síntomas
Síntomas que suelen indicar un ataque y el primer movimiento que hago en cada caso.
- Qué ves: Google muestra un aviso junto a tu web o Search Console informa de un problema de seguridad
- Qué hagoReviso el informe Problemas de seguridad de Search Console y la lista de direcciones afectadas. Es el punto de partida del diagnóstico y de la solicitud de revisión posterior.
- Qué ves: En Search Console aparece un propietario que no has añadido
- Qué hagoLo anoto como prueba y le quito el acceso. Revisar los propietarios de Search Console es uno de los primeros pasos después de detectar un ataque.
- Qué ves: En la lista de usuarios hay una cuenta de administrador desconocida
- Qué hagoReviso todas las cuentas de administrador y las tareas cron. Las cuentas que nadie creó las elimino después de guardar sus datos como prueba.
- Qué ves: Los archivos del núcleo no coinciden con los originales
- Qué hagoEjecuto wp core verify-checksums y comparo los archivos de plugins y temas con las versiones de las fuentes oficiales.
- Qué ves: La web redirige a los visitantes a direcciones extrañas o reparte código malicioso
- Qué hagoActivo el modo mantenimiento para que la web no infecte a los visitantes y hago una copia de archivos y base de datos como prueba.
- Qué ves: Clientes de la tienda avisan de un comportamiento raro en la página de pedido o de pago
- Qué hagoLo trato como una posible violación de datos personales. Aseguro las pruebas, anoto la hora del aviso y te informo, porque desde ese momento corren los plazos del RGPD.
- Qué ves: La infección vuelve unos días después de la limpieza
- Qué hagoBusco el vector que no se cerró: una puerta trasera en la base de datos, una tarea cron, una cuenta antigua. Una limpieza sin cerrar el vector no aguanta.
La primera hora después del ataque: lo que puedes hacer tú
Antes de escribirme a mí o a cualquier otra persona, haz cinco cosas. No borres ningún archivo. Haz una copia de los archivos y de la base de datos, aunque esté infectada, porque es material de prueba. Anota la fecha y la hora en que te diste cuenta del ataque. Mira en Search Console si en la lista de propietarios hay alguien que no conoces. Si la web reparte malware o redirige a los visitantes, activa el modo mantenimiento.
Después cambia las contraseñas del panel de WordPress, de SFTP y de la base de datos. No restaures una copia de seguridad antigua hasta saber cuándo empezó la infección. Una copia de hace una semana no sirve si el código malicioso lleva un mes en la web.
Si necesitas orientación inmediata y todavía no tienes a nadie, la línea Tu Ayuda en Ciberseguridad de INCIBE atiende en el 017. INCIBE la describe como un servicio nacional, gratuito, confidencial y personalizado.
La limpieza va más rápido si recibo desde el principio acceso al panel del hosting, a los registros del servidor, a SFTP, a la base de datos y a Search Console. Si los accesos están repartidos entre varias personas o empresas, reúnelos en un solo sitio antes de empezar.
Eliminar malware de WordPress: orden de trabajo
Cada paso termina con algo que se puede comprobar: una copia, un informe, una lista de cambios.
Contrato de encargado del tratamiento antes del acceso
Antes de recibir acceso al sitio firmamos un contrato de encargado del tratamiento (art. 28 del RGPD). En una web infectada hay datos de tus clientes.
Primera hora: asegurar las pruebas
Copia de archivos y base de datos como prueba, hora de detección anotada, modo mantenimiento si la web reparte malware y revisión de los propietarios en Search Console. Desde la detección corren los plazos del RGPD.
Diagnóstico como fase aparte
El diagnóstico tiene su propio precio y un alcance cerrado. Su resultado es la causa, el alcance de la reparación y el coste, por escrito. La limpieza empieza cuando confirmas ese alcance.
Vector del ataque en una copia del sitio
Trabajo sobre una copia del sitio, lejos de producción. El vector lo averiguo con los registros del servidor, con wp core verify-checksums y comparando los archivos de plugins y temas con versiones limpias.
Limpieza de archivos y base de datos
Elimino el malware y las puertas traseras de los archivos y de la base de datos, reviso las cuentas de administrador y las tareas cron, y restauro el núcleo y los plugins desde fuentes limpias.
Contraseñas y accesos nuevos
Cambio las contraseñas del panel de WordPress, de SFTP y de la base de datos. Los datos de acceso antiguos los doy por conocidos por el atacante.
Un único despliegue reversible
La versión limpia la despliego en un solo paso que se puede deshacer. Añado protecciones contra el vector encontrado y describo por escrito la causa y la forma de prevenirla.
Solicitud de revisión en Google
Cuando la web está limpia, solicito la revisión en el informe Problemas de seguridad de Search Console.
Sobre el último paso no tengo control. Según la ayuda de Google, la revisión tarda de unos días a unas semanas, y cuando termina Google envía un correo. Por eso no prometo una fecha para que desaparezca el aviso de los resultados de búsqueda.
Cuánto cuesta eliminar malware de WordPress
El precio de la limpieza no lo doy por adelantado, porque depende de lo que encuentre el diagnóstico: si la infección afecta a unos pocos archivos o también a la base de datos y a las cuentas, si las copias de seguridad son anteriores a la infección y si el vector es un plugin que basta con actualizar. El diagnóstico es una fase cerrada con su propio precio. Su resultado es la causa, el alcance de la reparación y el coste, por escrito. La limpieza empieza cuando confirmas ese alcance.
Una web sin contrato de mantenimiento pasa por la reparación WordPress, donde el precio lo doy tras la descripción del incidente. Lo que cuesta un mantenimiento continuo que incluye el análisis de malware y copias diarias lo explico en la página de mantenimiento WordPress precio.
Tienda WooCommerce hackeada
Un ataque a una tienda se diferencia de uno a una web de empresa en que casi siempre afecta a datos personales. En la base de datos de una tienda hay cuentas de clientes, direcciones de envío, teléfonos e historial de pedidos. Por eso en una tienda doy por hecho desde la primera hora que puede haber una violación de datos personales y anoto en el acto la hora de detección, que te paso a ti como responsable del tratamiento.
El orden de trabajo es el mismo que en una web de empresa, pero el alcance de la revisión es más amplio. Además de archivos, base de datos, cuentas y tareas cron reviso los plugins de pago, de transporte y los conectores con otros sistemas, porque cada uno tiene sus propias claves API. Las claves que hayan podido filtrarse hay que cambiarlas también en el lado de la pasarela de pago (el panel de Redsys, por ejemplo), del ERP o del programa de facturación, no solo en WordPress. Para cambiarlas hace falta acceso a los paneles de esos servicios, así que normalmente lo hacemos juntos.
Después de la limpieza compruebo el recorrido carrito, datos, envío y pago, sin hacer un pedido real, antes de que la tienda vuelva a vender. La tienda en la que esa prueba tiene que hacerse de forma constante la llevo en el Store Reliability Plan. Si después del ataque el carrito o el pago no funcionan y hay que recuperar las ventas, el servicio adecuado es el sprint de rescate WooCommerce.
Escenario típico: tienda con cuentas de clientes y un plugin sin actualizar
Un caso típico de los que traen los propietarios de tiendas: la tienda lleva varios años abierta, tiene cuentas de clientes y una docena larga de plugins, algunos sin actualizar desde hace meses. Alguien ve una cuenta de administrador extraña o un comportamiento raro en la página de pedido. En una tienda así primero aseguro las pruebas y anoto la hora de detección, y después compruebo si se han podido leer datos de clientes y cuáles. Esa descripción te la paso a ti, porque eres tú quien decide si notificar la violación a la AEPD y cuándo.
Escenario típico: la web de empresa redirige a los visitantes desde el móvil
Otro escenario típico: el titular de una web de empresa se entera por un cliente de que la web, abierta desde el móvil, lleva a otro sitio, mientras que desde el ordenador se ve normal. Ese síntoma suele indicar código malicioso en los archivos o en la base de datos que solo actúa para ciertos visitantes. También aquí empiezo con la copia como prueba y el modo mantenimiento, y busco el vector en los registros del servidor y comparando los archivos con versiones limpias. Si la web tiene formulario de contacto, compruebo además si el código malicioso tuvo acceso a los mensajes, porque son datos personales.
Ataque a un sitio en Drupal, TYPO3, Laravel o Symfony
El mismo orden de trabajo (pruebas, vector, limpieza en una copia, accesos nuevos, un único despliegue reversible) vale para sistemas que no son WordPress. Cambian las herramientas: en Drupal y TYPO3 restauro el núcleo y los módulos desde fuentes limpias con Composer, y en una aplicación Laravel o Symfony comparo el código del servidor con el repositorio.
Una versión sin soporte de seguridad no recibe parches para las vulnerabilidades nuevas. Drupal 7 no tiene soporte de seguridad desde el 5 de enero de 2025, y Drupal 10 lo pierde el 9 de diciembre de 2026. El soporte gratuito de TYPO3 12.4 terminó el 30 de abril de 2026. Después de limpiar un sitio en una de esas versiones no basta con quitar el código malicioso: hace falta un plan de actualización o de migración a WordPress. Para Drupal 10 las opciones están en el artículo Drupal 10, fin de soporte.
Web hackeada y RGPD: 72 horas y la AEPD
Si con el ataque alguien pudo acceder a datos personales (cuentas de clientes, pedidos, mensajes de formularios), empiezan a correr los plazos del RGPD. El art. 33.1 del RGPD dice que el responsable notifica la violación a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas físicas. Si la notificación llega más tarde, tiene que ir acompañada de los motivos del retraso. Cuando el riesgo es alto, el art. 34.1 exige además comunicar la violación a los interesados sin dilación indebida.
En España la autoridad de control es la AEPD. Su página sobre comunicación de brechas de datos explica la obligación de notificarla a la autoridad de control competente, y el formulario de notificación está en la sede electrónica de la AEPD. Para decidir si hay que notificar, la AEPD ofrece la herramienta Asesora Brecha, y para valorar si hay que comunicarla a los afectados, Comunica-Brecha RGPD. El incidente de seguridad en sí lo puedes consultar con INCIBE en el 017.
Quién responde de qué ante una violación de datos
El reparto de papeles sale del RGPD y del contrato de encargado del tratamiento que firmamos antes de acceder al sitio.
Tú, como responsable del tratamiento
- Decides si hay que notificar la violación a la AEPD (art. 33 del RGPD)
- Decides si hay que comunicarla a los interesados (art. 34 del RGPD)
- Presentas la notificación a la AEPD y cuentas el plazo de 72 horas desde que tuviste constancia
- Llevas el contacto con los clientes cuyos datos pudieron filtrarse
Yo, como encargado del tratamiento
- Te informo de la violación sin dilación indebida desde que tengo constancia (art. 33.2 del RGPD)
- Te paso los datos que necesitas para la notificación: hora de detección, archivos y datos afectados, vector encontrado
- No notifico a la AEPD en tu nombre, salvo que el contrato lo diga
- Elimino las consecuencias del ataque y cierro el vector dentro del alcance del contrato
La responsabilidad de cada parte, también por las consecuencias del ataque, la fija el contrato. Por eso el contrato de encargado del tratamiento se firma antes del primer acceso al sitio y no el día del incidente. Para la notificación sirve lo que sale de mis primeros pasos: la hora de detección, el alcance de los archivos y las tablas afectadas y el vector encontrado. El informe completo con la causa te lo entrego por escrito.
Si tu empresa trabaja en un sector cubierto por NIS2 o DORA, las obligaciones de notificación pueden ir más allá del RGPD. La preparación de una infraestructura WordPress para esos requisitos la trato en la página de cumplimiento NIS2 y DORA.
Limpiar, restaurar o sustituir
La elección depende de cuándo empezó la infección y de dónde viene.
Tienes una copia de seguridad seguro anterior a la infección y el vector ya se conoce.
Restauro esa copia en una copia de trabajo, cierro el vector y solo entonces despliego. El contenido y los pedidos añadidos después de la fecha de la copia hay que trasladarlos aparte.
No sabes cuándo empezó la infección o todas las copias son posteriores a ella.
Limpio la web en una copia: archivos, base de datos, cuentas, tareas cron, núcleo y plugins desde fuentes limpias.
El origen es un tema o un plugin que ya nadie desarrolla.
Lo elimino o propongo un sustituto. Si el cambio exige código nuevo, recibe un presupuesto propio.
El sitio está en una versión del CMS sin soporte de seguridad.
La web no funciona después del ataque y no tienes contrato de mantenimiento.
Nada indica un ataque, pero quieres saber si la web está limpia.
Auditoría de seguridad: informe en 5 días laborables, ordenado por prioridades.
Cómo detectar un ataque antes que Google
El aviso en los resultados de Google es un síntoma tardío. Antes, el ataque deja rastro en los archivos y en la base de datos. En el mantenimiento comparo los archivos del núcleo, los plugins y los temas con las sumas de comprobación de las fuentes oficiales (wp checksum core, wp checksum plugin --all), así que un archivo modificado se ve en menos de un día. El análisis de malware busca patrones conocidos de código malicioso, y la revisión mensual de las cuentas de administrador detecta las que nadie creó.
La segunda fuente son las bases de datos de vulnerabilidades, entre ellas Patchstack y WPScan. Cuando aparece una vulnerabilidad en un plugin que tienes instalado, lo actualizo fuera del ciclo semanal. Así el vector se cierra antes de que alguien lo aproveche.
Arreglos de código después del ataque
Cuando el vector fue el código propio del sitio, por ejemplo un formulario en un plugin hecho para la empresa o una función del tema que no validaba los datos de entrada, lo corrijo como parte de la protección contra ese vector. El arreglo va al sistema de control de versiones, y el código lo reviso con PHP_CodeSniffer y las reglas de los WordPress Coding Standards, que incluyen también reglas de seguridad, y con el análisis estático de PHPStan. En sitios que no son WordPress sigo el estándar PSR-12. Antes de desplegar reviso el cambio una vez más, por separado del momento de escribirlo. Si el arreglo exige rehacer una parte mayor del código, lo describo y lo presupuesto aparte.
Qué recibes después de la limpieza
Después de la limpieza recibes una descripción por escrito: cómo se produjo el ataque, qué se cambió en los archivos y en la base de datos, qué accesos se renovaron y qué protecciones añadí contra el vector encontrado. Esa descripción te sirve para la notificación a la AEPD, si la presentas, y para hablar con el hosting. La versión limpia queda desplegada en un solo paso que se puede deshacer, y la copia de la versión infectada se guarda como prueba.
Si quieres que después de la limpieza alguien vigile la web de forma continua, pasa al mantenimiento con la cuota mensual normal.
Lo que no prometo después de un ataque
No garantizo que la web no vuelva a ser hackeada nunca. La limpieza elimina el código malicioso y cierra el vector que se ha podido averiguar, pero en los plugins aparecen vulnerabilidades nuevas sin parar. Tampoco garantizo un plazo de reparación: depende del alcance de la infección, del acceso al hosting y de si las copias de seguridad son anteriores a la infección. No prometo una fecha para que Google retire el aviso, porque la revisión la hace Google.
Lo que sí prometo es el orden de trabajo descrito arriba, el resultado del diagnóstico por escrito antes de la limpieza y un informe con la causa y la forma de prevenirla después.
Cómo reduce el mantenimiento el riesgo de otro ataque
Dentro del servicio de mantenimiento WordPress hago copias de seguridad cada día y las guardo al menos 30 días, analizo los archivos en busca de malware y controlo su integridad, y una vez al mes reviso las cuentas de administrador. La monitorización comprueba la disponibilidad del sitio cada 1 a 5 minutos y me envía una alerta cuando deja de responder. Cuando el análisis detecta algo, aíslo los elementos infectados, restauro una versión limpia desde la copia, añado protecciones contra el vector y describo el incidente en el informe mensual.
Treinta días de copias cuentan cuando el ataque se detecta con retraso. Si la infección tiene dos semanas, en el historial de copias sigue habiendo una versión anterior a ella. Aun así compruebo la fecha de la infección antes de restaurar nada.
Un plugin sin actualizar con una vulnerabilidad publicada es un vector de ataque abierto. Lo que protege de él es un ciclo regular de actualizaciones, que describo en la página de actualizaciones WordPress. Lo que cuesta un mantenimiento que incluye el análisis y las copias está en la página de mantenimiento WordPress precio.
Siguiente paso si la web está infectada ahora: no borres nada, haz una copia de los archivos y la base de datos, anota la hora de detección y escríbeme con la dirección de la web y una descripción de los síntomas.
