PHP2Shell: due vulnerabilità critiche in PHP. Cosa fare subito, anche sulle versioni non più supportate

Il 21 ottobre 2026 il team di PHP ha pubblicato un aggiornamento di sicurezza d'emergenza per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, ribattezzate PHP2Shell. Entrambe possono consentire l'esecuzione di codice da remoto senza autenticazione e hanno un punteggio CVSS v4.0 di 9,2. I dettagli sono trapelati il giorno prima del rilascio previsto e sono già stati segnalati i primi tentativi di attacco.

Cosa è successo

Le due vulnerabilità si trovano nel cuore dell'interprete PHP, non in un framework o in un'applicazione specifica:

• CVE-2026-109618: un errore di memoria esaurita può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte; la successiva pulizia della richiesta tratta quei dati come validi.
• CVE-2026-109619: uno stato interno legato a una richiesta può sopravvivere dopo che la memoria che lo conteneva è stata liberata, e una richiesta successiva gestita dallo stesso processo può riutilizzarlo.

In pratica, una richiesta HTTP costruita ad arte può portare all'esecuzione di codice sul server. Secondo l'avviso ufficiale, con mod_php l'attacco è stato dimostrato prima ancora che venga eseguito il codice dell'applicazione: non serve che il sito abbia a sua volta una vulnerabilità.

Chi è a rischio

Tutte le installazioni PHP che rispondono a richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è considerato più alto con mod_php. Sono coinvolti siti istituzionali, e-commerce, CMS come WordPress, gestionali web e piattaforme per la ricerca clinica come REDCap, che è scritto in PHP.

Versioni corrette e versioni che resteranno vulnerabili

Le correzioni sono disponibili solo per i rami di PHP ancora supportati. Tutte le versioni precedenti restano esposte.

Due aspetti da tenere presenti. Le distribuzioni Linux possono pubblicare la correzione come backport nei propri pacchetti, senza cambiare il numero di versione: in quel caso fa fede l'avviso di sicurezza del fornitore. E il ramo 8.2 smetterà di ricevere aggiornamenti il 31 dicembre 2026: chi aggiorna oggi alla 8.2.35 si mette al sicuro per poche settimane e dovrà comunque pianificare il passaggio a 8.4 o 8.5.

Cosa fare subito

1. Censire i server: individuare tutte le macchine con PHP, partendo da quelle esposte su internet, e annotare versione e modalità di esecuzione (FPM, mod_php, CGI).
2. Aggiornare a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure installare il pacchetto corretto della propria distribuzione, e riavviare tutti i processi PHP. Secondo il team di PHP non esistono mitigazioni complete: l'aggiornamento è l'unica scelta sicura.
3. Se non è possibile aggiornare subito, applicare le mitigazioni parziali indicate nell'avviso ufficiale, che riducono alcune vie di attacco ma non rendono l'installazione sicura:
   • session.upload_progress.enabled=0, impostato in php.ini o nel pool FPM (non con ini_set() o .user.ini), con riavvio dei worker;
   • memory_limit=-1 non sovrascrivibile dall'applicazione, insieme a limiti contenuti per post_max_size e upload_max_filesize;
   • su PHP 8.5, anche fatal_error_backtraces=0.
4. Ridurre l'esposizione: regole WAF sui vettori noti, accesso limitato a VPN o indirizzi autorizzati per i sistemi interni, e messa offline temporanea dei sistemi che non si possono proteggere.
5. Verificare eventuali compromissioni sui server rimasti esposti: file PHP sconosciuti, processi anomali, account o cron aggiunti.

Il vero problema: le versioni PHP non più supportate

Molti server in produzione girano ancora su PHP 7.4, 8.0 o 8.1, spesso perché l'applicazione non è mai stata adattata alle versioni successive. Per questi sistemi oggi non esiste una patch ufficiale. Le strade possibili sono due:

• Mettere in sicurezza nel breve periodo: isolare l'applicazione dalla rete pubblica, applicare le mitigazioni disponibili e filtrare il traffico, sapendo che è una soluzione temporanea.
• Aggiornare a un ramo supportato, idealmente PHP 8.4 o 8.5. Spesso non basta installare la nuova versione: funzioni rimosse, controlli di tipo più rigidi e librerie datate richiedono di adeguare il codice e le dipendenze, e di provare tutto in un ambiente di test prima di andare in produzione.

Lo stesso vale per le piattaforme applicative: aggiornare PHP sotto un'istanza REDCap, un CMS o un gestionale richiede di verificare la compatibilità della versione installata e, se necessario, aggiornare anche l'applicazione.

Come può aiutarti Depalop

Ci occupiamo di applicazioni PHP critiche e dell'infrastruttura su cui girano. Per PHP2Shell offriamo un percorso in tre fasi:

• Verifica rapida: inventario dei server, versioni di PHP, modalità di esecuzione ed esposizione su internet, con un elenco di priorità.
• Messa in sicurezza immediata: aggiornamento dove possibile, mitigazioni di configurazione, filtri e isolamento per i sistemi che non si possono aggiornare subito, controllo di eventuali compromissioni.
• Aggiornamento pianificato a PHP 8.4 o 8.5 per le applicazioni su versioni non più supportate: analisi del codice e delle dipendenze, correzioni, test in ambiente separato, rilascio con piano di rientro.

Approfondisci i servizi di infrastruttura IT e sicurezza informatica e di gestione e manutenzione REDCap, oppure contattaci per una verifica dei tuoi server.

Fonti

• PHP.net – Security advisory: Critical remote code execution vulnerabilities
• PHP – Versioni supportate
• NCSC – Critical security issue affecting PHP