Tre siti amministrativi di ICANN sono stati temporaneamente messi offline durante la risposta a due vulnerabilità critiche di PHP. Nell’aggiornamento pubblicato il 22 ottobre, l’organizzazione ha comunicato di avere applicato e testato la patch rilasciata dal progetto PHP e di avere riportato online il sito della Generic Names Supporting Organization (GNSO), quello del programma per i nuovi gTLD 2026 e il sito dedicato al round 2012.
La distinzione operativa è rilevante: ICANN afferma che non risultano sistemi compromessi e precisa che APS, la piattaforma di pubblicazione e consultazione delle domande 2026, e TAMS, il sistema di gestione delle domande, non sono basati su PHP e sono rimasti disponibili. Non si è quindi trattato di un’interruzione del DNS o del processo di registrazione dei domini, ma di una misura preventiva su tre siti web amministrativi esposti a un rischio nel software sottostante.
Leggi anche: Domain security e continuità operativa: il DNS entra nei piani di resilienza
Due vulnerabilità nel motore PHP
Il progetto PHP ha pubblicato gli aggiornamenti il 21 ottobre. Le correzioni riguardano CVE-2026-109618 e CVE-2026-109619, due difetti che, in determinate condizioni, possono consentire a un aggressore non autenticato di eseguire codice sul server. Il primo è legato alla gestione di un errore di memoria esaurita; il secondo a uno stato interno non azzerato correttamente tra richieste gestite dallo stesso processo.
Il rilascio include le versioni corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. L’avviso ufficiale spiega che il rischio riguarda le installazioni PHP che servono richieste web e invita gli operatori a verificare i pacchetti forniti dalla propria distribuzione o dal proprio hosting. Per le versioni fuori supporto, la disponibilità di correzioni dipende dal fornitore: il numero di versione da solo non basta a stabilire se una macchina sia stata aggiornata con un backport.
Le vulnerabilità interessano il livello di esecuzione dell’applicazione, prima che la logica specifica di un sito possa gestire normalmente la richiesta. Questo amplia il perimetro della verifica: non basta chiedersi se il CMS sia aggiornato, occorre sapere quale versione del runtime è installata, come viene servita e se il provider abbia distribuito una correzione. I dettagli tecnici pubblicati dal progetto PHP distinguono inoltre i diversi percorsi di attacco e le relative condizioni, senza che questo implichi che ogni installazione sia stata sfruttata.
Perché ICANN ha scelto la disattivazione temporanea
Quando è uscito l’avviso iniziale, le patch non erano ancora disponibili. ICANN ha quindi sospeso tre siti che utilizzavano PHP e ha mantenuto raggiungibili i sistemi che, secondo l’organizzazione, non dipendevano dal componente vulnerabile. Dopo il rilascio, l’ente ha installato e testato l’aggiornamento, quindi ha ripristinato i servizi. La sequenza documenta una scelta di contenimento e ripristino, non un’ammissione di incidente o di accesso non autorizzato.
Leggi anche: Domain takeover: uno studio analizza la sicurezza dei registrar
Per chi segue il round dei nuovi gTLD, la disponibilità di APS e TAMS ha ridotto l’impatto sui flussi centrali di consultazione e gestione delle candidature. La precisazione conta anche per evitare un equivoco: una pagina del programma offline non equivale automaticamente a una perdita dei dati, a una sospensione delle domande o a un guasto dell’infrastruttura dei nomi. Siti informativi, applicazioni operative e servizi DNS hanno funzioni e dipendenze differenti.
La continuità dipende anche dai fornitori
Il caso rende visibile una dipendenza comune a registri, registrar, marketplace e siti di settore: le applicazioni web poggiano su componenti condivisi, spesso gestiti da team diversi. La risposta richiede inventario delle versioni, canali di aggiornamento del provider, verifica dei sistemi esposti e una decisione chiara su cosa tenere online se la correzione non è ancora applicabile. Il National Cyber Security Centre britannico raccomanda di censire PHP anche sulle macchine più recenti, installare l’aggiornamento corretto e valutare la sospensione temporanea quando non sia possibile ridurre rapidamente il rischio.
Questa dipendenza è particolarmente concreta nel settore dei domini. Portali di registrazione, pannelli di gestione, servizi di assistenza e pagine che pubblicano policy possono essere cruciali per l’operatività dei clienti senza costituire, per questo, il registry o il DNS autoritativo. La distinzione aiuta a stimare l’impatto: si deve chiedere quale servizio è fermo, quali dati o azioni gestisce e quali canali alternativi restano disponibili.
La lettura Webinvest
L’aggiornamento di ICANN è un esempio utile di risposta circoscritta: isolare i siti che dipendono dal componente vulnerabile, preservare i sistemi indipendenti, applicare la correzione e verificare il ripristino. La disponibilità di APS e TAMS ha mantenuto accessibile il nucleo operativo delle candidature, mentre il temporaneo stop dei siti amministrativi ha limitato l’esposizione dichiarata dall’ente.
Per operatori e investitori, la lezione non è che ogni sito PHP sia stato compromesso, né che una versione aggiornata elimini ogni rischio futuro. È che la resilienza di un servizio legato ai domini dipende anche dalla rapidità con cui il suo gestore conosce lo stack tecnico, riceve gli aggiornamenti e comunica quali funzioni restano raggiungibili. Infrastruttura DNS, software applicativo e canali informativi sono livelli diversi, ma l’affidabilità percepita nasce dalla loro gestione coordinata.
Fonte principale: ICANN, aggiornamento del 22 ottobre 2026. Dettagli tecnici e versioni corrette: PHP.net; indicazioni operative: NCSC.
← Tutte le news