Aggiornamento di sicurezza PHP 2026: guida alla correzione PHP2Shell CVSS 9.2

La divulgazione in sé è stata insolita. Il 20 ottobre il team di sicurezza di PHP ha pubblicato un preavviso, ha fissato il rilascio per il 21 ottobre alle 14:00 UTC e si è riservato il diritto di anticiparlo. Gli identificatori CVE sono trapelati un giorno prima della divulgazione, insieme a dichiarazioni gonfiate su gravità e versioni interessate. I vendor avevano già ricevuto le patch per le loro distribuzioni e i CERT nazionali hanno cominciato a pubblicare indicazioni prima ancora che il codice fosse pubblico. In altre parole: una volta uscito il rilascio, nessuno aveva una scusa legittima per ritardare.

Due vulnerabilità, un rilascio di emergenza

Nessuno dei due bug è un errore di logica in un'applicazione. Entrambi risiedono nel modo in cui PHP prepara e smonta una richiesta, ed è per questo che nessun aggiornamento di framework o plugin, e nessuna regola WAF, può sostituire l'aggiornamento dell'interprete.

CVE-2026-109618 — RCE tramite corruzione legata all'esaurimento della memoria. Quando PHP esaurisce la memoria, interrompe la richiesta invece di continuare. L'avviso descrive un percorso in cui tale interruzione blocca PHP mentre i dati interni della richiesta sono inizializzati solo in parte, così la fase di pulizia della richiesta tratta poi come validi dati non validi. Un attaccante in grado di spingere l'uso della memoria al limite può quindi orientare ciò che accade dopo. È la vulnerabilità che rende il consiglio di mitigazione così controintuitivo: il vendor chiede agli amministratori di impedire a PHP di raggiungere il proprio tetto di memoria, non di abbassarlo.

CVE-2026-109619 — RCE tramite stato globale residuo. Lo stato interno di proprietà di una richiesta può sopravvivere dopo che la memoria che lo conteneva è stata liberata. La richiesta successiva gestita dallo stesso processo worker può consumare quello stato residuo prima che l'inizializzazione normale lo azzeri. Su un worker di lunga vita — esattamente ciò che sono PHP-FPM, mod_php e LiteSpeed — il riuso della memoria è una condizione normale e permanente, ed è per questo che non si tratta di un caso limite riservato a configurazioni esotiche.

Il nome PHP2Shell non è un'etichetta ufficiale del progetto PHP: è nato tra ricercatori e vendor di sicurezza e ha attecchito, quindi lo vedrete negli output degli scanner, nei bollettini dei provider di hosting e negli avvisi dei CERT in riferimento esattamente a queste due CVE.

Chi è davvero esposto

L'avviso è diretto: sono a rischio tutte le installazioni PHP che servono richieste web. Questo include PHP-FPM dietro nginx o Apache, Apache con mod_php, php-cgi, LiteSpeed e FrankenPHP. La differenza tra loro è quanta fatica deve fare un attaccante.

Se ospitate WordPress, WooCommerce, Laravel, Magento, ERP affini a Magento o un portale di prenotazioni in PHP per la vostra attività commerciale, rientrate nelle prime tre righe della tabella anche quando il codice applicativo è perfetto. Per uno sguardo più ampio su chi dovrebbe gestire il runtime, vedete la nostra guida all'IT outsourcing in Turchia.

Verificate la vostra versione in due minuti

La trappola, qui, è l'aritmetica delle versioni. Le distribuzioni spediscono PHP 8.3.6 o 8.2.x per anni e retroportano le correzioni di sicurezza dentro lo stesso numero di versione visibile, quindi php -v da solo non vi dice se siete protetti. Confrontate tre cose.

1. La versione PHP visibile e la SAPI che serve il traffico.

2. La versione del pacchetto della distribuzione, non quella upstream. Su Debian e Ubuntu la risposta onesta è il changelog; sui sistemi RPM interrogate il changelog del pacchetto.

Se il changelog della versione installata cita entrambe le CVE, siete protetti anche se php -v continua a dire 8.3.6. È questa la differenza tra una risposta di sicurezza vera e una superstizione da numero di versione.

3. Se il processo in esecuzione ha ricaricato il binario corretto. Un aggiornamento di pacchetto mai seguito da un riavvio lascia in memoria il vecchio codice. Confrontate l'ora di avvio del servizio con l'ora di installazione del pacchetto:

Su cPanel, Plesk, DirectAdmin o una piattaforma gestita l'equivalente è il selettore PHP più il bollettino di sicurezza del provider stesso: identificate la versione integrata effettivamente assegnata al vostro sito, non quella più recente pubblicizzata nel pannello. Se il vostro provider non è in grado di indicare una data di patch, considerate il sito come non corretto. I nostri servizi di infrastruttura digitale coprono questo audit oltre all'aggiornamento stesso; potete anche semplicemente contattarci con il vostro stack e vi diremo cosa controlleremmo.

Versioni corrette e baratro EOL

PHP supporta ogni ramo per due anni di sviluppo attivo e altri due anni di correzioni di sicurezza. È questa politica ad aver prodotto quattro correzioni simultanee il 21 ottobre — ed è sempre questa a lasciare i rami più vecchi a se stessi.

Due avvertimenti pratici tratti dall'avviso. Primo: se installate PHP da un repository della community invece che dalla vostra distribuzione, quel repository può restare indietro rispetto alla finestra di sicurezza: i manutentori dei diffusissimi pacchetti Remi hanno dichiarato che non avrebbero avuto aggiornamenti lo stesso giorno, quindi la strada sicura sono i pacchetti della vostra distribuzione o una compilazione da sorgente. Secondo: se siete su PHP 8.1 o precedenti, «aspettare il nostro provider» è una decisione di sicurezza che state prendendo a nome dei vostri clienti — documentatela o cambiatela.

Correggere un server di produzione senza causare un incidente

Gli aggiornamenti di sicurezza all'interno dello stesso ramo minore rompono raramente un'applicazione; lo fanno i riavvii non testati. L'ordine che segue è quello che usiamo sulle piattaforme commerciali in produzione, e tiene breve la finestra di rischio senza giocarsi il sito.

1. Prima lo snapshot. Uno snapshot di hypervisor o di volume che avete davvero testato si ripristina in pochi minuti, e rende economica la decisione di applicare la patch.
2. Riproducete la versione in staging. Stesso ramo, stesse estensioni, stessi file di configurazione PHP, una copia dei dati di produzione. Percorrete i flussi di checkout, richiesta preventivo e pagamento, non solo la home page.
3. Aggiornate il set di pacchetti come un blocco unico. Mescolare una CLI aggiornata con un binario FPM vecchio è il modo tipico in cui ci si ritrova con un php -v corretto e un percorso web ancora esposto: apt-get update && apt-get install --only-upgrade 'php8.3-*', oppure dnf update --security 'php*' sugli host RPM.
4. Riavviate il processo che serve le richieste, poi verificate che sia ripartito. systemctl restart php8.3-fpm (oppure ricaricate Apache / riavviate LiteSpeed), poi ricontrollate l'ora di avvio del servizio ed eseguite di nuovo le verifiche su versione e changelog.
5. Sorvegliate il log degli errori per un'ora. Messaggi OOM, nuove firme di errori fatali e tassi di 5xx insoliti sono i segnali che le impostazioni di mitigazione indicate più avanti potrebbero richiedere una messa a punto — non buone ragioni per rimandare l'aggiornamento.
6. Registrate le evidenze. Versione del pacchetto, riga di changelog che cita entrambe le CVE, marca temporale del riavvio. Clienti, auditor e revisioni dei controlli in stile ISO 27001 chiedono esattamente questo, e salvarlo richiede dieci secondi.

Quando l'aggiornamento deve aspettare — un'integrazione ERP validata, un calendario di rilascio sotto embargo, un giro di approvazioni del cliente — mettetevi davanti un controllo compensativo lo stesso giorno, invece di lasciare la porta aperta e sperare. È ciò che hanno raccomandato gli avvisi dei CERT nazionali esattamente per questa situazione: isolare dalla rete pubblica le applicazioni PHP esposte a Internet dove la correzione immediata non è possibile.

Mitigazioni temporanee: restringete la finestra, non chiudetela

L'avviso di PHP lo dice senza mezzi termini: non esiste una mitigazione completa e l'aggiornamento è l'unica scelta sicura. Considerate quanto segue come una copertura da giorni, non da settimane, applicata a un livello che l'applicazione non può scavalcare, con tutti i worker riavviati dopo.

Contro CVE-2026-109618 (il percorso da esaurimento di memoria)

• Lasciate che PHP esaurisca la memoria della macchina invece del proprio limite: memory_limit = -1, idealmente come php_admin_value memory_limit = -1, così il codice applicativo non può rimettere il tetto.
• Tenete piccoli i corpi delle richieste all'interprete: l'indicazione dell'avviso è intorno agli 8 MB quando non ci sono upload e intorno ai 32 MB quando ci sono, con upload_max_filesize inferiore a post_max_size.
• Applicate al proxy i limiti sulle operazioni costose, perché il danno sta nella richiesta decodificata, non nella dimensione in transito: dimensione totale del corpo decodificato, numero di campi in input, numero di parti multipart, numero di header, profondità di annidamento — e coprite anche le richieste che arrivano senza un Content-Length utilizzabile.
• Contenete il raggio dell'impatto con un limite di memoria di container o cgroup dimensionato in modo che un worker terminato sia un evento di disponibilità, non un evento per l'intero host. Non sostituitelo con RLIMIT_AS o RLIMIT_DATA: quei limiti innescano proprio l'errore di allocazione che sta nel percorso vulnerabile.

Contro CVE-2026-109619 (il percorso dello stato residuo)

• Disabilitate l'avanzamento dell'upload in sessione con session.upload_progress.enabled = 0, impostato in php.ini, nel pool FPM o nella configurazione del server — in un punto che si applica prima dell'analisi della richiesta. Poi riavviate ogni worker, perché FPM condivide tra le richieste lo stato già inizializzato dei moduli. ini_set() e .user.ini arrivano troppo tardi per essere d'aiuto.
• Su PHP 8.5, impostate fatal_error_backtraces = 0 e riavviate.
• Rimuovete le impostazioni per richiesta non valide o deprecate, che quindi emettono diagnostica nelle prime fasi dell'inizializzazione. Sopprimere il messaggio con error_reporting, display_errors o @ non rimuove il percorso di codice.
• Date la caccia agli errori fatali raggiungibili da un attaccante e ai timeout di lunga durata nei gestori di upload e importazione, nel codice di callback e nelle routine di pulizia — gli stessi punti in cui risiedono entrambi i bug.

Una CDN o un WAF davanti all'origin si guadagnano comunque il posto: rate limiting, blocco delle richieste dalle forme anomale e virtual patching riducono il rumore e rallentano la scansione opportunistica. Per un attaccante mirato sono un dosso stradale, non un controllo che possiate firmare come rimedio.

Cosa chiedere oggi al vostro provider di hosting

Gli script del supporto rispondono a questa domanda con «siamo sempre aggiornati». Chiedete invece evidenze che potete archiviare:

• La versione PHP integrata assegnata al nostro account, e se si tratta di un pacchetto della distribuzione o di una build del vendor.
• La data in cui le correzioni per CVE-2026-109618 e CVE-2026-109619 hanno raggiunto il vostro parco macchine, con la stringa completa della versione interna del pacchetto.
• Se la correzione si applica alla SAPI che serve il nostro sito (FPM, LiteSpeed, mod_php) e a ogni nodo di staging o di backup che potremmo ripristinare.
• Se la piattaforma non è ancora corretta: quale controllo compensativo è attivo e fino a quando.
• La vostra politica consolidata per i rami EOL — cosa succede al mio sito il 1º gennaio 2027, quando termina il supporto di sicurezza di PHP 8.2.

Un provider che risponde a quelle cinque domande in una sola email è un provider da tenersi. Uno che risponde con materiale di marketing apre invece una conversazione sulla migrazione; vale la stessa diligenza che applichiamo nel nostro lavoro di gap assessment ISO 27001, dove il deliverable è l'evidenza, non la rassicurazione.

Dovete presumere di essere stati compromessi?

Non automaticamente — ma verificate invece di tirare a indovinare, soprattutto se il server era esposto alla rete pubblica durante la finestra precedente alla vostra patch.

• Cercate processi, listener e voci cron che non avete creato voi, e connessioni in uscita dall'utente del worker PHP.
• Confrontate con un diff le directory applicative scrivibili rispetto a una fonte di verità del deploy: nuovi file PHP, directory di upload modificate, cartelle temporanee eseguibili senza motivo apparente.
• Cercate nei log web tempeste di richieste intorno alle ore della divulgazione, corpi multipart insolitamente grandi o richieste che hanno restituito 500 con firme OOM nel log degli errori PHP.
• Verificate che il binario corretto sia effettivamente in esecuzione — a rispondere è il confronto tra i tempi di riavvio fatto sopra.
• Se qualcosa non torna, trattatelo come un incidente: preservate disco e log, ruotate ogni credenziale che l'applicazione può leggere e ricostruite da un'immagine nota e sana. Reinstallare il pacchetto PHP sopra un host compromesso non è un rimedio.

Un esempio pratico dalla nostra stessa infrastruttura

worldwidetradex.com lo gestiamo su Ubuntu 24.04 LTS con nginx e PHP-FPM, quindi il 22 ottobre abbiamo eseguito su noi stessi i controlli descritti sopra. I risultati illustrano bene perché l'aritmetica delle versioni conta:

La lezione vale per qualsiasi stack: la vostra postura di sicurezza è la versione del pacchetto più il changelog più il riavvio, non la stringa di versione da marketing nel pannello dell'hosting.

Rendete il patching una routine, non un'impresa eroica

PHP2Shell non è memorabile perché esotico; è memorabile perché l'interprete su cui gira gran parte del web aveva un bug critico sfruttabile prima dell'autenticazione e migliaia di host hanno dovuto reagire nel giro di poche ore. I team che questa volta hanno potuto dormire sonni tranquilli non erano fortunati — avevano l'automazione.

• Aggiornamenti di sicurezza incustoditi per l'interprete, con versione e riavvio registrati automaticamente.
• Un inventario che sa quale SAPI e quale ramo PHP usa ogni sito, compreso lo staging, i backup e quel WordPress del 2019 rimasto lì.
• Un percorso di ripristino provato più volte, così «correggiamo subito» non viene mai messo sul piatto della bilancia contro «non possiamo fare rollback».
• Un piano sui rami: niente su una release PHP il cui supporto di sicurezza termina entro i prossimi dodici mesi.
• Un responsabile con nome e cognome per ogni server e un percorso di escalation scritto, per i giorni in cui una patch arriva alle 14:00 UTC di un mercoledì.

Se preferite comprare questa capacità invece di assumerla in casa, ci prendiamo in carico le piattaforme PHP in produzione — cadenza delle patch, monitoraggio, backup e ripristini documentati — nell'ambito del nostro servizio di infrastruttura gestita. Iniziate con una breve descrizione del contesto e le quantità: richiedete un preventivo.

Domande frequenti

Fonti

• PHP — l'avviso di sicurezza «Critical remote code execution vulnerabilities, update now» e gli annunci di rilascio del 21 ottobre 2026, comprese le indicazioni di mitigazione e la timeline di supporto sulle versioni supportate.
• Avvisi di sicurezza GitHub per il repository PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) e GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, «Critical Vulnerabilities in PHP», che nomina entrambe le CVE.
• Infosecurity Magazine — «Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches» (21 ottobre 2026) e «PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure» (22 ottobre 2026).

Volete che l'aggiornamento venga gestito al posto vostro? Per parlare di patching, audit delle versioni, migrazione a una piattaforma PHP gestita e corretta o dell'infrastruttura che la circonda, contattateci o chiamate il +90 505 679 78 03.