In breve: per verificare i file core del CMS, confronti i file installati con un originale pulito della stessa versione: per WordPress tramite i checksum ufficiali, per altri sistemi tramite un download nuovo o una ricostruzione dal composer.lock. Ogni discrepanza è un incarico di verifica. Il confronto trova anche codice dannoso sconosciuto, ma copre solo i file per i quali esiste un originale.
Perché il confronto trova più di qualsiasi firma
Gli scanner di malware cercano schemi noti. Ciò che non conoscono lo trascurano. Il confronto con l'originale lavora al contrario: non chiede se un file abbia un aspetto sospetto, ma se corrisponda esattamente a ciò che il produttore ha consegnato. Ogni discrepanza emerge, che segua o no uno schema noto.
Dopo PHP2Shell questo è particolarmente prezioso. Per le vulnerabilità CVE-2026-109618 e CVE-2026-109619 non esistono Indicators of Compromise pubblicati e confermati. Gli scanner non possono quindi cercare in modo mirato tracce di PHP2Shell. Il confronto con l'originale trova invece ogni modifica al nucleo, indipendentemente da come sia nata. Perché gli scanner da soli non bastano lo spiega l'articolo Scanner di malware per siti web: cosa trovano e cosa no.
Il principio: stessa versione, fonte pulita
Un confronto vale quanto il suo riferimento. Devono essere soddisfatte tre condizioni:
- Esattamente la stessa versione: un confronto con una versione più recente mostra centinaia di differenze innocue. Stabilisca la versione installata dall'applicazione o dal
composer.lock. - Fonte ufficiale: l'originale proviene dal produttore, dal catalogo ufficiale dei pacchetti o dal Suo sistema di controllo di versione. Non da un vecchio backup del server interessato.
- Confronto su una copia: lavori su una copia messa al sicuro della directory web, in modo che timestamp e tracce restino conservati.
| Sistema | Riferimento | Strumento |
|---|---|---|
| Core di WordPress e plugin dalla directory | checksum di WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Progetti Composer (ad es. Shopware 6, Laravel, Symfony, Drupal, TYPO3 in modalità Composer) | ricostruzione dal composer.lock |
composer install in directory vuota, poi diff |
| CMS con pacchetto di download | pacchetto della stessa versione dal produttore | diff -rq |
| Progetti propri con Git | ultimo commit noto | git status, git diff |
| Pacchetti di sistema del server | database dei pacchetti della distribuzione | dpkg --verify, rpm -Va |
WordPress: più di verify-checksums
Come verificare core e plugin con WP-CLI è spiegato nella guida Trovare backdoor in WordPress. Vale la pena di aggiungere un complemento: secondo la documentazione di WP-CLI, l'opzione --include-root verifica tutti i file e le cartelle nella directory principale e avvisa delle voci che non appartengono a WordPress. Lì gli aggressori amano collocare file i cui nomi ricordano quelli dei file core.
# Core confrontato con i checksum ufficiali, inclusi i file estranei nella directory principale
wp core verify-checksums --include-root
Plugin e temi commerciali questa via non li copre. Per essi scarichi dal fornitore il pacchetto originale della stessa versione e confronti con diff.
Verificare i file core del CMS nei progetti Composer
Molte applicazioni PHP moderne sono costituite in gran parte da pacchetti che installa Composer, il gestore di pacchetti per PHP. Come funziona lo spiega la pagina Composer: il gestore di pacchetti per PHP. Il file composer.lock registra quali versioni esatte sono installate. Secondo la documentazione di Composer, composer install usa proprio queste versioni. Così si può ricostruire lo stato di consegna:
# Su un sistema pulito, non sul server interessato
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Elencare le differenze nella cartella vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Le opzioni --no-scripts e --no-plugins impediscono che durante la ricostruzione vengano eseguiti script dei pacchetti. Se la produzione è stata installata con --no-dev, usi questa opzione anche nella ricostruzione, altrimenti i pacchetti di sviluppo compaiono come differenza. Faccia attenzione a due tipi di risultato: file che differiscono e file che esistono solo sul server. Il secondo gruppo è spesso il più interessante. Come verificare inoltre i pacchetti installati rispetto a vulnerabilità note lo descrive la guida Verificare le dipendenze Composer alla ricerca di vulnerabilità.
Confrontare anche il sistema operativo
Se un aggressore aveva i privilegi di root, può aver sostituito anche programmi di sistema. I gestori di pacchetti hanno un confronto proprio:
# Debian, Ubuntu: file il cui contenuto differisce dal pacchetto
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: verificare tutti i pacchetti
sudo rpm -Va
Un 5 in terza posizione dell'output significa che il contenuto di un file è cambiato. Secondo il manuale di dpkg, il confronto del contenuto è lì attualmente l'unica verifica efficace. I file di configurazione modificati sono normali e contrassegnati con c. Un programma modificato in /usr/bin, invece, è un serio segnale d'allarme. Tenga presente: un aggressore con privilegi di root può manipolare anche il database dei pacchetti. In caso di sospetto di accesso root, una ricostruzione è più affidabile di qualsiasi confronto.
Un sistema di controllo di versione per il codice dell'applicazione rende i confronti futuri una questione di secondi. git status mostra allora ogni scostamento dallo stato approvato.
Valutare le discrepanze e conoscere i limiti
Non ogni discrepanza è un attacco. Alcune agenzie in passato modificavano direttamente i file core invece di usare estensioni. Anche pacchetti linguistici, fine riga dopo un trasferimento via FTP o correzioni applicate in seguito generano differenze. Decisivo è se qualcuno sa spiegare la modifica.
Esamini ogni discrepanza singolarmente e annoti il risultato: nota e documentata, spiegabile come innocua o poco chiara. I file poco chiari li apra solo come testo su una copia e li sostituisca con la fonte pulita. Per i file che esistono solo sul server la questione è più semplice: chi non li conosce dovrebbe metterli al sicuro e farli rimuovere dopo aver verificato il loro contenuto.
Upload, file di configurazione come wp-config.php o .env, personalizzazioni proprie e cache non hanno originale. Vanno verificati in modo mirato, così come il database, i cron job, gli account utente e le chiavi SSH. Un confronto pulito è quindi un tassello importante, ma non un'assoluzione per l'intero server.
Come aiuta PHP SOS in concreto?
- Stabiliamo le versioni installate e costruiamo un riferimento pulito da fonti ufficiali.
- Confrontiamo core, estensioni, pacchetti Composer e programmi di sistema e valutiamo ogni discrepanza.
- Verifichiamo in modo mirato le aree senza originale e sostituiamo i file modificati con una fonte pulita nell'ambito della rimozione del malware.
- Su richiesta configuriamo uno stato di versione rispetto al quale eseguire le verifiche future.
Domande frequenti
Come verifico se i file core di WordPress sono stati modificati?
Con WP-CLI e il comando wp core verify-checksums. Confronta i file con i checksum che WordPress.org pubblica per la versione installata. Con l'opzione --include-root, WP-CLI avvisa inoltre dei file nella directory principale che non appartengono a WordPress.
Che cosa faccio con un CMS privo di funzione di verifica integrata?
Scarica esattamente la stessa versione dalla fonte ufficiale del produttore e confronta le due directory con diff. Nei progetti Composer ricostruisce lo stato dal composer.lock in una directory vuota e confronta la cartella vendor.
Il confronto trova anche codice dannoso in plugin e temi?
Solo se per questi esiste un originale pulito, ad esempio dalla directory ufficiale o dal fornitore. Personalizzazioni proprie, upload e file di configurazione non hanno un originale e vanno verificati a parte.
Il confronto sostituisce uno scanner di malware?
Lo integra. Il confronto trova ogni modifica ai file noti, anche codice dannoso sconosciuto. Ma non dice nulla sui file senza originale, sul database, sui cron job o sugli accessi.