Qué importa primero: Un sitio WordPress puede generar spam a través de wp_mail, una forma vulnerable, un correo malicioso PHP, una cuenta comprometida SMTP o un script fuera de WordPress.
Qué indica realmente este síntoma
Volumen de correo, encabezados de mensajes, registros de cola y archivo fecha y horas identificar la ruta de envío. Cambiar la dirección desde no elimina un remitente malicioso.
Recopila pruebas antes de cambiar nada
- Pausa o limite el correo saliente mientras se preserva la cola y el proveedor logs.
- Recoger cabeceras de muestra, remitente de sobres, resultados de autenticación y fecha y horas.
- Busque en la web y el correo logs para el script original, la cuenta o la clave API.
- Inspecciona formularios, usuarios, cron, cargas y archivos PHP recientemente cambiados.
Causas más habituales
- Código de sitio comprometido: Un script puerta trasera o correo envía directamente.
- Forma pública abusada: Los bots explotan una forma abierta como relé o campo receptor.
- Credencial SMTP/API robada: El correo se origina del proveedor sin tocar WordPress.
- Compromiso compartido de servidoring: Otro sitio bajo la misma cuenta genera la cola.
Secuencia segura de diagnóstico y reparación
- Revocar o rotar las credenciales de correo e invalidar las claves expuestas.
- Eliminar scripts maliciosos y parchear el formulario o componente vulnerable.
- Añadir listas de permisos de destinatarios, nonce, límites de velocidad y controles de bot cuando proceda.
- Restaurar el envío gradualmente mientras se monitorean rebotes, supresiones y eventos del proveedor.
Cómo distinguir entre las causas probables
No trates Código de sitio comprometido y Forma pública abusada como causas equivalentes. Un script puerta trasera o correo envía directamente. En cambio, los bots explotan una forma abierta como relé o campo receptor. Para distinguirlas, usa estas dos comprobaciones: Pausa o limite el correo saliente mientras se preserva la cola y el proveedor logs; y recoger cabeceras de muestra, remitente de sobres, resultados de autenticación y fecha y horas. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Revocar o rotar las credenciales de correo e invalidar las claves expuestas— o si debes conservar el estado actual y ampliar la investigación.
En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No elimine la cola de correo antes de preservar muestras. Los encabezados y metadatos de envío son a menudo la ruta más rápida a la fuente.
Cómo verificar la reparación
- El volumen de salida vuelve a la línea de base esperada.
- Sólo las aplicaciones legítimas pueden autenticar y enviar.
- No queda ningún script spam, ruta de formulario abusada o credencial comprometida.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.