PHP2Shell, in Italia 285mila servizi ancora da aggiornare: l'allarme dell'ACN e il formato JPEG XL che Google Immagini non legge

Due falle da 9.2 nel motore che fa girare gran parte del web hanno spento siti pubblici in mezza Europa. L'ACN conta 285.149 servizi PHP italiani ancora esposti e stima che ad aggiornare sia stato il 18%. Intanto Chrome e Firefox accendono JPEG XL, che Google Immagini non indicizza.

26 ottobre 2026 9 min di lettura

81,9%: dei servizi PHP italiani con versione nota è ancora esposto a PHP2Shell: ad aggiornare è stato il 18%

In Olanda il centro nazionale per la cybersicurezza ha spento il proprio sito. In Francia il ministero dell'Interno ha staccato i portali delle prefetture, in Finlandia l'ente di stato Valtori ha chiuso i servizi pubblici online, nel Regno Unito la ministra per la tecnologia Lloyd of Effra ha detto alla Camera dei Lord che «32 servizi governativi non sono disponibili e quattro lo sono parzialmente». In Italia non si è spento quasi nulla, e la fotografia dell'Agenzia per la cybersicurezza nazionale spiega perché la cosa non consola: 285.149 servizi PHP italiani girano ancora su una versione bucata, l'81,9% di quelli che dichiarano il numero di versione, e ad aggiornare è stato circa il 18% dei soggetti interessati.

La falla si chiama PHP2Shell e tocca il motore che esegue il codice di gran parte dei siti del mondo, WordPress, Drupal, Magento e WooCommerce compresi. Nelle stesse ore in cui i sistemisti applicavano le patch, Chrome e Firefox hanno acceso di serie JPEG XL, il formato che secondo il team di Chrome comprime dal 30 al 50% meglio del JPEG, e John Mueller ha avvisato che Google Immagini non lo legge. Chi in Italia tiene in piedi un sito o un negozio online si ritrova con due lavori di manutenzione che di solito non stanno in nessun preventivo: l'interprete che esegue il codice e il formato delle fotografie.

PHP2Shell: due falle da 9.2 e mezza Europa che spegne i siti pubblici

Il 21 ottobre alle 14 UTC la PHP Foundation ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per chiudere CVE-2026-109618 e CVE-2026-109619, valutate 9.2 sulla scala CVSS 4.0. La prima nasce da una corruzione di memoria: se una richiesta tocca il limite di memoria nel momento sbagliato, PHP si ritrova dati interni riempiti a metà e poi li tratta come validi. Su Apache con mod_php l'esecuzione di codice da remoto è stata dimostrata con le impostazioni predefinite e senza autenticarsi.

L'uscita era fissata per il 22 ottobre ed è stata anticipata di un giorno perché il 20 gli identificativi dei due CVE giravano già in rete, e poche ore dopo la società di ricerca Calif ha pubblicato per errore un video con la prova di concetto. Le falle non sono state trovate a mano: Cybersecurity Italia scrive che Calif ha lavorato con il modello GPT-5.6 Sol di OpenAI. La Foundation ammette che il ritardo con cui il problema è stato chiuso «è stato un fallimento strutturale», dovuto al processo decisionale del team di sicurezza e alla mancanza di risorse.

Un tecnico cammina davanti agli armadi di un data center con le spie accese — Le due falle PHP2Shell si chiudono soltanto aggiornando l'interprete sui server: toccare il CMS o i plugin non basta Foto Freepik

Un sistemista lavora sui cavi di rete dentro un armadio rack pieno di server — Le due falle PHP2Shell si chiudono soltanto aggiornando l'interprete sui server: toccare il CMS o i plugin non basta Foto Freepik

Gli attacchi sono partiti prima dell'annuncio. The Register riferisce che AWS ha visto i primi tentativi quattro giorni prima della divulgazione, che Cloudflare ne ha contati a milioni e che il centro nazionale britannico ha spedito 50.000 avvisi. Oltre al Regno Unito hanno oscurato siti pubblici in via precauzionale Germania, Belgio, Francia, Finlandia e Paesi Bassi. Lo stesso giorno, ricorda TechCrunch, Node.js ha chiuso quattro vulnerabilità gravi e il proxy open source LiteLLM è circolato per qualche ora con dentro un ladro di credenziali cloud e un trojan, finiti su PyPI, Docker Hub e GHCR.

Il CERT-AGID ha pubblicato la sua nota il 21 ottobre con una frase che vale per quasi tutti i siti italiani: aggiornare il solo CMS o i relativi plugin non corregge le vulnerabilità dell'interprete PHP. Chiede di riavviare il servizio dopo l'aggiornamento e di cercare nei log i POST anomali e gli errori di memoria esaurita, e segnala il tema Drupal design-comuni-drupal-theme, usato dai siti dei comuni italiani, fino alla versione 1.8.1. La nota tecnica dell'ACN ripresa il 25 ottobre parte dai dati Censys: 741.523 servizi PHP rilevati in Italia, 348.130 con versione identificata, 285.149 potenzialmente vulnerabili. L'agenzia chiede l'aggiornamento immediato, la disattivazione di session.upload_progress.enabled per una terza falla ancora senza patch (CVE-2026-115560) e i WAF in modalità blocco.

Le patch per Debian e Ubuntu le impacchetta un volontario

Le correzioni ufficiali coprono solo i rami da PHP 8.2 a 8.5. Tutto quello che sta sotto, cioè una quota non piccola dei siti italiani fermi a PHP 7.4 o 8.0, dipende da una persona: Ondrej Sury, ingegnere ceco, direttore dell'ingegneria DNS all'Internet Systems Consortium, che da oltre vent'anni trasforma il codice sorgente di PHP nei pacchetti per Debian e Ubuntu distribuiti da packages.sury.org e dal PPA ppa:ondrej/php. Non lavora per il progetto PHP, non è pagato dalla Foundation e manda avanti quel repository con le donazioni.

Uno sviluppatore lavora al codice su un portatile in una stanza buia, di notte — I pacchetti PHP aggiornati per Debian e Ubuntu, quelli che quasi tutti gli hosting installano, li prepara da vent'anni un volontario Foto Freepik

Il 21 ottobre Sury ha pubblicato le build con il backport per PHP 8.1, 8.0, 7.4, 7.3, 7.2, 7.1 e perfino 5.6, ricavate dalla 8.2.35. HeroDevs lo cita così: «avevo le build pronte quando è uscita la release, anche dopo che la data era stata spostata». Rob Nalen, direttore operativo della stessa società, che lo sponsorizza su GitHub Sponsors, riassume il rapporto fra le aziende e il software libero che usano: «il nostro lavoro dipende da quello che fanno loro». Il 23 ottobre, The Atlantic gli ha dedicato un ritratto con il titolo che in questi casi torna sempre: l'uomo che ha salvato internet.

Per un'azienda italiana la conseguenza è pratica. Se il sito gira su un hosting condiviso con PHP 7.4, l'aggiornamento non arriva dal progetto PHP ma da quel repository, e la sua continuità dipende da quante persone decidono di finanziarlo. Il CSIRT della Regione Toscana lo scrive in forma amministrativa nel bollettino del 21 ottobre: per PHP 8.1 e precedenti il fornitore non rilascerà patch né soluzioni alternative. Restano due strade, pagare qualcuno che faccia il backport o portare l'applicazione su un ramo supportato. La Foundation intanto prova a uscire dal modello del volontario eroico: ha creato a maggio un gruppo per la sicurezza dell'ecosistema, ha assunto due sviluppatori fra luglio e settembre e chiede soldi a hosting provider, piattaforme cloud e istituzioni pubbliche.

Chrome e Firefox accendono JPEG XL, ma Google Immagini non lo indicizza

La seconda manutenzione riguarda le immagini e nasce da una notizia che sembra buona. Dopo l'abbandono del 2022 e il ritorno del decoder in Chromium a inizio 2026, Chrome ha attivato JPEG XL di serie con la versione 155 del 6 ottobre e Firefox con la 158 del 13 ottobre. Safari lo legge dal 2023: per la prima volta un formato che comprime meglio del JPEG viene letto dai tre motori principali senza toccare nulla.

I vantaggi li riassume il post di CGI Coffee del 22 ottobre: ricomprimere in JXL un JPEG che già esiste fa risparmiare circa il 20% del peso e permette di ricostruire bit per bit l'originale, quindi un archivio di fotografie si converte senza perdere nulla. Il formato sostituisce anche il PNG e la GIF, gestisce il caricamento progressivo e arriva a 32 bit per canale con l'HDR, dove WebP si ferma a 8.

Un portatile su un tavolo mostra la pagina di un negozio di abbigliamento online con i prezzi — Sulle schede prodotto di un negozio online le fotografie pesano più di tutto il resto: è lì che un formato nuovo si fa sentire Foto Freepik

Il problema sta a valle del browser. Search Engine Journal ha raccolto il 21 ottobre quello che John Mueller, search advocate di Google, aveva scritto su Bluesky il 15: JPEG XL al momento non è supportato nelle immagini di Google e nelle anteprime di Discover. Chi converte tutto e butta i vecchi file perde due canali che per un editore o per un negozio online valgono traffico vero.

La soluzione che indica lo stesso Mueller, rispondendo a Barry Pollard del team Chrome, è vecchia quanto il web responsivo: servire il JXL dentro un elemento picture e lasciare un img di riserva in JPEG, WebP o AVIF, perché «l'elemento picture contiene un elemento img, quindi funziona con qualunque motore di ricerca». Vanno controllati anche il tag og:image e l'immagine dichiarata con schema.org, che Discover usa per l'anteprima: se puntano a un JXL, l'anteprima sparisce. Serve infine che il server mandi il tipo MIME image/jxl, cosa che diversi hosting italiani non fanno ancora.

Cosa cambia in Italia

Per chi gestisce un sito: controllare la versione usata davvero dal web server, non solo quella di php -v, aggiornare ad almeno 8.5.12, 8.4.27, 8.3.36 o 8.2.35 e riavviare Apache o PHP-FPM. Se il sito gira su PHP 7.x servono i pacchetti con il backport.
Per chi vende online: WooCommerce, Magento e PrestaShop girano tutti su PHP. Aggiornare il plugin del carrello o il tema non chiude la falla, e un'esecuzione di codice sul server di un negozio significa carte e anagrafiche dei clienti.
Per chi lavora in agenzia o si occupa di SEO: JPEG XL si può adottare subito, ma dentro un elemento picture con il file di riserva, tenendo JPEG, WebP o AVIF nel tag og:image e nello schema.org.
Per le aziende e la pubblica amministrazione: chi rientra nel perimetro NIS2 del decreto legislativo 138/2024 deve mandare al CSIRT Italia una pre-notifica entro 24 ore da un incidente significativo e la notifica entro 72; con dati personali coinvolti scattano anche le 72 ore verso il Garante privacy.
Per chi compra un servizio di hosting: chiedere al fornitore quando ha applicato la patch e quale ramo di PHP tiene aggiornato. Un hosting che propone ancora PHP 7.4 come scelta predefinita scarica su un volontario un rischio che dovrebbe gestire lui.

Conclusioni: il conto della manutenzione che nessuno mette a preventivo

Il mercato che poggia su questa impalcatura è grosso. L'Osservatorio eCommerce B2c del Politecnico di Milano e di Netcomm stima per il 2026 acquisti online degli italiani sopra i 66,6 miliardi di euro (+6%), di cui 42,6 miliardi di prodotti, con 35 milioni di consumatori digitali. Le imprese che vendono online sono però scese a 87.000, il 4,4% in meno del 2025. Secondo la rilevazione Imprese e ICT dell'Istat il 76,1% delle aziende con almeno dieci addetti ha un sito e solo il 20,1% vende online: dietro quei siti ci sono decine di migliaia di installazioni WordPress affidate a un fornitore esterno e aggiornate quando capita.

Nelle prossime settimane il conto si vedrà su due voci. La prima è il numero dell'ACN: se a un mese dalla patch la quota di servizi aggiornati resta vicina al 18%, l'Italia diventa il posto più comodo d'Europa per chi cerca server aperti. La seconda è contrattuale: molti contratti di manutenzione firmati in Italia coprono il CMS e i plugin, non l'interprete e non il sistema operativo. Questa è la settimana giusta per rileggerli e mettere nero su bianco chi aggiorna che cosa, entro quante ore, e chi paga quando il ramo di PHP non è più supportato.

Sulle immagini invece la fretta non serve. Conviene preparare adesso la catena di produzione, generando i JXL accanto ai formati già usati e tenendo il file di riserva: il giorno in cui Google Immagini aprirà al formato, chi ha gli archivi già convertiti si trova avanti di mesi. Per un negozio italiano con qualche migliaio di schede prodotto, un 20% in meno sul peso delle fotografie vuol dire pagine più rapide sulla rete mobile e meno banda pagata ogni mese: i due numeri che finiscono davvero in bilancio.