In breve: per la sicurezza PHP di Drupal dopo PHP2Shell conta soprattutto il server: la vulnerabilità è in PHP, non in Drupal. Verifichi lo stato di PHP nel rapporto di stato e presso il gestore, riavvii tutti i processi PHP e controlli poi settings.php, la directory files e i permessi dei ruoli.
Drupal e PHP2Shell: la situazione
Drupal è spesso impiegato per siti più grandi, portali ed enti pubblici, con frequenza con molti redattori e interfacce. Le vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso da remoto senza autenticazione. Quanto Drupal stesso sia ben curato è irrilevante al riguardo.
Drupal ha un proprio team di sicurezza che pubblica avvisi su core e moduli. PHP2Shell non ne fa parte, perché non è una vulnerabilità di Drupal. Chi segue solo gli avvisi di Drupal può quindi aver trascurato la segnalazione.
Nei progetti Drupal più grandi la responsabilità si distribuisce spesso su più soggetti: un'agenzia cura il codice, un centro di calcolo gestisce i server, la redazione è interna. Chiarisca per iscritto chi applica l'aggiornamento di PHP, chi attiva il riavvio e chi verifica se prima sia successo qualcosa. Nelle configurazioni con più web server dietro un load balancer, ogni singolo server deve essere aggiornato e riavviato, altrimenti una parte delle richieste resta su un vecchio PHP.
Sicurezza PHP di Drupal: verificare versione e stato delle patch
In Rapporti > Rapporto di stato, Drupal mostra la versione di PHP con cui gira il sito, insieme agli avvisi sulla configurazione. Da riga di comando, drush status fornisce la versione del PHP CLI, con cui girano anche cronjob e deployment. Entrambi devono essere aggiornati.
Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Distribuzioni e hoster talvolta applicano le correzioni come backport; il numero resta allora lo stesso, e fa fede lo stato confermato dei pacchetti. Quali versioni di PHP supporta la Sua versione di Drupal, lo verifichi nei requisiti di sistema su drupal.org. Dopo l'aggiornamento fa parte del lavoro il riavvio, descritto in Riavviare PHP-FPM e tutti i worker.
Directory e file che contano
| Posizione | Contenuto | Punto da controllare |
|---|---|---|
sites/default/settings.php |
Database, hash salt, trusted_host_patterns |
Data di modifica, include aggiunti |
sites/default/files/ |
upload pubblici, immagini generate, CSS e JS | nessun file PHP, .htaccess presente |
| directory dei file privati | upload protetti, spesso fuori dalla document root | Diritti di accesso |
modules/contrib/, modules/custom/ |
Moduli di drupal.org e sviluppi su misura | moduli modificati o sconosciuti |
themes/ |
Temi con template Twig | JavaScript estraneo |
vendor/ |
Dipendenze di Composer | composer audit |
Drupal crea nella directory files un .htaccess che impedisce l'esecuzione di PHP. Con Apache funziona, con Nginx no. Lì serve una regola propria:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Controlli non invasivi con strumenti di base e Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Confronti lo stato del codice sul server con il Suo repository Git. Nei progetti Drupal con Composer è il modo più rapido per trovare file estranei o modificati, perché ogni scostamento deve essere spiegabile.
Ruoli, permessi e moduli come rischio
L'accesso si trova in /user/login, l'area di gestione in /admin. In Drupal sulla sicurezza non decidono solo gli account amministratore, ma i singoli permessi. Diritti come gestire moduli, utenti, permessi o formati di testo con HTML completo sono di fatto diritti di amministratore. Verifichi in Persone e Permessi quali ruoli li abbiano e chi appartenga a quei ruoli.
I moduli contrib ampliano molto Drupal, ma portano codice proprio. I moduli senza manutenzione attiva e i vecchi sviluppi su misura sono spesso il motivo per cui un aggiornamento di PHP viene rimandato. Maggiori informazioni sulle dipendenze si trovano in Verificare le vulnerabilità nelle dipendenze di Composer.
Che cosa offre un aggiornamento di Drupal e che cosa no
Un aggiornamento del core o di un modulo chiude errori in quel codice e può rendere possibili versioni di PHP più recenti. Non applica patch a PHP, non rimuove file estranei da sites/default/files, non reimposta i permessi e non elimina account creati di nascosto. Anche la cache può continuare a consegnare contenuti manipolati finché non viene svuotata. In caso di sospetto vanno rinnovati hash salt e accesso al database.
Nelle installazioni multisito più siti condividono lo stesso codice, ma hanno ciascuno un proprio settings.php e una propria directory files sotto sites/. Controlli allora ogni sito singolarmente. Un riscontro in un sito, a causa del codice condiviso, di solito riguarda anche tutti gli altri.
In che modo PHP SOS aiuta concretamente?
- Verifichiamo PHP web e CLI del Suo server Drupal e ci facciamo confermare patch e riavvio.
- Mettiamo al sicuro log e dati e confrontiamo lo stato del codice con il Suo repository o con i pacchetti originali.
- Controlliamo
settings.php, la directoryfiles, le regole del server, ruoli e permessi. - Su richiesta ci occupiamo della manutenzione continuativa nel contratto di manutenzione della sicurezza, così che gli aggiornamenti di PHP e di Drupal non tornino a divergere.
Domande frequenti
Un aggiornamento di sicurezza di Drupal aiuta contro PHP2Shell?
No. Gli aggiornamenti di Drupal chiudono errori nel core e nei moduli di Drupal. PHP2Shell è nel PHP del server e richiede un aggiornamento di PHP o un backport confermato, oltre al riavvio di tutti i processi PHP.
Dove mostra Drupal la versione di PHP?
Nel rapporto di stato, sotto Rapporti. Con Drush, drush status mostra la versione di PHP della riga di comando. Le due indicazioni possono differire, e da nessuna delle due si riconosce con certezza un backport.
Il .htaccess nella cartella files protegge anche con Nginx?
No. Il .htaccess creato da Drupal viene interpretato solo da Apache. Con Nginx serve una regola propria nella configurazione del server che blocchi i file PHP nella directory files.
Che cosa significa trusted_host_patterns?
L'impostazione in settings.php stabilisce con quali nomi host risponde Drupal. Protegge da attacchi tramite indicazioni host manipolate e va inserita in ogni installazione in produzione.