In breve: un file PHP nella cartella di upload è un serio segnale d'allarme, perché lì dovrebbero esserci solo immagini e documenti. Non apra mai il file nel browser, ma lo legga come testo, verifichi marcature temporali e proprietario e cerchi il nome del file nei log di accesso. Di solito sono innocui solo i segnaposto vuoti come un index.php senza contenuto; tutto il resto lo tratti come una possibile intrusione.
Perché PHP nella cartella di upload non ha nulla da fare
Le cartelle di upload servono per i contenuti caricati da visitatori o redattori: immagini, PDF, video. L'utente del server web può scrivervi, altrimenti gli upload non funzionano. Proprio questo rende queste cartelle attraenti per gli aggressori. Chi può scrivere file attraverso una vulnerabilità li deposita dove la scrittura è consentita.
I nuovi file PHP nelle cartelle di upload o di cache rientrano, secondo i rapporti di cui disponiamo, tra i segnali d'allarme generali dopo un'intrusione. Per PHP2Shell non esistono Indicators of Compromise confermati; un ritrovamento non dice quindi nulla su quale vulnerabilità abbia portato lì il file. Come si realizzano in modo sicuro le funzioni di upload lo descrive Implementare in modo sicuro gli upload di file in PHP.
Se un file simile possa causare danni lo decide la configurazione del server web. Se esegue file PHP nella cartella di upload, ogni file depositato lì diventa un possibile telecomando. Se l'esecuzione è bloccata, il file resta un corpo estraneo, ma per ora senza effetto. Molte installazioni non hanno mai configurato questo blocco.
Come arriva un file PHP nella cartella di upload?
Per la valutazione aiuta conoscere le vie possibili. Ognuna porta a domande successive diverse.
| Via | Contesto tipico | Domanda successiva |
|---|---|---|
| Modulo di upload non sicuro | verifica della sola estensione o del tipo comunicato dal browser | Quali moduli accettano file? |
| Vulnerabilità in un plugin o tema | vulnerabilità nota in un'estensione obsoleta | Quali estensioni sono obsolete? |
| Credenziali rubate | account di amministratore, FTP o hosting | Quali accessi ci sono stati di recente? |
| Esecuzione di codice tramite una vulnerabilità | ad esempio nell'interprete, come possibile con PHP2Shell | PHP era vulnerabile nel periodo? |
| Plugin legittimo | segnaposto, raramente file di cache | Il file appartiene al pacchetto originale? |
Più vie possono sommarsi. Un aggressore che esegue codice attraverso una vulnerabilità magari deposita il file solo per tornare più comodamente in seguito.
Elencare i luoghi di ritrovamento in modo sistematico
Prima di valutare un singolo file, si faccia un quadro generale. I comandi leggono soltanto. I percorsi sono esempi per WordPress; per altri sistemi adatti il percorso di upload.
# File simili a PHP nella cartella di upload con dimensione, proprietario, mtime e ctime
find /var/www/html/wp-content/uploads -type f \
\( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
-printf '%s Bytes %u m:%T+ c:%C+ %p\n'
# Determinare il tipo di file in base al contenuto anziché all'estensione (le immagini con contenuto PHP spiccano)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Altri sistemi usano altre cartelle di scrittura, ad esempio fileadmin in TYPO3, images in Joomla o la cartella dei media sotto public in Shopware 6. Si aggiungono le directory di cache e temporanee dell'applicazione. Nelle installazioni multisito e con più siti su un server ci sono altrettante cartelle di upload; ciascuna va inclusa nella ricerca.
Sono sospetti anche i file .htaccess e .user.ini nella cartella di upload. Con essi si può riattivare l'esecuzione di PHP in quella cartella o modificare la configurazione.
File PHP nella cartella uploads: interpretare correttamente il ritrovamento
Non ogni risultato è ugualmente grave. L'inquadramento seguente aiuta nella prima valutazione. Non sostituisce un'indagine accurata.
| Riscontro | Primo inquadramento |
|---|---|
index.php con zero byte o solo un commento |
di solito segnaposto contro l'elencazione della directory, confrontare con il plugin |
| File PHP con contenuto in una cartella mensile | sospetto elevato |
Doppia estensione come bild.jpg.php o .php.png |
sospetto elevato, mimetizzazione tipica |
Immagine che secondo file contiene codice PHP |
sospetto elevato, può essere eseguita tramite inclusione |
.htaccess o .user.ini nella cartella di upload |
sospetto, verificare la configurazione |
| Il file appartiene all'utente del server web, ctime dopo il 17 ottobre | compatibile con un'intrusione attraverso il sito |
Legga i file sospetti solo come testo, ad esempio con head -c 2000 datei.php o less. Spiccano righe molto lunghe, stringhe codificate e nomi di funzione come eval o base64_decode. Da cosa riconoscere il codice offuscato lo mostra Riconoscere il codice PHP offuscato.
Il file è stato richiamato? Uno sguardo al log
La domanda più importante dopo il ritrovamento è: qualcuno ha usato il file? La risposta sta nei log di accesso del server web. Cerchi il nome del file, anche nei log archiviati.
# Richieste del file sospetto nei log correnti e compressi (nome come esempio)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null
# Solo richieste riuscite con indirizzo IP e momento
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Molte richieste POST riuscite da pochi indirizzi indicano un uso attivo come webshell. L'assenza di risultati non significa automaticamente cessato allarme, perché i log possono essere ruotati, cancellati o incompleti. Se il sito gira dietro una CDN o un proxy, altri log si trovano lì; nell'hosting condiviso l'hoster mette di solito i log di accesso a disposizione nell'area clienti. Faccia inoltre attenzione alle richieste ad altri file nuovi dagli stessi indirizzi, perché portano spesso ad altri componenti. Conservi i log a partire dal 20 ottobre. Come valutare a fondo i log lo spiega la guida Analizzare i log del server web dopo un attacco.
Se il log mostra richieste riuscite a un file PHP sconosciuto, parta dal presupposto di un'intrusione. Conservi file e log, limiti l'accesso al server e verifichi se possano essere coinvolti dati personali.
Dopo la valutazione: l'ordine corretto
- Conservare: copiare il file con somma di controllo e marcature temporali, conservare i log.
- Chiarire l'origine: verificare moduli di upload, plugin e il periodo precedente al ritrovamento.
- Cercare altri componenti: file aggiuntivi, cron job, nuovi account amministratore.
- Bloccare l'esecuzione: vietare PHP nella cartella di upload a livello di server web, come descritto nell'articolo Vietare l'esecuzione di PHP nelle cartelle di upload.
- Bonificare e cambiare gli accessi: solo allora rimuovere il file e rinnovare tutte le password.
Come aiuta concretamente PHP SOS?
- Valutare il ritrovamento: verifichiamo il file senza eseguirlo e lo inquadriamo.
- Chiarire l'uso: valutiamo i log e ricostruiamo chi abbia richiamato il file e quando.
- Bonificare per intero: con la rimozione del malware cerchiamo tutti i componenti, chiudiamo la causa e cambiamo gli accessi.
- Impedire la ripetizione: blocchiamo l'esecuzione di PHP nelle cartelle in scrittura e monitoriamo i nuovi file.
Domande frequenti
Ogni file PHP nella cartella di upload è pericoloso?
Non ogni file. Alcuni plugin depositano un index.php vuoto perché il contenuto della cartella non venga elencato. Tutto il resto, in particolare file con contenuto, nome insolito o doppia estensione, va trattato come caso sospetto.
Posso aprire nel browser il file sospetto?
No. Una richiesta tramite il sito esegue il codice. Legga il file solo come testo sul server o in una copia, ad esempio con less o head.
Come scopro se il file è stato utilizzato?
Cerchi il nome del file nei log di accesso del server web. Richieste con stato 200 e metodo POST mostrano che il file è stato richiamato. Gli indirizzi IP e i momenti associati aiutano nell'indagine successiva.
Basta cancellare il file e bloccare PHP nella cartella di upload?
Entrambe le cose sono necessarie, ma non sufficienti. Chiarisca inoltre come il file sia arrivato lì, cerchi altri componenti e cambi le credenziali. Altrimenti l'aggressore torna per la stessa via.