Il 21 ottobre 2026 il progetto PHP ha pubblicato le patch per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, note come php2shell. Un attaccante senza utente né password può, con richieste HTTP manipolate, leggere la memoria del server ed eseguire codice con i permessi del processo web. Se il tuo sito è un WordPress, PrestaShop, Drupal, Joomla, Magento o un’applicazione Laravel, gira su PHP ed è coinvolto.
Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se il tuo server ne ha una precedente, aggiornare è il lavoro di oggi.
Cosa è successo, senza gergo
Sono due difetti nel modo in cui PHP gestisce la memoria quando serve una richiesta web.
- CVE-2026-109618 (memoria esaurita a metà richiesta). Se PHP esaurisce la memoria mentre prepara i dati di una richiesta, la pulizia successiva tratta dati non validi come validi. Un attaccante lo provoca con richieste multipart (quelle dei moduli con file allegati) costruite per esaurire la memoria anche se la loro dimensione sembra entro i limiti. Avviso: GHSA-w8hw-w9fx-j79w.
- CVE-2026-109619 (stato che sopravvive tra una richiesta e l’altra). Un errore fatale, come l’esaurimento della memoria o il superamento del tempo massimo, interrompe la pulizia. Parte dello stato interno resta liberato ma raggiungibile, e la richiesta successiva servita dallo stesso processo lo usa. Huntress lo descrive come use-after-free nell’heap senza autenticazione, con fuga di memoria ed esecuzione remota di codice. Avviso: GHSA-6wmf-4rv5-p3rp.
Entrambe hanno un punteggio CVSS v4.0 di 9.2 su 10 (critico). Il post trapelato prima della pubblicazione parlava di 10.0; il valore ufficiale è 9.2.
La fuga di memoria ha una conseguenza pratica: ciò che il processo PHP ha caricato (password del database, token, chiavi API, certificati) può finire a chi sfrutta il difetto. Wiz ha dimostrato l’esecuzione remota senza autenticazione contro WordPress, Drupal e Joomla, oltre a questa via di fuga.
Chi è coinvolto
Secondo php.net, tutte le installazioni di PHP che servono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è maggiore con mod_php: Rapid7 spiega che lì il difetto è sfruttabile prima che venga eseguito il codice dell’applicazione, quindi nessun plugin di sicurezza di WordPress lo ferma.
Per versione:
| Ramo di PHP | Versione corretta | Stato |
|---|---|---|
| 8.5 | 8.5.12 | Supportato |
| 8.4 | 8.4.27 | Supportato |
| 8.3 | 8.3.36 | Supportato |
| 8.2 | 8.2.35 | Fine vita il 31-dic-2026 |
| 8.1, 8.0, 7.4 | Nessuna versione ufficiale | Solo backport nel codice sorgente |
PHP è usato dal 69,7% dei siti di cui si conosce il linguaggio lato server, secondo W3Techs citato da Infosecurity Magazine. Se il tuo sito è stato fatto con un template WordPress e nessuno lo ha più toccato dalla consegna, con ogni probabilità è ancora su una versione di PHP senza patch.
Come verificare la versione di PHP
Tre modi, dal più facile al più affidabile:
- Pannello dell’hosting. In cPanel, Plesk o nel pannello del tuo provider di solito c’è una sezione “Versione PHP” o “PHP Selector”. In WordPress compare anche in Strumenti → Salute del sito → Info → Server.
php -vvia SSH. Attenzione: mostra la versione della riga di comando, che può non coincidere con quella che serve il sito. Su un server con più versioni installate capita spesso che siano diverse.phpinfo(). Un fileinfo.phpcon<?php phpinfo();nella root del sito mostra la versione e la SAPI che serve davvero le richieste (la riga “Server API” dice se è FPM, Apache 2.0 Handler, cioè mod_php, CGI o LiteSpeed). Cancellalo appena lo hai guardato: quel file mostra a chiunque la configurazione del server.
Se usi i pacchetti della tua distribuzione Linux (Debian, Ubuntu, RHEL e derivate), il numero di versione può non coincidere con la tabella anche con la patch applicata: le distribuzioni LTS hanno ricevuto le patch prima e le includono nella propria numerazione. Controlla l’avviso di sicurezza della tua distribuzione per il pacchetto PHP.
Hosting condiviso o VPS. Su un hosting condiviso il provider controlla il binario di PHP e il php.ini globale: tu scegli il ramo dal pannello, ma la patch la applica lui. Chiedigli per iscritto se ha già aggiornato alle versioni corrette. Su un VPS o un server dedicato lo fai tu, o chi ti segue la manutenzione.
Cosa fare adesso
1. Aggiornare
Passa a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure installa il pacchetto corretto della tua distribuzione. Poi riavvia tutti i processi PHP (il servizio php-fpm, Apache se usi mod_php, LiteSpeed). Finché i vecchi processi restano attivi, il codice vulnerabile continua a girare.
Se sei sull’8.2, la patch ti copre adesso, ma quel ramo smette di ricevere correzioni il 31 dicembre 2026. Conviene pianificare già il passaggio all’8.3 o successiva.
2. Se sei su PHP 8.1 o precedente
Il progetto PHP non pubblica più versioni per 8.1, 8.0 e 7.4. Ha pubblicato backport minimi nel codice sorgente, in branch del suo GitHub, per chi compila PHP. Se non è il tuo caso, hai due strade: un provider o una distribuzione che supporti ancora quella versione, oppure migrare l’applicazione all’8.3 o successiva. La migrazione può rompere plugin o codice datato, quindi si prova su una copia prima di toccare la produzione.
3. Mitigazioni temporanee mentre aggiorni
Sono quelle pubblicate dal progetto PHP. Riducono l’esposizione, non sostituiscono l’aggiornamento:
session.upload_progress.enabled = 0nelphp.inio nella configurazione del pool PHP-FPM, poi riavviare tutti i worker. Impostarlo conini_set()o in un.user.ininon funziona.- Su PHP 8.5, inoltre:
fatal_error_backtraces = 0. - Contro l’esaurimento della memoria: limitare nel server web o nel proxy la dimensione della richiesta e il numero di campi, parti e header. Se il sito non riceve upload di file,
post_max_size = 8M; se li riceve,32M.
Su un hosting condiviso probabilmente non hai accesso al php.ini né al pool: in quel caso anche la mitigazione spetta al provider.
Se non puoi aggiornare o sospetti un attacco
L’NCSC britannico raccomanda, se non puoi aggiornare, di cercare indicatori di compromissione e backdoor, e, se non puoi nemmeno applicare le mitigazioni, di valutare di scollegare il sistema. Un sito fermo per un giorno costa meno di un sito che distribuisce malware o espone i dati dei tuoi clienti.
Cosa controllare su un sito PHP:
- File
.phpnuovi o modificati in cartelle dove non dovrebbero esserci, comewp-content/uploadso le directory di cache. - Utenti amministratori che nessuno ha creato.
- Attività pianificate (cron) o processi che non riconosci.
- Errori fatali per memoria esaurita o timeout nei log di PHP dal 20 ottobre in poi, soprattutto su richieste POST multipart.
Se trovi qualcosa, o se il tuo server è rimasto esposto senza patch, ruota i segreti che il processo PHP aveva in memoria: password del database, chiavi API (gateway di pagamento, email, CRM), token e, se il certificato TLS è servito dallo stesso processo, anche la sua chiave. A causa della fuga di memoria, aggiornare non annulla ciò che è già trapelato. Se il sito mostra già segni che qualcuno è entrato, in sito hackerato spieghiamo cosa fare nella prima ora.
Cronologia
- 20 ottobre: un post su Hacker News pubblica gli identificativi delle CVE prima della fine dell’embargo.
- 21 ottobre, 14:00 UTC: il progetto PHP anticipa la pubblicazione delle patch.
- 21 ottobre: l’NCSC (Regno Unito) e il CERT-EU emettono allerte. Rapid7 avverte che si aspetta sfruttamento e che diversi team lo stanno riproducendo.
- 21 ottobre, 16:30 ora della costa est USA: Huntress riferisce di non aver osservato sfruttamento tra i suoi clienti.
Che il 21 ottobre non si sia visto sfruttamento non dà margine: gli identificativi sono pubblici e ci sono team che stanno riproducendo il difetto.
Gli altri avvisi di quella settimana (Node.js, NGINX, GitLab, Railway, LiteLLM e i certificati di GoDaddy ed eMudhra) sono nel riepilogo delle vulnerabilità di ottobre 2026.
Se preferisci che ce ne occupiamo noi
In Soamee manteniamo applicazioni PHP e server di clienti, e possiamo occuparci di questo aggiornamento per te. Il processo è quello descritto in questo articolo, applicato al tuo caso:
- Inventario: quali siti e server hai, quale versione di PHP e quale SAPI usa ciascuno, e chi controlla ogni server (tu o l’hosting).
- Mitigazione immediata dove l’aggiornamento non si può fare in giornata.
- Aggiornamento alla versione corretta, o piano di migrazione se sei sull’8.1 o precedente, provato prima su una copia.
- Verifica che il sito risponda con la nuova versione e che non restino vecchi processi attivi.
- Revisione degli indicatori di compromissione e rotazione dei segreti se serve.
Nessun aggiornamento garantisce che un server non sia stato compromesso prima della patch; per questo il punto 5 è nella lista. Se vuoi che lo controlliamo, scrivici o chiedi una consulenza gratuita. Se cerchi qualcuno che segua la manutenzione in modo continuativo, guarda i nostri servizi di cloud e DevOps o di sviluppo web.