Nel 2026 possiamo affidare a un’intelligenza artificiale l’analisi di vulnerabilità che un essere umano impiegherebbe settimane a comprendere, costruire data center grandi come quartieri industriali e discutere seriamente di agenti autonomi capaci di operare senza supervisione continua. Poi, all’improvviso, arriva PHP. Tre lettere che ricordano all’industria tecnologica una verità poco elegante: il futuro dell’informatica poggia spesso su fondamenta che nessuno ha avuto il coraggio, il tempo o il budget di rifare. La notizia delle due vulnerabilità critiche individuate nel linguaggio, secondo le informazioni diffuse il 21 e 22 ottobre, ha riportato questa contraddizione al centro della scena. Il problema non riguarda un vecchio blog dimenticato in un angolo della rete, ma un ecosistema che comprende piattaforme editoriali, servizi pubblici, applicazioni commerciali e infrastrutture digitali sulle quali continua a scorrere una parte considerevole della vita online.

La domanda, dunque, è inevitabile: nel 2026 usiamo ancora PHP? La risposta è sì, e non per una particolare nostalgia dei programmatori degli anni Duemila. PHP è ancora profondamente radicato nell’architettura del web, soprattutto grazie a WordPress e a un patrimonio di applicazioni sviluppate nel corso di decenni. Le stime citate nella copertura della vicenda attribuiscono al linguaggio una presenza in una quota molto ampia dei siti internet, talvolta indicata intorno al 70 per cento, anche se il dato dipende da come si definisce e si misura il suo utilizzo. Il punto non è stabilire se PHP sia moderno secondo i gusti di una conferenza tecnologica. Il punto è che milioni di decisioni architetturali prese nel passato continuano a determinare il livello di sicurezza del presente. Il software, a differenza dei dirigenti aziendali, non va automaticamente in pensione quando raggiunge una certa età. Continua a lavorare, spesso senza ferie e senza che nessuno controlli più se il contratto di manutenzione sia ancora valido.

Le vulnerabilità segnalate, identificate nei resoconti con i codici CVE-2026-109618 e CVE-2026-109619, sono state descritte come problemi critici che possono consentire l’esecuzione di codice da remoto in condizioni vulnerabili. La gravità attribuita alla vicenda è particolarmente significativa perché il difetto avrebbe interessato versioni di PHP risalenti a circa vent’anni fa, comprese release ormai fuori supporto. Secondo le ricostruzioni pubblicate, la combinazione di condizioni tecniche necessarie a sfruttare il problema ne avrebbe reso difficile l’individuazione e l’utilizzo per lungo tempo. La difficoltà, tuttavia, non equivale all’impossibilità: quando un exploit diventa praticabile, la distanza tra una vulnerabilità teorica e un incidente operativo può ridursi drasticamente.

Non siamo semplicemente davanti all’ennesima falla da correggere con una patch e una riunione urgente del reparto IT. Siamo davanti al costo differito delle scelte tecnologiche. Un’azienda può aver risparmiato per anni evitando di migrare un’applicazione, rinviando l’aggiornamento di una dipendenza o mantenendo in funzione un server che nessuno vuole toccare perché, come recita una delle leggi non scritte dell’informatica aziendale, finché funziona non bisogna disturbarlo. Il problema è che funzionare non significa essere sicuro. Significa soltanto che, fino a quel momento, nessuno ha ancora trovato un motivo sufficiente per interromperne il servizio.

Il dettaglio che trasforma l’incidente in una storia industriale, e non soltanto informatica, è la finestra temporale nella quale la vulnerabilità è stata sfruttata. Amazon Threat Intelligence ha riferito di aver rilevato un tentativo di attacco il 17 ottobre 2026, quattro giorni prima della divulgazione pubblica e del rilascio delle correzioni. Dopo la pubblicazione, gli strumenti di rilevamento hanno registrato ulteriori tentativi, mentre le prove di concetto necessarie a riprodurre l’exploit hanno cominciato a circolare rapidamente.

È il consueto vantaggio competitivo del crimine informatico: non deve innovare per creare valore, gli basta individuare il punto in cui qualcun altro ha smesso di investire. Nel frattempo, secondo il CEO di Cloudflare Matthew Prince, citato nella copertura della vicenda, i tentativi osservati sulla rete dell’azienda sarebbero passati da migliaia a centinaia di migliaia, fino a milioni nell’arco di poche ore. Numeri che descrivono la velocità di propagazione di un exploit, non necessariamente altrettante intrusioni riuscite.

La gravità tecnica merita di essere compresa senza trasformare l’analisi in un bollettino apocalittico. Le due vulnerabilità, entrambe valutate 9,2 su 10 nella scala CVSS riportata dagli organismi di sicurezza, riguardano la gestione della memoria durante condizioni di errore. Nel primo caso, un esaurimento della memoria può interrompere l’elaborazione di una richiesta quando alcune strutture interne non sono state inizializzate correttamente; nel secondo, uno stato interno può continuare a riferirsi a memoria già liberata. Sono problemi che appartengono a una categoria insidiosa, perché il comportamento difettoso emerge in condizioni particolari e non necessariamente durante il normale funzionamento dell’applicazione. Un aggressore può costruire richieste HTTP appositamente manipolate per tentare di trasformare queste anomalie in esecuzione di codice remoto, senza autenticazione, prima ancora che l’applicazione esegua la propria logica.

Tradotto per chi gestisce un’impresa: il problema potrebbe trovarsi sotto il livello del sito, prima del login, prima dei controlli applicativi e prima che il software aziendale abbia la possibilità di difendersi.

La conseguenza è che non basta aggiornare WordPress, installare l’ultima estensione di sicurezza o cambiare la password dell’amministratore. Occorre verificare la versione effettiva del runtime PHP, comprese le installazioni incorporate in prodotti di terze parti, container e applicazioni gestite da fornitori esterni. Le versioni corrette indicate negli avvisi tecnici sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le versioni 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP, anche se alcuni fornitori possono distribuire correzioni retroportate nei propri pacchetti.

Quest’ultimo dettaglio è decisivo per le aziende che utilizzano gestionali personalizzati o applicazioni sviluppate quando ancora si discuteva se l’iPhone fosse una moda passeggera. Se il software non può essere aggiornato senza rompersi, la questione non è più soltanto tecnica: diventa una scelta economica tra il costo della migrazione e quello potenziale di un incidente.

Qui il cinismo manageriale trova terreno fertile. Per anni molte organizzazioni hanno trattato la manutenzione del software come una voce da comprimere, mentre destinavano budget ben più generosi ai progetti che potevano essere presentati agli azionisti con una bella slide sull’innovazione. Migrare una piattaforma legacy non produce sempre una dimostrazione spettacolare; spesso significa mesi di lavoro invisibile, test di regressione e riunioni nelle quali nessuno vuole assumersi la responsabilità di interrompere un servizio che genera ricavi. L’intelligenza artificiale, al contrario, offre una narrazione più vendibile: promette produttività, automazione e nuovi mercati. Peccato che un agente intelligente non possa compensare automaticamente un server esposto con una versione di PHP vulnerabile. L’innovazione applicativa poggia su infrastrutture che devono restare governabili; ignorare questo principio significa finanziare il piano industriale del futuro lasciando aperta la porta sul retro del presente.

C’è poi un aspetto che rende questa vicenda particolarmente interessante nel 2026: il ruolo dell’intelligenza artificiale nella ricerca delle vulnerabilità. Secondo le informazioni pubblicate, strumenti basati su modelli avanzati hanno contribuito a individuare e analizzare difetti difficili da scoprire con i metodi tradizionali. Google Cloud ha attribuito un contributo significativo a Gemini 4 Argon nel lavoro di identificazione, sviluppo degli exploit, rilevamento degli attacchi e validazione delle correzioni, mentre la copertura giornalistica ha riportato anche il coinvolgimento di altri modelli e ricercatori.

Questo non significa che l’IA abbia improvvisamente imparato a violare qualsiasi sistema, né che ogni vulnerabilità scoperta da un modello possa essere sfruttata con successo. Significa, piuttosto, che la barriera cognitiva per analizzare software complesso potrebbe abbassarsi. La stessa tecnologia può aiutare i difensori a individuare un difetto prima della pubblicazione oppure permettere agli attaccanti di trasformare più rapidamente un risultato tecnico in uno strumento operativo. La corsa alla sicurezza diventa così più veloce, ma non necessariamente più rassicurante.

Gli effetti si sono già estesi oltre il mondo dei siti commerciali. Le notizie hanno segnalato interruzioni temporanee che hanno coinvolto servizi come Internet Archive e piattaforme molto diverse tra loro; alcune organizzazioni hanno preferito sospendere l’accesso pubblico ai sistemi esposti fino all’applicazione delle misure correttive. Le autorità europee, attraverso una comunicazione congiunta che coinvolge Commissione europea, ENISA, CERT-EU, Europol e le reti nazionali di risposta agli incidenti, hanno raccomandato interventi immediati.

Il caso dei servizi storici è particolarmente amaro. Un vecchio gioco online può sembrare un oggetto trascurabile agli occhi di chi misura il valore in ricavi trimestrali, ma rappresenta anche una porzione di memoria digitale. Quando un servizio non più mantenuto deve chiudere perché il suo ambiente software non può essere aggiornato in sicurezza, non perdiamo soltanto una funzione: perdiamo un frammento di storia della rete. Il progresso tecnologico, a quanto pare, conserva la memoria soltanto quando qualcuno paga per farlo.

Per le imprese, la lezione non consiste nel dichiarare guerra a PHP. Il linguaggio continua a essere uno strumento legittimo, supportato e utilizzabile in contesti produttivi; la sua età, da sola, non lo rende insicuro. La differenza la fanno il ciclo di aggiornamento, la qualità della gestione operativa e la capacità di sapere esattamente quali componenti siano presenti nell’infrastruttura. Un’applicazione PHP aggiornata, monitorata e mantenuta può essere una scelta ragionevole. Un’applicazione costruita su una versione abbandonata, della quale nessuno conosce più le dipendenze, è invece una passività che il bilancio spesso non mostra. Il CTO dovrebbe quindi pretendere un inventario verificabile dei sistemi esposti, una prova dell’avvenuta correzione e un controllo dei log per individuare eventuali segnali di compromissione precedenti all’aggiornamento. Se la correzione immediata non è possibile, l’isolamento temporaneo del servizio può essere necessario, come indicano le raccomandazioni delle autorità di sicurezza.

Resta la domanda iniziale, con tutta la sua ironia: nel 2026 usiamo ancora PHP? Certamente. Il vero scandalo non è che un linguaggio nato decenni fa continui a far funzionare una parte importante del web. È che alcune organizzazioni scoprano soltanto durante una crisi quanto dipendano da software che non hanno più la capacità di aggiornare. Possiamo chiamare questa situazione debito tecnico, legacy o rischio operativo; il nome cambia poco quando un servizio deve andare offline. Nel frattempo, mentre il settore celebra agenti autonomi e modelli sempre più potenti, tre lettere continuano a ricordarci che la modernità digitale non si misura dal linguaggio utilizzato nell’ultima presentazione aziendale, ma dalla capacità di mantenere sicuro ciò che esiste già. Il futuro può anche essere scritto dall’intelligenza artificiale. Il conto, però, arriva ancora al reparto IT.