Si index.php torna a aparèixer infectat després de substituir-lo, el fitxer no és la causa arrel. Restaurar core és fàcil; una reinfecció indica que algun procés, compte o mecanisme de persistència encara pot tornar-lo a escriure.
Demostra quan i com canvia index.php
Parteix d’una còpia de core fiable, registra hash i data de modificació i espera el següent canvi. Creua l’hora amb peticions web, execució de cron, activitat de plugins, desplegaments i esdeveniments del servidor. El més important és identificar qui escriu el fitxer.
Separa corrupció de core i persistència activa
- Compara els fitxers de core amb la release exacta de WordPress.
- Revisa PHP modificat recentment fora de core, sobretot en rutes escrivibles.
- Inspecciona tasques programades, MU plugins i loaders de tema o plugin.
- Comprova si alguna automatització legítima de l’hosting o del desplegament modifica el fitxer.
Busca el component que el pot tornar a escriure
La persistència pot viure en un plugin compromès, un loader ocult, una tasca programada o un procés de servidor. Si també canvia .htaccess, utilitza el diagnòstic de .htaccess que es reescriu. Si els canvis coincideixen amb execucions programades, revisa tasques cron malicioses a WordPress.
Restaura des d’un baseline fiable només després de contenir
- Conserva el fitxer infectat i els logs rellevants.
- Aïlla o desactiva l’escriptor confirmat.
- Reinstal·la core, plugins o tema afectats des de paquets fiables.
- Rota credencials que encara puguin donar accés d’escriptura.
- Revisa propietat i rutes escrivibles abans de tornar al trànsit normal.
No substitueixis index.php periòdicament com a “solució”
Això pot amagar la recurrència mentre l’escriptor continua actiu i elimina timestamps útils per atribuir la reinfecció.
Criteri de sortida
El cas només es pot tancar quan el hash de core es manté estable amb trànsit, cron i reinicis normals, cap procés desconegut torna a escriure el fitxer i la via de persistència ha estat eliminada.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
Fresh data i hores i hashes separen la reinfecció real de la sortida cau. Propietat i auditoria registres ajuden a identificar web, SFTP o escriu a nivell de sistema.
- 1
Preserva cada versió infectada, hash, data i hora i propietari.
- 2
Fes un seguiment del fitxer per a la següent escriptura i correlacional amb el procés i accedeix a registres.
- 3
Cerca cron, mu-plugins, càrregues, configuració d'autoprepensió i llocs de germans.
- 4
Auditoria servidoring, SFTP i credencials de gestor emprades prop del temps d’escriptura.
Què ha de quedar verificat
- index.php segueix sent idèntic a través del trànsit, cron i reiniciar.
- Cap procés o compte desconegut pot escriure a l’arrel de la web.
- Els llocs germans i la configuració a nivell de servidor estan nets.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
És útil continuar substituint index.php amb una còpia neta mentre s'investiga?+
No, això s'ha desmarcat explícitament. Repetidament es substitueix el fitxer mentre el lloc roman en línia i activament s'escriu per restablir el símptoma sense tancar la ruta d’escriptura, de manera que és probable que el fitxer es torni a infectar abans que es trobi la causa real.
Per què index.php seria específicament el fitxer que es continua tornant a infectar?+
És petit i comunament monitorat, el que el converteix en un punt d’execució fiable per als atacants en comptes d’una coincidència. La modificació repetida d’aquest fitxer en particular és en si mateixa evidència que la neteja va ometre un carregador, una credencial compromesa, o una infecció relacionada en una altra part del compte.
Podria un lloc web completament diferent en el mateix servidor ser la font real de reinfecció?+
Sí. Quan diversos llocs comparteixen el mateix compte hosting o usuari del sistema, una aplicació veïna compromesa pot escriure a través de directoris i tornar a infectar index.php en un lloc que d’altra manera està net, de manera que els llocs germans han de ser revisats com a part de la investigació.
Quina és la diferència entre un carregador ocult i la persistència a nivell del servidor que causa això?+
Un carregador ocult és un altre fitxer PHP dins de la instal·lació WordPress que reescriu index.php en sol·licituds o a través de cron, mentre que la persistència a nivell de servidor usa mecanismes com auto_ prepend_ file o tasques programades del sistema que s'executen abans de que WordPress fins i tot s'executi.