In breve: il virtual patching per PHP copre il tempo fino all'installazione dell'aggiornamento vero e proprio. A questo scopo combiniamo le regole di una Web Application Firewall con le misure provvisorie pubblicate da php.net su PHP2Shell e definiamo subito il percorso verso la patch regolare. Non offre una protezione completa, ma riduce il rischio nel periodo transitorio.
Quando il virtual patching per PHP è sensato
Per PHP2Shell il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda l'aggiornamento immediato e, se non è possibile, di scollegare temporaneamente dalla rete i web server. Per molte imprese nessuna delle due cose è fattibile subito: uno shop deve restare raggiungibile, uno sviluppo proprio richiede un test prima dell'aggiornamento, oppure il server gira con PHP 8.1 o precedente, per cui non esistono più aggiornamenti ufficiali.
In questi casi il virtual patching è un ponte. Non sostituisce la decisione se non sarebbe più appropriata la messa offline. Questa valutazione spetta a Lei, noi forniamo l'inquadramento tecnico.
Perché una WAF da sola non basta
Cloudflare ha segnalato tentativi di attacco osservati e ha distribuito regole di protezione, ma avverte che le regole basate sui soli dati della richiesta non bastano. Il motivo sta nella natura delle vulnerabilità. Con CVE-2026-109618 una condizione di out-of-memory può interrompere PHP mentre i dati della richiesta sono inizializzati solo in parte. Con CVE-2026-109619 uno stato interno può persistere dopo la liberazione della memoria ed essere usato da una richiesta successiva nello stesso worker. Errori di questo tipo dipendono dallo stato del server, non solo dal contenuto di una singola richiesta.
Per questo puntiamo su più livelli: regole WAF davanti al server, misure provvisorie in PHP stesso e un'osservazione rafforzata del server. Ogni livello ne ferma una parte, nessuno basta da solo. Insieme Le danno il tempo per installare l'aggiornamento in modo ordinato.
Le misure provvisorie secondo php.net
php.net indica diverse impostazioni che riducono il rischio, esplicitamente senza protezione completa. È importante che le applicazioni non possano sovrascrivere questi valori. Un esempio per un pool PHP-FPM con upload:
; Misure provvisorie PHP2Shell (nessuna protezione completa), poi riavviare tutti i worker
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Senza upload php.net raccomanda post_max_size = 8M. Poiché memory_limit viene tolto, serve un limite di memoria a livello di container o cgroup, non tramite RLIMIT_AS o RLIMIT_DATA. L'impostazione session.upload_progress.enabled=0 va in php.ini, nel pool FPM o nella configurazione del server, non in ini_set() o .user.ini. È al tempo stesso il rimedio per l'avviso su CVE-2026-115560. Tutte le misure in sintesi si trovano alla pagina Misure immediate se non può ancora applicare la patch.
Le misure provvisorie hanno effetto solo dopo un riavvio di tutti i worker PHP. E proteggono soltanto da attacchi futuri: se qualcuno fosse entrato prima, non lo chiariscono.
Quando la messa offline è la scelta migliore
Il virtual patching non è in ogni situazione la risposta giusta. In alcune configurazioni consigliamo di seguire il BSI e di scollegare temporaneamente il web server dalla rete finché non è stata applicata la patch:
- il server gira con Apache e mod_php, dove il team PHP classifica il rischio come il più alto e un exploit è stato dimostrato prima ancora che venga eseguito il codice dell'applicazione
- sul server si trovano dati particolarmente meritevoli di protezione, ad esempio dati sanitari, di clienti di studi professionali o di pagamento
- non c'è modo di impostare in modo stabile le misure provvisorie nella configurazione del server, ad esempio con determinati pacchetti di hosting condiviso
- ci sono già indizi che il server sia stato attaccato
Una messa offline temporanea non significa che il Suo sito web sia stato hackerato. Alcuni fornitori hanno messo offline dei siti web per precauzione. Una breve e sobria pagina informativa per i visitatori è allora di solito la soluzione migliore rispetto a un'interruzione non spiegata.
Come aiuta concretamente PHP SOS?
- Verificare la situazione: rileviamo versioni di PHP, modalità di esecuzione e livelli di protezione esistenti come CDN, WAF o reverse proxy. Con mod_php segnaliamo il rischio più elevato che il team PHP vede in quel caso.
- Costruire i livelli: attiviamo o integriamo regole WAF, impostiamo in modo stabile le misure provvisorie nella configurazione del server e limitiamo la memoria tramite container o cgroup. Per le configurazioni Nginx ci orientiamo alla pagina Mettere in sicurezza Nginx con PHP-FPM.
- Riavvio e test: tutti i processi PHP vengono riavviati, poi verifichiamo upload, moduli, login e cassa.
- Osservare: nel periodo transitorio prestiamo particolare attenzione a crash dei worker, picchi di memoria e processi insoliti.
- Pianificare la patch: stabiliamo quando e come arriverà l'aggiornamento regolare e lo attuiamo con il servizio di patch PHP.
Che cosa riceve, che cosa ci serve e che cosa non promettiamo
Riceve una documentazione di tutte le regole e impostazioni applicate, con motivazione, i risultati dei test e un piano di scadenze e interventi per la patch vera e propria. Da Lei ci servono accesso al server o al pannello, accesso a CDN o WAF, se presenti, un referente tecnico e indicazioni sulle funzioni di upload delle Sue applicazioni.
Non promettiamo che il virtual patching impedisca un attacco. Riduce il rischio per un tempo limitato. Con PHP 8.1 e precedenti non è una condizione permanente; qui nel piano rientra la migrazione a una versione supportata.
Domande frequenti
Che cos'è il virtual patching?
Virtual patching significa schermare una vulnerabilità nota davanti all'applicazione, invece di modificare il codice stesso. Di solito avviene tramite una Web Application Firewall o modifiche di configurazione. È una soluzione ponte, non un sostituto dell'aggiornamento.
La WAF del mio fornitore di CDN basta contro PHP2Shell?
Da sola, di norma no. Cloudflare ha distribuito regole di protezione, ma avverte essa stessa che le regole basate sui soli dati della richiesta non bastano. La WAF è un livello aggiuntivo accanto a misure provvisorie e patch.
Per quanto tempo posso fare affidamento sul virtual patching?
Il meno possibile. Deve coprire il tempo fino all'aggiornamento regolare, ad esempio finché si libera una finestra di manutenzione o un'applicazione è stata testata. Con PHP 8.1 e precedenti serve anche un piano di migrazione.
Le misure provvisorie possono disturbare il mio sito web?
Sì, è possibile. Limiti di upload più bassi possono impedire il caricamento di file grandi, e la disattivazione di session upload progress riguarda gli indicatori di avanzamento durante il caricamento. Dopo ogni modifica testiamo le funzioni più importanti.