Los escáneres de archivos no encuentran nada, pero las páginas públicas todavía cargan un script desconocido. La inyección puede estar en el contenido de una entrada, un bloque HTML, un widget, un patrón reutilizable o los datos de un constructor. WordPress la sirve legítimamente desde la base de datos.
No ejecutes una búsqueda y sustitución global. Los constructores y ajustes pueden usar datos serializados o estructurados, y un código legítimo de analítica puede parecerse a la inyección.
Conserva la respuesta afectada y la base
Guarda el HTML como visitante sin sesión, las URL afectadas, el hostname del script y la hora. Exporta una copia coherente de la base y protégela porque puede contener usuarios, formularios y datos de clientes.
Registra si el script aparece en todas las páginas, una plantilla o unas pocas entradas. Un widget global de pie tiene un propietario distinto de un artículo alterado.
No pulses ni solicites el dominio del payload más allá de capturar la evidencia de red generada por tu propia página.
Localiza el origen en la base de datos
Busca un hostname, nombre de archivo o fragmento distintivo con una herramienta compatible con WordPress. Revisa entradas, metadatos, opciones, widgets, bloques reutilizables, navegación y tablas específicas del constructor.
Una consulta SQL de solo lectura puede ayudar sobre una copia, pero el prefijo y el formato varían. No pegues el código malicioso directamente en un comando donde las comillas puedan ejecutarlo o corromper la búsqueda.
Busca indicadores codificados y decodificados únicamente dentro de un entorno aislado.
Relaciona el registro con su propietario visible
Identifica ID, tipo de entrada, estado, idioma y editor. Para una opción, averigua qué plugin o tema controla la clave. En un constructor, encuentra la plantilla o sección global que la renderiza.
Consulta revisiones y logs de auditoría para establecer cuándo y quién modificó el valor. Una sesión administrativa robada puede haber usado el editor normal sin tocar archivos.
Conserva la revisión maliciosa como evidencia, pero mantenla inaccesible para los visitantes.
Elimina únicamente el payload confirmado
Usa el editor de WordPress o la interfaz admitida por el plugin propietario cuando sea posible. En contenido estructurado, elimina exactamente el widget o bloque comprometido y regenera su salida.
Si debes trabajar directamente en la base, hazlo primero en staging y utiliza las API de WordPress que preservan la serialización. Exporta la fila y registra los valores anterior y posterior con datos sensibles censurados.
Nunca apliques un REPLACE SQL general a wp_posts y wp_options: puede modificar texto legítimo y romper las longitudes serializadas.
Comprueba las copias generadas y en caché
El valor inyectado puede haberse compilado en CSS o JavaScript del constructor, un paquete de minificación, caché de página completa o una respuesta del CDN.
Después de limpiar la fuente en la base, regenera solo los recursos afectados y purga las URL concretas en la página y el CDN. Vacía la caché de opcode u objetos mediante controles admitidos cuando corresponda.
No purgues antes si necesitas conservar la respuesta almacenada como evidencia.
Averigua cómo cambió la base
Revisa administradores, contraseñas de aplicación, roles de editor, vulnerabilidades de plugins, SFTP, panel y acceso directo a base. Comprueba logs web y de auditoría alrededor de la revisión guardada.
Corrige endpoints de edición o API vulnerables, elimina usuarios desconocidos y rota las credenciales afectadas después de asegurar los dispositivos de administración.
Inspecciona tareas programadas y plugins de snippets capaces de reinsertar el script.
Verifica todas las rutas de renderizado
Busca el hostname anterior tanto en la base limpia como en el HTML público. Prueba escritorio y móvil, visitante sin sesión, idiomas, plantillas de correo y páginas WooCommerce que reutilicen bloques globales.
Monitoriza cambios del registro y acciones administrativas más allá del intervalo anterior de recurrencia. Confirma que los editores legítimos todavía pueden actualizar el contenido afectado sin reintroducir el código.
Cuándo conviene una limpieza especializada
Solicita ayuda cuando los datos del constructor estén serializados, el script aparezca globalmente o no puedas atribuir la modificación. Envía URL públicas y el hostname externo, no el volcado de la base.
Una limpieza completa elimina el payload almacenado, sus copias compiladas y la ruta de acceso que lo insertó.