Vulnerabilità PHP 2026: come verificare e correggere i servizi web a rischio

Interpretare correttamente il messaggio di allarme

L’affermazione secondo cui una vulnerabilità PHP potrebbe interessare „metà di Internet“ è un’esagerazione, ma non un dato quantificato. Non vi è alcuna prova che la metà di tutti i servizi Internet sia vulnerabile o sia già stata compromessa. Il rischio effettivo è comunque considerevole, poiché PHP viene utilizzato come ambiente di esecuzione in molti siti web, negozi online, API e interfacce di amministrazione.

Ciò che conta non è se un sito web utilizzi PHP, ma quale versione di PHP elabori le sue richieste web. Gli aggiornamenti di sicurezza del 21 ottobre 2026 riguardano, in linea di principio, le installazioni non aggiornate dei rami supportati, a condizione che gestiscano richieste tramite un servizio web. Un'istanza locale di PHP utilizzata per attività di sviluppo va quindi valutata in modo diverso rispetto a un portale clienti accessibile dall'esterno.

Il sito Visibilità su Internet L'urgenza è un fattore determinante. Un negozio accessibile al pubblico con moduli e funzioni di upload offre più potenziali punti di contatto rispetto a un servizio interno isolato. Tuttavia, nemmeno un servizio interno è automaticamente sicuro: accessi VPN, account compromessi o altri sistemi nella rete possono renderlo accessibile. La portata da sola non sostituisce quindi una valutazione tecnica dei rischi.

Altrettanto importanti sono la modalità di funzionamento e Portabiciclette. PHP può essere eseguito, ad esempio, tramite PHP-FPM, come modulo Apache, tramite php-cgi o integrato in un prodotto. Diversi domini sullo stesso server possono avere versioni e modalità di aggiornamento diverse. Dare un via libera generalizzato a tutti i siti web PHP sarebbe sbagliato tanto quanto supporre che ogni installazione sia immediatamente vulnerabile.

Cosa consentono tecnicamente le vulnerabilità di PHP

A Esecuzione di codice da remoto (RCE) significa che, in determinate condizioni, un malintenzionato può eseguire codice su un sistema remoto. Secondo la nota di sicurezza, per queste vulnerabilità PHP non è necessario effettuare prima l’accesso. Il codice verrebbe inizialmente eseguito con i privilegi del processo web, non automaticamente con diritti di amministratore illimitati. Le possibili conseguenze dipendono quindi in larga misura dai permessi dei file, dalle credenziali di accesso e dall’isolamento del server.

CVE-2026-109618 riguarda percorsi di errore in Carenza di memoria. Se PHP interrompe una richiesta a causa di una condizione di esaurimento della memoria, le strutture dati interne potrebbero rimanere incomplete. Se tali condizioni vengono riutilizzate durante la pulizia della richiesta, si può verificare un danneggiamento della memoria. La descrizione ufficiale cita in particolare le richieste multipart, i caricamenti di file e il consumo di memoria durante l’analisi di input annidati come contesti tecnici rilevanti.

CVE-2026-109619 riguarda invece uno stato interno legato a una richiesta, la cui memoria è già stata liberata. Se un worker riutilizzato elabora successivamente un’altra richiesta, PHP può accedere a questo stato obsoleto prima che abbia effetto la normale inizializzazione. La nota di sicurezza fa riferimento, tra l’altro, all’avanzamento del caricamento delle sessioni e ai percorsi di errore. Ciò descrive la classe di errore, non costituisce una guida allo sfruttamento.

• Possono essere interessate le richieste web tramite PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.
• Gli errori risiedono nel runtime di PHP, non principalmente in WordPress, Joomla, Shopware, nei temi o nei singoli plugin.
• I CMS e i framework influenzano le funzionalità disponibili, come il caricamento dei file, ma non sostituiscono un aggiornamento dell'interprete.

Perché non tutte le installazioni sono ugualmente a rischio

Il fatto che un servizio sia effettivamente a rischio dipende da diversi fattori. Tra questi, hanno la priorità un runtime web PHP non aggiornato e un servizio web accessibile. Seguono poi la modalità operativa, i processi riutilizzati, le funzioni per gli upload o i moduli complessi, nonché i diritti dell’account del processo web. Un servizio con ampi diritti di scrittura sui file web o con accesso ad altri servizi può avere conseguenze più gravi rispetto a un progetto rigorosamente isolato.

In Apache con mod_php Il progetto PHP sottolinea in particolare il rischio: un attacco documentato può essere sferrato già prima dell’esecuzione del codice effettivo dell’applicazione. Un CMS ben mantenuto non protegge quindi dalla vulnerabilità in fase di esecuzione. Ciò non significa che PHP-FPM, php-cgi, FrankenPHP o LiteSpeed siano considerati sicuri; anche questi devono essere controllati con priorità se non sono aggiornati con le patch.

Particolare attenzione va inoltre prestata ai prodotti con PHP incorporato. Tra questi possono figurare immagini di container, appliance, sistemi di gestione NAS o prodotti di rete la cui interfaccia utilizza PHP internamente. In questi casi, un comando eseguito sull’host spesso non mostra il runtime effettivamente in uso. Inoltre, l’aggiornamento del sistema operativo non risolve automaticamente la vulnerabilità di un componente PHP presente in un’immagine o in un prodotto del produttore.

Un firewall, un Web Application Firewall o limiti restrittivi di upload possono rendere più difficili le singole richieste e limitare la superficie di attacco. Tuttavia, non sostituiscono la correzione, poiché non risolvono la gestione errata della memoria e dello stato nell’interprete. Anche un CMS privo di errori dipende comunque da un ambiente di esecuzione sicuro. È quindi fondamentale verificare e aggiornare lo stato delle patch del PHP che elabora effettivamente le richieste web.

Confronta lo stato di applicazione delle patch e lo stato dell'assistenza

Per entrambe le vulnerabilità, ciò che conta in primo luogo è lo stato delle patch all’interno del ramo PHP in uso. Il progetto PHP indica le versioni corrette specifiche per le serie supportate. I livelli di patch precedenti della stessa serie sono considerati a rischio; l’aggiornamento alla versione indicata o a una versione più recente di questo ramo costituisce la soluzione completa prevista.

A Aggiornamento tramite patch rimane nella stessa serie di sviluppo, ad esempio dalla versione 8.3.35 alla 8.3.36. Ha lo scopo di fornire la correzione di sicurezza e presenta un ambito di compatibilità più ristretto rispetto al passaggio dalla versione 8.2 alla 8.4. Quest’ultimo è una migrazione: dipendenze, estensioni, codice applicativo ed eventualmente l’implementazione devono essere verificati separatamente.

PHP 8.2 rimane utilizzabile per la risoluzione immediata dei problemi, a condizione che sia in esecuzione almeno la versione 8.2.35. Tuttavia, il ramo raggiungerà la fine del supporto il 31 dicembre 2026. Pertanto, non è consigliabile fermarsi a questa versione: pianifica il passaggio a un ramo con supporto più lungo, dopo aver verificato la compatibilità dell'applicazione in un ambiente adeguato.

Con PHP 8.1 e versioni precedenti è necessaria particolare cautela. Il progetto PHP non fornisce una versione regolare e aggiornata a tal fine; i backport minimi del codice sorgente non sono equiparabili a un pacchetto generalmente disponibile e mantenuto. Un backport di sicurezza documentato dal fornitore del sistema operativo può essere adeguato, ma richiede una conferma nell’avviso di sicurezza o nel changelog del pacchetto. In assenza di tale conferma, è necessaria una migrazione anziché una semplice modifica estetica della versione.

Verificare il tempo di esecuzione effettivo sul web

La verifica della versione inizia con un'analisi dello stato attuale, ma non deve limitarsi alla shell. Su un server gestito autonomamente, i seguenti comandi mostrano la versione del comando PHP eseguito su quel server e i file di configurazione individuati da tale comando. Non modificano né i pacchetti né la configurazione e sono quindi adatti come primo passo di verifica a basso rischio.

php -v
php --ini

L'output descrive solo il comando richiamato tramite questo comando della shell Runtime CLI. Un sito web può invece essere gestito tramite PHP-FPM, Apache con mod_php, php-cgi o un container. Questo ambiente di esecuzione web può utilizzare una versione di PHP e file di configurazione diversi rispetto al comando php -v sull'host. Ai fini della valutazione della sicurezza, è determinante il processo che elabora le richieste HTTP effettive.

Nel managed hosting, quindi, controlla nel pannello clienti la versione PHP selezionata per ogni progetto o dominio e, se necessario, verifica lo stato delle patch del servizio fornito. In caso di più domini, è necessario controllare singolarmente ogni assegnazione: un dominio principale potrebbe già utilizzare il ramo aggiornato, mentre un negozio online, un’istanza di staging o un sottodominio potrebbero ancora utilizzare un interprete più vecchio.

Sui server con PHP-FPM, la configurazione del servizio, l'inventario dei pacchetti e la documentazione relativa alla distribuzione vanno considerati come un unico insieme. Negli ambienti containerizzati, devi inoltre verificare l'immagine effettivamente distribuita e non solo un manifesto di build locale. È fondamentale stabilire quale revisione nel pod o nel container in esecuzione accetta le richieste web; un'immagine di base aggiornata non protegge un'istanza precedente già in esecuzione.

Pianificare i percorsi di aggiornamento in base alla modalità operativa

La procedura di aggiornamento più adeguata dipende da chi fornisce l’interprete e da dove viene utilizzato. Solo una volta chiarita questa ambito di responsabilità è possibile decidere in modo affidabile se sia necessario un cambio di pannello, un aggiornamento del pacchetto, una nuova immagine o un aggiornamento del produttore. La seguente classificazione distingue questi casi senza equiparare le modalità operative in termini di rischio.

Nel caso dell’hosting condiviso, il provider dovrebbe fornire il livello di patch di sicurezza per la versione PHP selezionata; l’amministratore verifica poi l’applicazione. Con PHP-FPM o mod_php, l’amministratore di norma aggiorna i pacchetti e successivamente riavvia in modo controllato il servizio effettivamente interessato. Un semplice riavvio senza l’applicazione della correzione non sostituisce l’aggiornamento.

Le distribuzioni Linux forniscono spesso le correzioni di sicurezza sotto forma di Backport. In tal caso, il numero di versione visibile del pacchetto potrebbe differire da quello delle versioni pubblicate su php.net, sebbene la correzione sia inclusa. Pertanto, non limitarti a confrontare stringhe come „8.4.26“, ma leggi l’avviso di sicurezza e il changelog del distributore. Il progetto PHP sottolinea che le distribuzioni e i fornitori di versioni LTS possono ricevere le patch.

I container richiedono una procedura specifica: creare un’immagine corretta o scaricarla dal fornitore, distribuirla e sostituire le vecchie istanze. Nel caso delle interfacce NAS, dei dispositivi di rete o delle applicazioni web pronte all’uso, la correzione spetta invece al produttore del prodotto. Una patch del sistema operativo host non raggiunge necessariamente l’interprete integrato; l’inventario e le indicazioni del produttore rimangono quindi indispensabili.

Misure immediate senza false rassicurazioni

Il giorno dell’aggiornamento, per prima cosa crea un inventario completo: domini, API, interfacce di gestione, container e prodotti che potrebbero contenere PHP integrato. Per ogni servizio, annota la modalità operativa web, il canale di aggiornamento responsabile e il runtime PHP effettivamente utilizzato. Successivamente, verrà data priorità a ogni servizio accessibile pubblicamente o critico per l’azienda, non solo al server con il numero di versione più evidente.

Successivamente, installa l'aggiornamento di sicurezza rilasciato dal provider di hosting, dal distributore Linux, dal produttore dell'immagine o del prodotto. Per i rami PHP supportati, l'aggiornamento allo stato delle patch corrette costituisce la soluzione completa; un WAF, le regole di upload o il riavvio del server web non lo sostituiscono. Organizza la procedura in modo tale che l’aggiornamento del pacchetto, dell’immagine o del produttore sia documentato in modo tracciabile e possa essere risalito in caso di problemi.

Dopo l'aggiornamento è necessario tutti i vecchi lavoratori devono essere terminati e sostituiti da processi che abbiano comprovatamente caricato il runtime aggiornato. Utilizza un ricaricamento solo se la gestione specifica del servizio garantisce questa sostituzione completa; in caso contrario, è necessario un riavvio controllato. Verifica quindi gli orari di avvio dei processi, lo stato dei servizi o il runtime web rilevato internamente, invece di limitarti a dare per scontata la sostituzione. Nel caso dei container, distribuisci l’immagine corretta ed elimina tutte le vecchie istanze.

Verifica quindi i flussi applicativi principali quali la registrazione, i moduli, i caricamenti, il checkout e le API. I test dimostrano se l’applicazione e le estensioni funzionano con le patch aggiornate; tuttavia, da soli non provano né la sostituzione completa dei worker né l’assenza di una precedente compromissione. Questi aspetti devono essere valutati separatamente tramite verifiche operative e di sicurezza.

Se non è possibile applicare una patch in tempi brevi, alcune impostazioni possono limitare le vie di attacco note, ma non garantiscono una sicurezza totale. La disattivazione dell’indicatore di avanzamento del caricamento deve essere effettiva prima dell’analisi di una richiesta. Verifica in anticipo se le applicazioni o le interfacce necessitano di questa barra di avanzamento, quindi riavvia ogni worker PHP interessato. Verifica infine che nessun processo precedente continui a funzionare con l’impostazione precedente.

session.upload_progress.enabled = 0

Anche l'impostazione di limiti conservativi per i dati POST e altre opzioni indicate nel bollettino di sicurezza possono ridurre solo in parte la superficie di attacco. Letti in ritardo .user.ini-file o un ini_set() all’interno dell’applicazione non sono sufficienti per questa configurazione. Considera tali misure come una riduzione temporanea del rischio e mantieni l’aggiornamento di sicurezza come obiettivo.

Da ciò va distinta la normale gestione delle sessioni salvate. Il contributo alla Garbage collection delle sessioni PHP spiega come la pulizia, gli accessi ai file e i worker interagiscano durante il normale funzionamento. Tuttavia, questa ottimizzazione operativa non risolve le vulnerabilità qui trattate e non sostituisce né la versione corretta della patch PHP né la successiva sostituzione dei processi in esecuzione.

Dopo l'applicazione della patch, verificare il funzionamento e individuare eventuali anomalie

Un aggiornamento dei pacchetti completato con successo dimostra, in un primo momento, solo che sono stati installati dei file o dei pacchetti. Non conferma né che il processo web abbia caricato il nuovo runtime, né che l’applicazione funzioni correttamente con esso. Verifica quindi, dopo il riavvio, il runtime web rilevante per il servizio e documenta l'ora, la versione, il servizio riavviato e il risultato del controllo di funzionamento.

Il test funzionale dovrebbe coprire i processi chiave reali: pagine pubbliche importanti, accesso e disconnessione, invio di moduli, caricamento di file, checkout o prenotazione, nonché endpoint API e attività in background. Testa solo le operazioni per le quali disponi delle autorizzazioni necessarie e, nel caso di negozi online in produzione, utilizza, per quanto possibile, i dati di test previsti a tale scopo. Controlla contemporaneamente i log del server web, di PHP e dell’applicazione per individuare eventuali nuovi errori, arresti anomali ricorrenti o codici di stato inattesi.

È necessario un nuovo inizio per creare processi duraturi e Lavoratore caricare il codice aggiornato, ma non genera di per sé una correzione. Senza l’aggiornamento installato, la vulnerabilità rimane. In caso di carico elevato, la finestra di manutenzione dovrebbe essere scelta in modo tale che le richieste possano essere elaborate in modo ordinato e che gli effetti del riavvio di un worker rimangano osservabili.

L'impatto di un riavvio controllato sulla velocità di elaborazione dipende dal numero e dal carico dei processi PHP. Ai fini della pianificazione, è utile tenere conto delle code, dei lavori in corso e delle transazioni critiche, anziché terminare i processi in modo non coordinato. La guida Capire i worker PHP spiega il ruolo di questi processi nelle richieste dinamiche parallele.

Se dopo l'applicazione della patch si verificano anomalie, distinguere tra errori di compatibilità dell'applicazione e un'implementazione incompleta. Confrontare la configurazione, le estensioni attivate e il runtime web con lo stato precedente alla manutenzione. Un rollback non deve comportare che un servizio accessibile pubblicamente rimanga permanentemente in uno stato vulnerabile; in tal caso, definire rapidamente un percorso di aggiornamento compatibile e corretto.

Dare priorità alle installazioni PHP obsolete e nascoste

È necessario prestare particolare attenzione ai sistemi in cui PHP non è visibile come runtime installato intenzionalmente: immagini Docker, appliance virtuali, NAS e interfacce di rete, nonché prodotti software già pronti. Un aggiornamento dell’host non aggiorna automaticamente né un’immagine container né il runtime integrato in un prodotto del produttore. È quindi opportuno chiedere specificatamente al produttore una valutazione e un aggiornamento di sicurezza per il prodotto in questione.

Per i rami obsoleti occorre distinguere chiaramente tre casi. Una versione di PHP con supporto regolare riceve gli aggiornamenti di sicurezza pubblicati dal progetto PHP. Un backport di distribuzione o di un fornitore può contenere la correzione nonostante il numero di versione visibile sia diverso, ma deve essere documentato dall'avviso di sicurezza o dal changelog di tale fornitore. Il codice sorgente gestito autonomamente, invece, richiede che l’utente si assuma la responsabilità della compilazione, del collaudo e del funzionamento; non costituisce un sostituto equivalente di un canale di aggiornamento regolare.

PHP 8.1 e i rami precedenti non ricevono più rilasci regolari dall'upstream. Per PHP 8.2 è disponibile una versione corretta, ma il ramo raggiungerà la fine del supporto alla fine del 2026. Utilizza una correzione disponibile per risolvere la situazione urgente, ma per le versioni obsolete o in scadenza pianifica inoltre un aggiornamento testato Migrazione su un ramo con supporto più lungo.

1. Aggiornare innanzitutto i servizi accessibili pubblicamente con un runtime PHP non aggiornato, soprattutto se sono disponibili funzioni di caricamento o di amministrazione.
2. Utilizzare Apache con mod_php e gestire subito dopo negozi online, API o portali clienti di importanza critica per l'azienda; l'avviso di sicurezza ufficiale evidenzia un rischio particolarmente critico per mod_php.
3. Registrare container, appliance e prodotti di terze parti sulla base di immagini, inventario e stato del produttore; l'assenza di pacchetti PHP visibili non è un segnale di sicurezza.
4. Isolare i servizi non supportati o per i quali non è possibile applicare tempestivamente le patch e limitarne l'accesso, pianificando al contempo in modo vincolante la sostituzione, l'aggiornamento o la migrazione.

La segmentazione della rete, l’obbligo di utilizzare una VPN o regole di accesso restrittive possono far guadagnare tempo nel caso in cui le interfacce di gestione non possano essere aggiornate immediatamente. Tuttavia, sono solo Misure transitorie, poiché gli account utente interni, i dispositivi compromessi e le condivisioni configurate in modo errato possono continuare a costituire vie di attacco. Se per un prodotto non viene offerta alcuna correzione o se il ramo PHP è definitivamente fuori dal supporto, la scelta più sicura è quella di sostituirlo o di effettuare la migrazione.