php2shell dieci giorni dopo: attacchi confermati e una terza falla

Dieci giorni fa la CISA, l'agenzia americana per la sicurezza informatica, scriveva di non aver visto attacchi con php2shell. Il 26 ottobre le due falle, CVE-2026-109618 e CVE-2026-109619, sono entrate nel suo catalogo delle vulnerabilità sfruttate, con tre giorni di tempo agli uffici federali per correggerle (catalogo). Intanto una ventina di firewall sono stati violati, e il progetto PHP ha segnalato una terza falla che le versioni del 21 ottobre non correggono. Cosa fanno le prime due, e come capire se il tuo PHP è a posto, l'abbiamo spiegato nell'articolo del 22 ottobre.

Due annunci ritirati e la prima prova

Sophos, il 22 ottobre, ha parlato di un attacco riuscito in casa di un cliente e la sera stessa ha corretto: erano scansioni e tentativi andati a vuoto. Unit 42, il gruppo di ricerca di Palo Alto Networks, aveva legato a php2shell un'intrusione in un ente governativo europeo, e due giorni dopo ha ritirato l'aggiornamento perché non riusciva a confermare che l'accesso fosse passato da lì.

La prima prova che regge l'ha pubblicata il ricercatore Adel Karimi il 24 ottobre: 35 shell, cioè 35 volte in cui l'attaccante ha potuto dare comandi al server, su tre server esca con PHP 8.4.26 e Apache con mod_php. Karimi stesso avverte che li aveva configurati apposta per facilitare l'attacco, con un solo processo di Apache, e che dopo l'accesso nessuno ha scaricato altro.

Sugli exploit pubblici Sansec aveva visto giusto. Su GitHub ne sono girati centinaia e secondo VulnCheck quelli veri si contano sulle dita. Di funzionanti però ce ne sono: quello di VulnCheck, che resta privato, al 26 ottobre entrava in PHP dalla 8.2.28 alla 8.5.11 con mod_php e le impostazioni predefinite. Wiz, nei sistemi che sorveglia, il 27 non aveva ancora visto un attacco andato a segno dall'inizio alla fine.

Il rumore, intanto, è stato enorme. Cloudflare ha contato migliaia di tentativi già nelle dieci ore prima dell'annuncio, e poi milioni (The Register). Al 26 ottobre però CrowdSec non contava nessuna compromissione pubblica confermata, e nei suoi dati vedeva attaccanti che provavano, non che raccoglievano. Gli hosting si sono mossi in fretta: secondo la cronologia di webhosting.today, SiteGround, Hostinger, GoDaddy, OVHcloud, Hetzner, cPanel e CloudLinux avevano PHP corretto o regole di blocco attive entro il 22 ottobre. Kinsta ha chiuso l'incidente senza prove di violazioni, Hostinger non ha visto più infezioni del solito.

I firewall di Palo Alto

Il primo attacco vero documentato ha colpito dei firewall. Dream Research ha descritto una campagna contro l'interfaccia web con cui si gestiscono i firewall Palo Alto, che sotto gira su PHP 8.0.30. Gli attaccanti agganciavano a php2shell una falla del kernel Linux, CVE-2026-46300, e con una sola richiesta, senza password, diventavano root. Venticinque server presi, fra Stati Uniti, Giappone, Taiwan e Corea del Sud.

Palo Alto ha segnato il suo avviso come «sotto attacco» e ha rilasciato correzioni per tutte le versioni supportate. Secondo Unit 42 l'azienda ha contattato uno per uno i clienti colpiti, circa lo 0,02% dei dispositivi installati: tutti con la gestione del firewall raggiungibile da internet.

PHP 8.0 non riceve correzioni dal 26 novembre 2023, e stava dentro l'apparecchio che dovrebbe proteggere la rete. Firewall, NAS, pannelli di VPN e centralini hanno spesso una pagina web di gestione, e quale PHP ci sia sotto lo sa solo chi li produce. Per questo noi la gestione di questi apparati non la lasceremmo raggiungibile da internet, nemmeno a correzioni installate.

In Italia

I numeri italiani li ha dati l'ACN il 25 ottobre, su dati Censys: 741.523 servizi PHP esposti su internet. Fra quelli di cui si riesce a leggere la versione, 285.149, l'81,9%, ne usano una potenzialmente vulnerabile. L'agenzia mette le mani avanti: nel conto entrano anche i server corretti senza cambiare numero di versione, come fanno CloudLinux, Plesk e cPanel, quindi quelli davvero a rischio sono meno. Tre giorni dopo il suo bollettino ha registrato lo sfruttamento in rete delle due falle.

Aruba dice che sui suoi piani di hosting l'aggiornamento è stato fatto in automatico; su server cloud e dedicati tocca al cliente. Notizie verificate di siti italiani violati con php2shell, al 31 ottobre, non ne abbiamo trovate.

La terza falla, ancora senza correzione

CVE-2026-115560 il progetto PHP l'ha annunciata il 23 ottobre con un avviso a parte. Passa dallo stesso meccanismo della seconda falla, quello che tiene traccia dei caricamenti nelle sessioni, e il progetto la considera un'ipotesi improbabile: serve un'applicazione che cambi il formato delle sessioni mentre gira, con ini_set() prima di session_start(), e quel meccanismo ancora acceso. La correzione arriverà con il prossimo rilascio ordinario; nelle versioni del 21 ottobre non c'è.

Il progetto e l'ACN indicano la stessa misura, session.upload_progress.enabled=0, che era già fra quelle temporanee del 22 ottobre. La funzione che spegne serve solo a mostrare a che punto è il caricamento di un file. Noi la spegneremmo dappertutto, anche dove pensi che l'applicazione non tocchi il formato delle sessioni: con un CMS e qualche decina di plugin, la certezza non ce l'hai.

Cosa controllare adesso

1. 01Chiedi all'hosting una conferma scritta: PHP con le correzioni del 21 ottobre e processi riavviati. Il messaggio da copiare è nell'articolo del 22 ottobre.
2. 02Metti session.upload_progress.enabled=0 nella configurazione del server o del pool di PHP-FPM, perché con ini_set() non vale, e riavvia i processi. Su un hosting condiviso aggiungilo allo stesso messaggio.
3. 03Nei log, dal 17 ottobre in poi, cerca invii di file verso pagine che non hanno moduli, errori di memoria esaurita e processi PHP chiusi all'improvviso.
4. 04Fai l'elenco degli apparati con una pagina web di gestione e verifica che nessuna si raggiunga da internet. Su un firewall Palo Alto installa la correzione indicata nel suo avviso.

Dieci giorni fa scrivevamo che non avremmo aspettato di sapere se aveva ragione Amazon o Sansec. A conti fatti avevano ragione a metà tutti e due: gli exploit pubblici non hanno portato attacchi di massa, quelli privati sono serviti per attacchi mirati. Se vuoi un secondo parere su un server o su un apparato esposto, scrivici.