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

Errors & Diagnosis

WordPress envia correus de spam: aturar la cua i identificar-ne l’origen

Outbound spam pot provenir de codi compromès, formularis abusats, credencials robades de SMTP o scripts de nivell d’allotjament.

Què importa primer: Un lloc WordPress pot generar spam a través de wp_ correu electrònic, una forma vulnerable, un correu maliciós PHP, un compte compromès SMTP o un script fora de WordPress.

Què indica realment aquest símptoma

Volum de correu, capçaleres de missatges, registres de cua i fitxer data i hores identificar la ruta d’enviament. Canvia l’adreça des de no eliminar un remitent maliciós.

Recull proves abans de canviar res

  • Pausa o limiti el correu sortint mentre es preserva la cua i el proveïdor registres.
  • Recollir capçaleres de mostra, remitent de sobres, resultats d’autenticació i data i hores.
  • Cerca a la web i el correu registres per a l’script original, el compte o la clau API.
  • Inspecciona formularis, usuaris, cron, càrregues i fitxers PHP recentment canviats.

Causes més habituals

  • Codi de lloc compromès: Un script porta del darrere o correu envia directament.
  • Forma pública abusada: Els bots exploten una manera oberta com relé o camp receptor.
  • Credencial SMTP/API robada: El correu s’ origina del proveïdor sense tocar WordPress.
  • Compromís compartit del servidoring: Un altre lloc sota el mateix compte genera la cua.

Seqüència segura de diagnòstic i reparació

  1. Revocar o rotar les credencials de correu i invalidar les claus exposades.
  2. Elimina scripts maliciosos i pega el formulari o component vulnerable.
  3. Afegeix llistes de permisos de destinataris, nonce, límits de velocitat i controls de bot quan sigui procedent.
  4. Restaurar l’enviament gradualment mentre es monitoritzen rebots, supressions i esdeveniments del proveïdor.

Com distingir entre les causes probables

No tractis Codi de lloc compromès i Forma pública abusada com a causes equivalents. Un script porta posterior o correu envia directament. En canvi, els bots exploten una forma oberta com relé o camp receptor. Per distingir- les, usa aquestes dues comprovacions: Pausa o limiti el correu sortint mentre es preserva la cua i el proveïdor registres; i recollir capçaleres de mostra, remitent de sobres, resultats d’autenticació i data i hores. Amb aquestes dades podràs decidir si convé aplicar la primera acció controlada -Revocar o rotar les credencials de correu i invalidar les claus exposades- o si has de conservar l’estat actual i ampliar la investigació.

En una web compromesa, contenir i netejar són decisions diferents. Conserva el fitxer sospitós i els registres d’accés abans d’eliminar la persistència, i gira les credencials només després de tancar la via activa. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.

Què no has de fer

No eliminis la cua de correu abans de preservar mostres. Les capçaleres i metadades d’enviament són sovint la ruta més ràpida a la font.

Com verificar la reparació

  • El volum de sortida torna a la línia de base esperada.
  • Només les aplicacions legítimes poden autenticar i enviar.
  • No queda cap script spam, ruta de formulari abusada o credencial compromesa.

Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.

CRITERI D’INCIDENT WP REPAIR

Seqüència d’intervenció segura

Volum de correu, capçaleres de missatges, registres de cua i fitxer data i hores identificar la ruta d’enviament. Canvia l’adreça des de no eliminar un remitent maliciós.

WP RepairModel de diagnòstic
1Desencadenant2Càrrega3Persistència4Via d’entrada
Segueix la cadena fins a trobar el primer punt que deixa de comportar-se com hauria de fer-ho.
  1. Pausa o limiti el correu sortint mentre es preserva la cua i el proveïdor registres.
  2. Recollir capçaleres de mostra, remitent de sobres, resultats d’autenticació i data i hores.
  3. Cerca a la web i el correu registres per a l’script original, el compte o la clau API.
  4. Inspecciona formularis, usuaris, cron, càrregues i fitxers PHP recentment canviats.

Què ha de quedar verificat

  • El volum de sortida torna a la línia de base esperada.
  • Només les aplicacions legítimes poden autenticar i enviar.
  • No queda cap script spam, ruta de formulari abusada o credencial compromesa.

SOBRE ESTE SÍNTOMA

Preguntes freqüents d'aquesta guia.

Canviarà l’adreça del lloc per aturar els correus electrònics spam?+

No. Canvia l’adreça From no elimina cap remitent maliciós ni tanca la ruta que usa per enviar correu; només canvia una capçalera de missatges que encara estan generats per la mateixa font compromesa.

És segur eliminar la cua de correu immediat per aturar la inundació?+

No abans de preservar primer les mostres. Les capçaleres de missatges i les metadades de cua són sovint la forma més ràpida de rastrejar la ruta d’enviament fins al seu origen, de manera que eliminar la cua abans de capturar aquesta evidència pot fer que la causa arrel sigui molt més difícil d’identificar.

Podria el spam ser originari sense WordPress estar directament involucrat?+

Sí. Un compte robat de SMTP o credencial API es pot usar per enviar correu a través del proveïdor directament, sense cap sol·licitud que toqui el codi WordPress, per la qual cosa la ruta d’enviament no s'ha d’assumir per executar a través de wp_mail per omissió.

Com distingiria un formulari compromès a part del codi maliciós real en el servidor?+

Un formulari públic abusat mostra als bots explotant un camp obert similar a relé o un paràmetre receptor, mentre que el codi del lloc compromès implica un script porta del darrere o un correu postal que envia correu directament independentment de les presentacions del formulari. Compara les capçaleres de missatges, el remitent de sobres i els resultats d’autenticació amb els registres web i de correu identifica quin patró coincideix amb el tràfic.

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