In breve: un workaround per la vulnerabilità di sicurezza PHP2Shell può ridurre il rischio, ma non sostituisce l'aggiornamento. php.net indica a tal fine limiti fissi di memoria e di upload, la disattivazione di session upload progress e, con PHP 8.5, fatal_error_backtraces=0. Se anche questo non è possibile a breve, il BSI raccomanda di scollegare temporaneamente dalla rete il web server.
Che cosa può fare un workaround e che cosa no
Le misure provvisorie di php.net servono a rendere più difficili le condizioni in cui le vulnerabilità CVE-2026-109618 e CVE-2026-109619 sono sfruttabili. Sono esplicitamente una protezione non completa. Le vulnerabilità sono corrette solo in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 oppure in un backport confermato dal Suo fornitore.
Le misure sono sensate quando l'aggiornamento non è possibile per un motivo concreto: una finestra di manutenzione è ancora da fissare, un'applicazione deve prima essere testata, oppure gestisce PHP 8.1 o precedente, per cui non esiste più un aggiornamento ufficiale. Sono allora un ponte, non un traguardo.
Pianifichi quindi insieme al workaround anche l'aggiornamento: chi lo attua, in quale finestra di manutenzione e chi verifica poi che tutti i worker siano stati riavviati? Una fase transitoria senza data di fine rischia di diventare una condizione permanente.
Opzione 1: scollegare temporaneamente il server dalla rete
Il BSI ha dichiarato il livello di allerta 3 (arancione) e raccomanda di scollegare temporaneamente dalla rete i web server interessati, se l'aggiornamento non è subito possibile. Alcuni fornitori lo hanno fatto per precauzione; ciò non significa che quei siti siano stati hackerati.
Per molte imprese l'indisponibilità dello shop o del portale è costosa. Può essere sensata una valutazione: accesso solo tramite VPN o indirizzi IP abilitati, una pagina di manutenzione statica al posto dell'applicazione PHP o la disattivazione di singoli siti web non necessari sul server. Quanto meno PHP è raggiungibile dall'esterno, tanto più piccola è la superficie di attacco.
È importante prendere la decisione in modo consapevole e annotarla: chi ha deciso, e quando, di lasciare il server online, e con quali misure di protezione? Questo aiuta in seguito nei confronti di assicuratore, protezione dei dati e direzione.
Le misure provvisorie di php.net
| Misura | Valore | Nota |
|---|---|---|
memory_limit |
-1, non sovrascrivibile |
impostare poi il limite di memoria tramite container o cgroup |
post_max_size |
8M senza upload, 32M con upload |
upload_max_filesize inferiore |
| Limite di memoria | tramite container/cgroup | non tramite RLIMIT_AS o RLIMIT_DATA |
session.upload_progress.enabled |
0 |
in php.ini, pool o configurazione del server, non tramite ini_set() o .user.ini |
fatal_error_backtraces |
0 |
solo PHP 8.5 |
L'impostazione session.upload_progress.enabled=0 è al tempo stesso il rimedio per la vulnerabilità segnalata il 23 ottobre, CVE-2026-115560.
Impostare correttamente il workaround per la vulnerabilità PHP
Decisivo è il luogo. I valori devono essere impostati in modo che un'applicazione non possa sovrascriverli. Percorsi e nomi dei servizi variano a seconda della distribuzione; gli esempi presuppongono PHP 8.3.
PHP-FPM, nel pool (ad es. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache con mod_php, nella configurazione del server o nel VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Limite di memoria tramite cgroup, qui con systemd per il servizio FPM. Il valore lo adatti al Suo server:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Poi riavviare tutti i worker, altrimenti nulla di tutto ciò ha effetto: systemctl restart php8.3-fpm oppure, con mod_php, Apache. Come verificare che non giri più alcun vecchio processo è spiegato alla pagina Riavviare PHP-FPM e tutti i worker. L'hardening generale della configurazione è descritto alla pagina Configurare php.ini in modo sicuro.
Dopo il passaggio testi upload e moduli grandi. Un post_max_size troppo ridotto può bloccare ordini, moduli di candidatura o upload di contenuti multimediali. È un motivo per non rimandare a lungo l'aggiornamento.
Livelli di protezione aggiuntivi
Una Web Application Firewall o il virtual patching possono aiutare come livello ulteriore. Cloudflare ha distribuito regole di protezione, ma avverte essa stessa che le regole basate sui soli dati della richiesta non bastano. Una WAF è quindi un complemento, non un sostituto. Maggiori informazioni alla pagina WAF e virtual patching.
Salvi inoltre i log del server a partire dal 20 ottobre. Secondo i resoconti dei media, un primo tentativo di attacco è stato osservato già il 17 ottobre; i log sono la base se in seguito dovrà chiarire se prima della patch sia successo qualcosa.
Come aiuta concretamente PHP SOS?
- Chiarire la situazione: verifichiamo se un aggiornamento sia possibile a breve o se serva una fase transitoria, e discutiamo con Lei l'opzione di scollegare dalla rete alcune parti.
- Impostare le misure: inseriamo i valori di php.net nel punto giusto, impostiamo il limite cgroup e riavviamo tutti i worker.
- Testare il funzionamento: dopo il passaggio verifichiamo moduli, upload e processi d'ordine.
- Portare alla patch: con il servizio di patch PHP pianifichiamo l'aggiornamento e poi ritiriamo in modo controllato i valori transitori dove disturbano.
Domande frequenti
Il workaround protegge completamente da PHP2Shell?
No. php.net definisce esplicitamente le misure come transitorie e non come protezione completa. Riducono il rischio finché l'aggiornamento non è installato. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete i server senza patch.
Posso impostare i valori tramite .htaccess o .user.ini?
Per session.upload_progress.enabled php.net esclude esplicitamente ini_set() e .user.ini. Anche per memory_limit vale: il valore deve essere impostato in modo che l'applicazione non possa sovrascriverlo. Ci si riesce in php.ini, nel pool FPM con php_admin_value o nella configurazione del server Apache.
Una Web Application Firewall basta come workaround?
Come livello aggiuntivo può aiutare. Cloudflare ha distribuito regole di protezione, ma fa notare essa stessa che le regole basate sui soli dati della richiesta non bastano. Una WAF non sostituisce né l'aggiornamento né le misure provvisorie sul server.
Che cosa faccio se ho solo hosting condiviso?
In tal caso php.ini e riavvio sono in mano all'hoster. Chieda in modo concreto se l'aggiornamento sia stato installato o le misure provvisorie siano state impostate e se tutti i processi PHP siano stati riavviati.