Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Confirmar Contenir Incident

WordPress envia spam des del compte de hosting

Contén el spam preservant logs, identificant script o compte, eliminant persistència i reparant reputació.

Una cua plena de missatges desconeguts o un avís del proveïdor no demostra, per si sol, que WordPress tingui malware. L’origen pot ser un formulari abusat, credencials SMTP robades, un script PHP injectat o una altra web allotjada al mateix compte. La resposta correcta és aturar l’enviament, conservar les proves i atribuir cada missatge abans de netejar.

Contén l’enviament sense destruir evidències

Bloqueja temporalment la font concreta quan sigui possible: script, bústia, credencial SMTP o funció d’enviament del compte. Si la ruta transaccional de comandes és independent i està verificada, es pot mantenir amb límits estrictes; si comparteix credencials o no pots demostrar-ne la integritat, pausa-la també.

No buidis immediatament la cua. Conserva els identificadors, l’hora, el Return-Path, la ruta o usuari d’origen i el resultat del lliurament. No copiïs cossos ni llistes de destinataris a documents oberts. Compara el creixement de la cua amb peticions web, tasques programades i registres d’autenticació.

Diferencia abús de formulari i compromís

En l’abús d’un formulari, les sol·licituds acostumen a passar per una ruta legítima i el servidor envia una notificació prevista amb dades malicioses. En una infecció, un PHP desconegut pot generar milers de missatges, falsificar capçaleres o executar-se des d’una tasca programada.

Revisa si hi ha injecció de capçaleres, un relay indegudament obert, endpoints sense límit i plugins SMTP amb credencials exposades. Un CAPTCHA present no prova que el formulari sigui segur: pot estar mal configurat, ometre’s en una crida directa o haver estat superat.

Identifica el primer missatge anòmal i correlaciona’l amb una pujada de fitxer, un accés al panell, una actualització de plugin o una execució de cron. Aquesta línia temporal ajuda a separar causa, persistència i conseqüència.

Troba la font real

Al cPanel o Plesk, consulta el registre de correu i la cua sense dependre només del remitent visible. Cerca l’identificador del missatge i segueix-lo fins al procés, usuari o script que el va crear. Contrasta’l amb accessos web i errors PHP de la mateixa franja.

Inspecciona totes les webs del compte, no només el domini denunciat. Comprova arrels documentals, directoris temporals, còpies públiques, mu-plugins, tasques cron i fitxers PHP dins d’uploads. Revisa si els permisos permeten que una web escrigui en una altra.

Si l’enviament prové d’una bústia autenticada, examina accessos SMTP/IMAP, reenviaments i dispositius autoritzats. Si prové de PHP, registra la ruta exacta, hash, propietari, dates i procés pare abans d’aïllar el fitxer.

Elimina la persistència i tanca l’accés

Substitueix el nucli, plugins i temes per còpies verificades de la versió correcta. Avalua per separat uploads i desenvolupament propi; no restauris cegament una còpia que ja pot contenir la porta d’entrada. Revisa usuaris administradors, opcions carregades automàticament, tasques, contingut injectat i comptes de base de dades.

Rota credencials de hosting, SFTP/SSH, WordPress, base de dades, SMTP i bústies relacionades. Revoca tokens i sessions, activa MFA i canvia secrets en configuracions i còpies desplegades. Fes-ho després de controlar els accessos, perquè una porta posterior activa podria capturar les claus noves.

Revisa el domini i el correu

Verifica també DNS: MX, SPF, DKIM, DMARC si existeix, subdominis i reenviaments. Un canvi de DNS no neteja malware, però una delegació o un registre alterat pot mantenir el frau fora del servidor.

Recupera l’enviament i la reputació

No sol·licitis retirar bloquejos fins que la causa estigui corregida. Determina si la mala reputació afecta la IP compartida, el domini, un subdomini o una bústia. En hosting compartit, el proveïdor pot haver de gestionar la IP; canviar-la sense corregir l’origen només trasllada el problema.

Reobre amb una prova controlada del formulari i una transacció de baix risc. Confirma autenticació, retorns, límits, cua i lliurament. Monitoritza durant diversos dies els volums per script, autenticacions fallides, nous fitxers i execucions programades.

L’incident queda tancat quan la cua es manté normal, cada ruta d’enviament té propietari, no reapareixen indicadors i les credencials antigues ja no funcionen.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència