Trobar PHP dins de wp-content/uploads requereix investigació immediata perquè uploads normalment ha de contenir mitjans, no codi executable. Pot ser un payload maliciós, un fitxer deixat per una altra infecció o, molt menys habitualment, codi propi desat en un lloc inadequat.
Contén l’execució abans d’esborrar l’evidència
Impedeix l’execució pública del fitxer o directori sospitós i conserva’n còpia, hash, propietari i timestamps. Registra peticions que hi hagin arribat.
Segueix la via que ha permès escriure PHP a uploads
- Revisa handlers de pujada vulnerables i plugins modificats recentment.
- Comprova propietat de fitxers i usuari PHP/web.
- Creua l’hora de creació amb access logs i activitat administrativa.
- Busca referències des de tema, plugins, cron i opcions de base de dades.
Un únic PHP pot indicar una persistència més àmplia
Si forma part d’una infecció al tema, compara malware WP-VCD. Si també canvien fitxers de core o arrel, utilitza el triatge de canvis d’integritat per delimitar l’abast.
Repara la via d’escriptura, no només la carpeta uploads
- Elimina els fitxers maliciosos confirmats després de conservar evidència.
- Actualitza o substitueix el component que permetia l’escriptura.
- Reinstal·la codi afectat des de fonts fiables.
- Rota credencials capaces de pujar o modificar codi.
- Bloqueja execució PHP als directoris multimèdia quan sigui compatible.
No converteixis tot el lloc en read-only com a solució permanent
WordPress necessita zones escrivibles controlades; l’objectiu és mínim privilegi.
Verificació
No ha de reaparèixer cap executable a uploads després de trànsit, cron o reinicis normals, i la pujada legítima de mitjans ha de continuar funcionant.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
Elimina un shell no revela com va arribar o si un altre carregador pot recrear- lo. Les marques de temps, la propietat i l’accés als registres i fitxers relacionats connecten la càrrega útil a un punt d’entrada.
- Enumeix cada connector executa i extensió doble sospitosa sota les càrregues.
- Registre de fashes, data i hores, propietari i rutes abans de la quarantena.
- Coincideix els temps de creació amb l’accés, càrrega i autenticació registres.
- Cerca referències als fitxers cron, opcions, temes, plugins i regles del servidor.
Què ha de quedar verificat
- No queden fitxers d’execució en els directoris de suports d’escriptura.
- El servidor rebutja els intents d’execució sota càrrega.
- El monitoratge no mostra recreació i la ruta d'escriptura original està tancada.
Fonts tècniques oficials
Continua el diagnòstic
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.
N'hi ha prou amb eliminar el fitxer PHP maliciós una vegada que el trobi en càrregues?+
No. Eliminar el fitxer elimina la càrrega immediata però no revela com va arribar allà o si un carregador separat pot simplement recrear-lo. Les marques de temps, propietat, registres d’accés i fitxers relacionats han de ser rastrejats fins al punt d’entrada real abans que l’incident pugui ser considerat tancat.
Heu d’obrir el fitxer PHP sospitós en un navegador per veure què fa?+
No, això és explícitament insegur. Un shell web pot executar la lògica de l’atacant en el moment en què se sol·licita, de manera que s'ha d’analitzar com una còpia offline preservada en lloc d’activada en viu, sota la suposició que qualsevol petició a la mateixa podria executar codi maliciós.
Per què malware segueix apareixent en wp-contentent/uploads específicament, en comptes de en carpetes plugin o theme?+
El directori de càrregues normalment es refereix només a mitjans, però és escrit per WordPress i sovint sobrevisqui a plugin complet o reemplaçament de nucli, el que el converteix en un objectiu atractiu per als atacants que desitgen una càrrega útil que persisteix a través de la neteja.
Si només un lloc està afectat, s'haurien de comprovar també altres llocs en el mateix servidor?+
Sí. Quan diversos llocs comparteixen el mateix compte hosting o usuari del sistema, un punt final de càrrega vulnerable o credencials robades en un lloc es poden usar per escriure fitxers en d’altres, de manera que els llocs veïns i comptes que comparteixen aquest usuari del sistema també han de ser escanejats.