Vulnerabilità critiche PHP: versioni corrette e test di regressione

Cosa ha comunicato PHP e quali sono i rischi

Il 21 ottobre 2026 il progetto PHP ha pubblicato correzioni per CVE-2026-109618 e CVE-2026-109619, due vulnerabilità critiche del runtime. In determinate condizioni possono consentire l’esecuzione di codice da remoto senza autenticazione su installazioni che gestiscono richieste web. PHP consiglia di considerarle esposte finché versione e correzione del fornitore non sono state verificate.

CVE-2026-109618 riguarda la corruzione dello stato interno durante la gestione dell’esaurimento della memoria. CVE-2026-109619 descrive uno stato globale che può conservare riferimenti alla memoria di una richiesta precedente. Non serve riprodurre l’attacco: aggiorna in modo controllato e verifica che l’applicazione funzioni.

L’avviso evidenzia un rischio specifico per Apache con mod_php. Cita anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. L’esposizione dipende da runtime, configurazione e percorsi dell’applicazione; non applicare lo stesso scenario a ogni installazione.

Versioni interessate e versioni corrette

La tabella riassume le versioni upstream pubblicate da PHP il 21 ottobre 2026. “Corretta dalla versione” indica il primo rilascio del ramo che include la correzione ufficiale. I pacchetti del sistema operativo, le immagini del fornitore e l’hosting gestito possono includere una correzione retroportata senza cambiare il numero mostrato. Controlla anche l’avviso del fornitore.

Il supporto di sicurezza di PHP 8.2 dovrebbe terminare il 31 dicembre 2026. La versione 8.2.35 corregge queste CVE nel ramo, ma pianifica il passaggio a una versione ancora supportata. PHP non pubblica più rilasci regolari per 8.1 e precedenti. Esistono correzioni minime per 7.4, 8.0 e 8.1; alcuni fornitori mantengono i propri pacchetti. Verifica cosa è installato davvero.

Prima di aggiornare: inventario e preparazione

Individua tutti i punti in cui viene usato PHP: server, container, immagini di base, pannelli hosting, prodotti con runtime incluso, processi in background e ambienti di test. Un sito può usare più versioni. Identifica il servizio che riceve traffico e chi gestisce ogni aggiornamento.

Annota versione e provenienza del pacchetto, sistema operativo, server web, runtime, immagine se presente, applicazione, ambiente, responsabile e piano per tornare alla versione precedente se qualcosa va storto. Non pubblicare `phpinfo()`: può mostrare informazioni sensibili. Usa inventari interni e strumenti autorizzati del fornitore.

Leggi le note del fornitore e le guide di migrazione se cambi ramo PHP. Prepara una finestra di manutenzione, un backup ripristinabile e un piano chiaro per tornare indietro. Per i servizi gestiti, chiedi conferma della versione e dell’eventuale riavvio o nuova distribuzione necessari.

Aggiornare in modo sicuro

1. Parti dai servizi raggiungibili da Internet e verifica se il fornitore ha pubblicato il pacchetto corretto.
2. Aggiorna prima un ambiente rappresentativo seguendo le istruzioni del sistema, dell’hosting o dell’immagine.
3. Ricostruisci e distribuisci i container con un’immagine corretta: aggiornare l’host non cambia PHP dentro l’immagine.
4. Riavvia o sostituisci i processi PHP secondo le indicazioni del fornitore, così caricano la nuova versione.
5. Controlla la versione nell’ambiente che riceve davvero il traffico.
6. Esegui i controlli di base e i test di regressione prioritari.
7. Durante la finestra concordata, controlla errori, registri e metriche.
8. Se qualcosa di critico non funziona, ferma la distribuzione, registra cosa è successo e torna alla versione precedente secondo il piano. Una regola WAF temporanea non sostituisce la correzione.

1. 01Mappare PHP
2. 02Applicare la correzione
3. 03Verificare i processi attivi
4. 04Testare i flussi
5. 05Rivedere i risultati
6. 06Decidere se distribuire

Preparare il piano di regressione

I test di regressione dopo una correzione servono a trovare effetti indesiderati nell’applicazione e nelle integrazioni. Non dimostrano che PHP sia privo di vulnerabilità e non sostituiscono analisi di sicurezza, dipendenze o configurazione.

Definisci il cambiamento: versione PHP, servizi, configurazione, estensioni, dipendenze e ambienti. Mappa i flussi che usano PHP e i componenti che condividono processi, sessioni, cache, file o code. Dai priorità all’impatto sul business, all’esposizione e alla difficoltà di recupero. Segna le dipendenze sconosciute come rischi da verificare.

Dividi i test in tre gruppi: controlli essenziali di disponibilità e funzioni principali; test mirati sui percorsi modificati o dipendenti; e una suite più ampia per i componenti più importanti. Conserva versione, ambiente e dati usati per poter capire e ripetere i risultati.

Esempi di casi di test

Adatta questi esempi all’architettura e alle regole del tuo sistema. Non sono un pacchetto universale: elimina ciò che non serve e aggiungi i flussi, le estensioni e le integrazioni del tuo prodotto. Usa account di test e dati fittizi, mai credenziali o dati personali reali.

Quando i test sono finiti?

Decidi prima di iniziare quali problemi devono bloccare la distribuzione. Non procedere se non funzionano accesso, permessi, operazioni importanti, integrità dei dati o integrazioni essenziali; se non puoi confermare la versione corretta; o se restano errori senza spiegazione. Un test bloccato dall’ambiente non è superato.

Alla fine confronta i test con l’ambito del cambiamento. Rivedi errori, blocchi, attività in sospeso, prove e rischi residui. Una suite tutta verde conferma solo i casi eseguiti: non dimostra che tutti i server siano stati aggiornati.

Fonti ufficiali e risorse utili

• Avviso di sicurezza ufficiale PHP
• Avviso CVE-2026-109618 (PHP/GitHub)
• Avviso CVE-2026-109619 (PHP/GitHub)
• Versioni PHP supportate
• Download ufficiali PHP
• Guida ufficiale alla migrazione a PHP 8.5

Questa guida è materiale informativo QA e non sostituisce le indicazioni di PHP, del sistema operativo, del container o del provider hosting. Ultima revisione: 21 ottobre 2026.