Respuesta breve: tu web sirve código inyectado que envía a parte de las visitas a otro sitio. La redirección suele ser condicional —solo móvil, solo desde buscadores o una vez por visitante—, por eso a menudo no la reproduces desde tu propio ordenador.
Reproduce y registra el disparador primero
Antes de tocar nada, anota qué dispositivo, navegador, país y origen la reproducen, y a dónde te lleva. Pruébalo como visita de Google y en móvil. Esas condiciones localizan la carga y son la única forma de demostrar después que ha desaparecido. No abras repetidamente el destino desde un equipo con sesiones importantes iniciadas.
Busca en cada capa — los sitios exactos
- Base de datos: revisa
wp_optionsporsiteurlyhomemanipulados, y busca en todas las tablas<script>inyectado o el dominio del atacante. - Archivos: por SSH,
grep -RIlE 'eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|str_rot13\s*\(|assert\s*\(|create_function\s*\(' wp-content/saca a la luz código ofuscado. Revisaheader.php,footer.php,functions.phpy cualquier.phpdentro de/wp-content/uploads. - Reglas del servidor:
.htaccesssuele llevar redirecciones condicionales según user-agent u origen. - Código autocargado: un archivo soltado en
/wp-content/mu-pluginsse carga en cada petición y se oculta de la lista de plugins. - Tareas programadas: inspecciona el array de cron (
wp cron event list) por una tarea que reinyecta el código.
Por qué borrar una línea no es una limpieza
La redirección visible suele ser la última fase. Si queda una puerta trasera, o la credencial que usó el atacante sigue siendo válida, vuelve en horas. Una limpieza real compara archivos con copias limpias (reinstalar núcleo y plugins desde su origen), elimina la persistencia, cierra la vía de entrada y rota todas las credenciales: WordPress, base de datos, SFTP y hosting.
Verifica bajo el disparador original
Vuelve a probar con el dispositivo, el origen y la red exactos que la reproducían, con todas las cachés y el CDN vaciados: una redirección puede sobrevivir en una respuesta cacheada tras limpiar el origen. Después vigila varios días, porque la reinfección desde una puerta trasera que se pasó por alto suele volver de forma discreta.
CRITERIO DE INCIDENTE WP REPAIR
Reconstruye el incidente antes de corregirlo
Las redirecciones condicionales de spam son un incidente, no una sola línea mala. Reproducir el disparador, conservar evidencia y encontrar persistencia es necesario antes de verificar la limpieza.
- 1
Anota dispositivo, origen, país, cookies y destino que reproducen la redirección.
- 2
Busca en archivos, base de datos, reglas, mu-plugins y tareas programadas.
- 3
Compara núcleo, plugins y tema con paquetes limpios de origen.
- 4
Identifica el componente vulnerable o credencial que permitió el cambio.
Qué debe quedar verificado
- El disparador condicional original ya no redirige.
- Comparación de archivos y revisión de usuarios, cron y base no muestran persistencia.
- Las credenciales se rotan y la vía de entrada se parchea o elimina.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →SOBRE ESTE SÍNTOMA
Preguntas frecuentes de esta guía.
¿Por qué no puedo reproducir la redireccionamiento cuando pruebo mi propio sitio desde mi escritorio?+
Debido a que la redireccionamiento es generalmente condicional — activado sólo para los visitantes móviles, sólo para las personas que llegan de los referenciadores de búsqueda, o sólo una vez por visitante. Usted necesita probar como un visitante Google y en el móvil, teniendo en cuenta el dispositivo exacto, navegador, país y referenciador que lo reproduce, ya que esas condiciones son lo que localizar la carga útil.
¿Es seguro seguir haciendo clic en el destino spam para comprobar si todavía está sucediendo?+
Evite abrir repetidamente el destino desde una máquina que mantiene sesiones de inicio de sesión importantes, ya que no sabe lo que hace el sitio de destino. Grabe las condiciones de activación en su lugar y verifique desde un entorno de prueba limpio y desechable cuando sea posible.
Encontré y borré una línea sospechosa de código de redireccionamiento, ¿por qué volvió la redireccionamiento?+
Debido a que la redirección visible es generalmente sólo la última etapa de la infección. Si una backdoor permanece, o la credencial que el atacante utiliza sigue siendo válida, devuelve dentro de horas independientemente de que una eliminación. Una corrección real compara archivos contra copias limpias, elimina la persistencia, cierra el punto de entrada, y rota cada credencial.
¿Dónde debería mirar más allá de los archivos theme obvios si la redirección no está en encabezado.php o pie de página.php?+
Compruebe la tabla wp_options para ver si hay un siteurl manipulado o valor de inicio, cualquier archivo.php dentro de /wp-content/uploads, un archivo caído en /wp-content/mu-plugins (que se carga en cada solicitud y no aparece en la lista plugin),.htaccess para reglas basadas en el agente de usuario o referrer, y el array cron para una tarea que reinyecta el código.