Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Confirmar Contener Incidente

WordPress envía spam desde la cuenta de hosting

Contén el spam preservando logs, identificando script o cuenta, eliminando persistencia y reparando reputación.

El correo saliente inesperado puede venir de un formulario abusado, credencial SMTP robada, PHP inyectado u otra web del mismo hosting. Bloquear todo el correo detiene el síntoma, pero no identifica el origen ni protege el acceso.

Contén el abuso, conserva cola/logs y separa los mensajes transaccionales legítimos.

Detén el daño

Pide al host/proveedor restringir el envío de la cuenta, script o credencial afectada. Mantén correo esencial mediante un proveedor separado solo cuando su origen sea confiable.

No aumentes límites ni liberes la cola mientras sigue el spam. Ofrece contacto alternativo si las notificaciones de formularios no son fiables. Registra hora de contención y dominios.

Preserva evidencia de correo

Guarda cola, delivery logs, eventos del proveedor y volumen por remitente/script/hora. Registra IDs representativos, Return-Path y rutas sin copiar cuerpos innecesarios.

No reenvíes muestras desde el servidor comprometido. Protege logs porque incluyen destinatarios y autenticación. Anota si el host atribuye el envío a PHP, login SMTP o buzón.

Conserva una muestra mínima de cabeceras con queue ID, hora y autenticación, redactando receptores. Compara el ritmo de creación con peticiones web y cron. Si la cola sigue creciendo después de bloquear formularios, el origen puede ser tarea, script persistente o credencial externa.

Separa formulario de malware

Compara spam con entradas guardadas y peticiones web. Si un formulario legítimo confirma a cualquier dirección introducida, bots pueden abusarlo.

Si sale de una ruta PHP desconocida, cron o credencial SMTP directa, trátalo como compromiso. Pueden coexistir varias causas. Añadir CAPTCHA no demuestra que el malware desapareció.

Para abuso de formulario, limita destinatarios, frecuencia y campos que pueden convertirse en cabeceras. Comprueba que no exista header injection y que el formulario no actúe como relay. Mantén la evidencia del request y mejora validación antes de reabrirlo.

Identifica script o cuenta

Usa headers/logs de mail, tracking PHP y eventos de autenticación para correlacionar. Revisa archivos recientes, PHP en uploads/caché, mu-plugins y tareas.

En abuso SMTP, examina sesiones, horas/IP y app passwords. No publiques datos ni atribuyas por IP sola. Conserva archivos sospechosos sin ejecutarlos.

Busca el primer mensaje anómalo, no solo los más recientes. Relaciona su hora con una subida de archivo, login de panel, instalación de plugin o creación de cron. El último script visible puede ser una copia creada por una persistencia anterior.

Comprueba todas las webs

Un usuario cPanel/Plesk comprometido puede modificar dominios hermanos. Inventaría document roots, cron, bases y credenciales compartidas.

Contén al nivel de cuenta si corresponde, no limpies repetidamente una instalación. Incluye dominios aparcados y staging abandonado. Separa webs y credenciales durante recuperación cuando sea posible.

Comprueba permisos entre document roots y propietario de cada proceso PHP. Si una web puede escribir en otra, corrige el aislamiento antes de declarar limpia la primera. Revisa también backups y archivos temporales accesibles desde la web.

Elimina persistencia y cierra entrada

Sustituye core/plugins/temas, valida código, revisa base/usuarios y elimina tareas maliciosas. Actualiza o retira el componente vulnerable.

Rota hosting, SSH/SFTP, WordPress, base, SMTP y email principal desde equipo limpio. Revoca keys y activa MFA. No restaures un backup sin evaluar fecha/vector.

Revisa DNS por includes SPF, selectores DKIM, MX y forwards extraños. Una cuenta DNS/buzón robada puede autorizar abuso tras reemplazar WordPress. Conserva registros y auditoría antes de corregir.

Repara reputación

Configura proveedor transaccional verificado, SPF/DKIM/DMARC alineados y From controlado. Procesa rebotes y suprime inválidos.

Solicita revisión de blocklist/proveedor solo cuando cese el spam y se corrija la causa. Libera correo legítimo antiguo gradualmente y sin duplicar. Documenta volumen esperado y umbrales.

Separa reputación del dominio y de la IP. En hosting compartido puede existir mala reputación ajena, pero eso no explica una cola propia con spam. Conserva respuestas SMTP y consulta listas mediante procesos autorizados, sin enviar nuevas campañas de prueba.

Verifica recuperación sostenida

Envía un formulario sintético y sigue un mensaje hasta Inbox. Monitoriza cola, volumen, archivos, cuentas privilegiadas y eventos durante varios días.

Prueba también rechazo, rate limit y una dirección inválida para confirmar que el sistema procesa rebotes sin reintentos infinitos. Establece alertas por subida repentina, no solo por alcanzar el límite del hosting.

Concilia leads/pedidos del periodo y retira rutas temporales. Solicita rescate urgente si no se identifica origen o hay varios dominios. Comparte recuentos y logs redactados, no credenciales, destinatarios completos o malware por email.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia