Server infettato dopo PHP2Shell? I comandi da terminale per scoprirlo subito

Dopo la scoperta di PHP2Shell (le vulnerabilità CVE-2026-109618 e CVE-2026-109619, che consentono l’esecuzione di codice da remoto senza autenticazione), aggiornare PHP è solo il primo passo. La patch corregge la falda per l’avvenire, ma non elimina eventuali backdoor o webshell già piazzate nel sistema.

Per capire le reali condizioni della tua macchina occorre un’ispezione manuale. Non esiste uno strumento magico che restituisca una risposta secca del tipo “sei al sicuro oppure no”. Le istruzioni che seguono servono a rintracciare le tracce tipiche di un’intrusione. Lavora con privilegi di root o via sudo e, quando possibile, fai uno snapshot del VPS prima di partire.

Definisci subito la cartella principale dei tuoi siti (adattando il percorso alla tua configurazione, come ad esempio /www/wwwroot se usi aaPanel):

Bash

WEBROOT=/var/www

1. Verificare la versione di PHP

Come prima cosa accertati che il sistema stia eseguendo uno dei rami corretti e aggiornati: PHP 8.5.12, 8.4.27, 8.3.36 oppure 8.2.35.

Bash

for v in /usr/local/lsws/lsphp*/bin/php; do echo "$v"; $v -v | head -n 1; done
php -v

2. Rintracciare i file PHP modificati di recente

Questo comando individua i file alterati negli ultimi 14 giorni, ordinandoli partendo dal più recente. Se tra i risultati compaiono elementi che non ricordi di aver toccato o aggiornato, serve un approfondimento immediato.

Bash

find $WEBROOT -type f -name "*.php" -mtime -14 \
  -not -path "*/cache/*" \
  -printf '%TY-%Tm-%Td %TH:%TM  %u  %p\n' | sort -r | head -100

3. Scovare script PHP in directory anomale

All’interno della cartella uploads di WordPress devono risiedere esclusivamente immagini o documenti, mai file di script eseguibili.

Bash

find $WEBROOT -path "*/wp-content/uploads/*" -type f \
  \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.php5" \)

Qualsiasi file restituito da questa ricerca rappresenta un segnale d’allarme concreto.

4. Cercare pattern di codice tipici delle webshell

Le webshell utilizzano spesso funzioni di sistema accoppiate a meccanismi di decodifica o variabili offuscate per nascondere il proprio operato.

Bash

grep -RInE --include=*.php \
  "(eval|assert|system|shell_exec|passthru|popen|proc_open)\s*\(\s*(base64_decode|gzinflate|str_rot13|\\\$_(GET|POST|REQUEST|COOKIE))" \
  $WEBROOT | head -50

Alcuni plugin del tutto legittimi potrebbero impiegare chiamate simili, dunque conviene valutare ogni riga nel suo contesto. Un file con nome generato casualmente e codice illeggibile richiede un controllo immediato.

5. Verificare l’integrità di WordPress tramite WP-CLI

Sfruttando WP-CLI è possibile mettere a confronto i file presenti sul server con gli originali depositati sui repository ufficiali.

Bash

cd /percorso/del/sito
wp core verify-checksums --allow-root
wp plugin verify-checksums --all --allow-root

Ogni elemento indicato come modificato o aggiunto arbitrariamente va esaminato con cura.

6. Analizzare i processi attivi e le connessioni di rete

Cerca processi anomali avviati dall’utente web, istanze di shell (come sh, bash, nc) o connessioni in uscita dirette verso IP sconosciuti.

Bash

ps aux --sort=-%cpu | head -15
ps -u www-data -o pid,etime,cmd
ss -tupan | grep ESTAB

Nota: sostituisci www-data con www se utilizzi ambienti come aaPanel, oppure con nobody se gestisci OpenLiteSpeed.

7. Controllare i meccanismi di persistenza

Gli attaccanti cercano quasi sempre di mantenere l’accesso creando task pianificati, nuovi utenti o chiavi SSH autorizzate.

Bash

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u $u 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.d /etc/cron.daily
systemctl list-timers --all
awk -F: '$3==0 {print $1}' /etc/passwd
find / -name authorized_keys -mtime -30 2>/dev/null
find /tmp /var/tmp /dev/shm -type f -mtime -14 -ls
last -n 20

Presta massima attenzione a cron job sconosciuti, account diversi da root con UID pari a 0, chiavi SSH inserite di recente o file eseguibili annidati nelle directory temporanee /tmp o /dev/shm.

8. Esaminare i log di sistema e del web server

La prima vulnerabilità si manifesta quando PHP esaurisce la memoria allocabile: la presenza di arresti anomali nel log degli errori è un buon punto di partenza.

Bash

grep -ci "allowed memory size" /usr/local/lsws/logs/error.log
journalctl -k | grep -i segfault

Subito dopo verifica quali indirizzi IP stanno inviando un numero elevato di richieste in formato POST verso i file PHP.

Bash

grep -E "POST .*\.php" /usr/local/lsws/logs/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Nota: adatta i percorsi dei file di log alla tua struttura (su aaPanel, ad esempio, si trovano di norma all’interno della cartella /www/wwwlogs/).

Un volume elevato di richieste POST concentrate su pochi file insoliti o all’interno della cartella uploads merita un’ispezione immediata.

9. Eseguire una scansione automatizzata

Strumenti dedicati alla ricerca di rootkit e malware aiutano a individuare anomalie sfuggite ai controlli manuali.

Bash

sudo apt update && sudo apt install -y rkhunter chkrootkit clamav
sudo rkhunter --update && sudo rkhunter --check --sk
sudo chkrootkit
sudo freshclam && sudo clamscan -ri $WEBROOT

Come intervenire se trovi tracce di infezione

L’esecuzione completa di questi passaggi richiede una ventina di minuti e restituisce un quadro chiaro sull’integrità dell’ambiente. Se il server risulta pulito, applica gli aggiornamenti di PHP, mantieni attivi i sistemi di backup e programma una nuova verifica a distanza di qualche giorno.