PHP 8.2 fine supporto il 31 dicembre 2026: cosa serve per PCI DSS e SOC 2

La data da segnare

PHP 8.2 raggiunge l'end-of-life il 31 dicembre 2026. Lo indica il registro ufficiale delle versioni di php.net, ripreso da php.watch: PHP 8.2, rilasciato 3 anni e 10 mesi fa (08 Dec 2022), ha terminato il supporto attivo 1 anno e 9 mesi fa (31 Dec 2024) e il supporto di sicurezza termina tra 2 mesi e 3 settimane (31 Dec 2026). L'ultima release prima dello stop è la 8.2.34, uscita il 24 settembre 2026.

Il dettaglio che conta per chi gestisce server in produzione: dal 31 dicembre 2024 PHP 8.2 è già in sola manutenzione di sicurezza, non riceve più correzioni di bug. Dopo il 31 dicembre 2026 qualsiasi CVE scoperta non riceverà una patch ufficiale per la 8.2. Questo è il punto che un auditor PCI DSS o SOC 2 va a verificare: non se il sito "funziona ancora", ma se il vendor del runtime continua a pubblicare patch di sicurezza.

Perché finisce nei rilievi di audit

PCI DSS dedica il Requirement 6 allo sviluppo e manutenzione sicura di sistemi e software. Una guida alla norma lo spiega senza giri di parole: il software end-of-life, che sia un sistema operativo, un database o un'applicazione non più supportata, pone un rischio enorme per la conformità PCI DSS. Le conseguenze pratiche elencate sono concrete: l'uso di software EOL può far fallire il requirement 6 (sistemi sicuri) e il requirement 5 (protezione antimalware), e in caso di violazione l'uso di software EOL può essere interpretato come negligenza, con sanzioni più pesanti.

Lo stesso principio vale per i framework di continuous monitoring: un runtime PHP fuori supporto, se presente nell'ambiente che processa o custodisce dati sensibili, è il tipo di evidenza che un revisore segnala come eccezione da remediation plan, indipendentemente dal fatto che l'applicazione sia ancora "online e funzionante".

Il piano pratico

Non serve aspettare dicembre. Chi ha un audit SOC 2 di tipo II o un assessment PCI DSS pianificato nei primi mesi del 2027 deve avere il runtime già aggiornato prima dell'apertura della finestra di verifica, non entro la scadenza stessa: gli auditor valutano lo stato dei sistemi durante il periodo coperto dal report, non lo stato il giorno della consegna.

I passi concreti: inventariare quali applicazioni girano ancora su PHP 8.2 (php -v su ogni host), verificare la compatibilità delle dipendenze con PHP 8.3 o 8.4, pianificare il test in staging prima del cambio in produzione. Chi gestisce hosting condiviso deve inoltre comunicare ai clienti, per iscritto, la data entro cui il pannello smetterà di offrire PHP 8.2 come opzione selezionabile.

Informazioni pratiche

• Scadenza: 31 dicembre 2026, fine patch di sicurezza per PHP 8.2 (fonte: endoflife.date/php, php.watch)
• Versioni di destinazione: PHP 8.3 o PHP 8.4, entrambe ancora in finestra di supporto attivo
• Verifica versione: comando php -v su ogni server coinvolto
• Riferimento normativo: PCI DSS, Requirement 6 (sviluppo e manutenzione sicura di sistemi e software)
• Consiglio operativo: completare la migrazione prima dell'apertura del periodo coperto dal prossimo audit SOC 2 o PCI DSS, non entro la scadenza EOL stessa