PHP2Shell, due falle critiche in PHP sfruttate: 382 siti della PA ancora da verificare

Le due vulnerabilità di PHP note come PHP2Shell, CVE-2026-109618 e CVE-2026-109619, permettono di eseguire codice sul server senza autenticazione e dal 26 ottobre 2026 sono nel catalogo CISA delle falle sfruttate. Le patch sono uscite il 21 ottobre alle 16:00 italiane: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. In Italia il CERT-AGID ha contato, al 29 ottobre, 382 indirizzi della pubblica amministrazione che dichiarano ancora una versione potenzialmente vulnerabile.

Le due falle e le versioni da installare

La CVE-2026-109618 riguarda la gestione degli errori di memoria esaurita: PHP interrompe l’elaborazione quando la memoria della richiesta è ancora parzialmente inizializzata e la pulizia successiva la tratta come valida. La CVE-2026-109619 nasce da uno stato interno che sopravvive alla liberazione della memoria e può essere riusato dalla richiesta successiva servita dallo stesso processo. Il team PHP considera più a rischio Apache con mod_php, dove esiste un exploit dimostrato che parte prima ancora che venga eseguito il codice dell’applicazione.

Su Debian, Ubuntu e Red Hat le correzioni arrivano spesso come backport, senza cambiare il numero di versione: un server che mostra ancora “8.2.x” può essere già sistemato, e viceversa. Conta il changelog del pacchetto, non il numero.

Sfruttamento: quanto è reale

Il quadro va letto con cautela, perché le fonti non coincidono. CISA ha inserito entrambe le CVE nel catalogo KEV il 26 ottobre. Secondo BleepingComputer, Amazon Threat Intelligence ha visto tentativi già quattro giorni prima delle patch, e Adel Karimi di Perplexity ha documentato su un honeypot l’esecuzione di codice contro Apache con mod_php e PHP 8.4.26. Wiz, invece, scrive di non aver ancora osservato nella propria telemetria uno sfruttamento completo riuscito: gli exploit pubblici si fermano spesso a metà catena, perché dipendono da build, limiti di memoria e configurazione dei processi. La stessa Wiz misura un calo di circa il 67% delle macchine esposte vulnerabili nei giorni successivi alla divulgazione.

Il 23 ottobre PHP ha segnalato anche una terza via d’attacco nelle sessioni, la CVE-2026-115560, che richiede una combinazione di configurazione insolita; la correzione arriverà con il prossimo rilascio regolare e la mitigazione è la stessa indicata per la 109619.

La situazione nella pubblica amministrazione

Il CERT-AGID ha controllato in modo passivo, leggendo solo la versione dichiarata dai server, i 22.371 indirizzi web censiti nell’Indice delle Pubbliche Amministrazioni. Nella prima rilevazione del 22 ottobre risultavano potenzialmente vulnerabili 650 indirizzi, il 3,2% di quelli raggiungibili. Il 29 ottobre erano 382, pari all’1,7%, e 215 delle URL inizialmente segnalate dichiaravano una versione aggiornata. L’agenzia avverte che un indirizzo uscito dalla lista non è per forza sistemato: alcuni hanno solo smesso di mostrare la versione. AgID ha pubblicato su GitHub, nel repository AgID/PHP2Shell (ramo beta), gli script usati sui propri server Ubuntu e in parte Fedora per verificare, aggiornare e applicare mitigazioni.

Cosa fare subito

1. Fate l’inventario di tutto il PHP che gira: server web, pannelli di hosting, appliance, immagini Docker e applicazioni che lo includono.
2. Controllate versione e changelog del pacchetto. I comandi sotto valgono per Debian/Ubuntu (sostituite il nome del pacchetto, per esempio php8.3-common) e per le distribuzioni basate su RPM.
3. Aggiornate partendo dai server raggiungibili da Internet e riavviate tutti i processi PHP (FPM o Apache).
4. Se non potete aggiornare subito, applicate le mitigazioni temporanee indicate da php.net; secondo CISA un WAF può offrire una protezione parziale nel frattempo. Chi usa ancora PHP 8.1 o precedenti, avverte CISA, dovrebbe togliere i sistemi dalla rete finché non sono aggiornati.
5. Cercate nei log processi PHP che avviano shell o scaricano strumenti; CISA ha pubblicato una regola SIGMA per questo controllo.
6. Gli enti pubblici possono usare gli script AgID, provandoli prima in un ambiente di replica come raccomanda il CERT-AGID.

php -v
apt changelog PACCHETTO_PHP | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

Le mitigazioni di php.net vanno impostate dove l’applicazione non può sovrascriverle, per esempio nel pool di PHP-FPM, e richiedono il riavvio di tutti i processi. Togliere il limite di memoria elimina il percorso d’attacco controllabile ma espone il server all’esaurimento della RAM: php.net suggerisce di affiancare un limite a livello di container o cgroup e sconsiglia RLIMIT_AS e RLIMIT_DATA.

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

Se servono upload più grandi, php.net indica post_max_size = 32M, sempre con upload_max_filesize più basso. Su PHP 8.5 va aggiunto anche fatal_error_backtraces=0.

La nostra lettura

Il calo da 650 a 382 indirizzi in una settimana è un buon segnale, ma l’1,7% della PA con una versione dichiarata vulnerabile, otto giorni dopo una patch critica, resta troppo. Il dato del CERT-AGID copre poi solo gli indirizzi principali censiti in IPA, non sottodomini e servizi dei fornitori. Il fatto che gli exploit pubblici funzionino male non è una garanzia: è solo il tempo che gli attaccanti impiegano a renderli affidabili. Altre allerte della sezione sono in https://hardwarfare.it/category/sicurezza-informatica/vulnerabilita-patch/.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo