Cybersicurezza

PHP2Shell, quando una vulnerabilità del software diventa un’emergenza mondiale

Sono state rivelate per errore due vulnerabilità presenti nel motore della maggior parte dei siti Internet del Pianeta e questo ha scatenato, letteralmente, il panico. Ecco cosa è accaduto

6' di lettura

English Version

6' di lettura

English Version

La cronaca delle ultime ore ci dice che alcuni siti istituzionali europei sono stati messi offline per precauzione. A spingere i responsabili a sospendere i servizi è stata la scoperta di due gravi falle di sicurezza in PHP, un linguaggio di programmazione utilizzato da una parte enorme del web. Ieri, infatti, sono state rivelate per errore due vulnerabilità presenti nel motore della maggior parte dei siti Internet del Pianeta e questo ha scatenato, letteralmente, il panico tra i gestori dei reparti informatici delle aziende.

Domande di approfondimento generate da 24Ore AI

Cosa è Php2Shell?

La vulnerabilità, conosciuta come PhP2Shell, si compone di due diverse falle (a cui sono stati dai i codici CVE-2026-109618 e CVE-2026-109619) che combinate permettono ai malintenzionati di prendere il controllo di molti server esposti sul Web, dandogli libero accesso ai dati e ai file presenti. Questo vuol dire che i criminali possono bloccare i servizi Internet e rubare i dati custoditi. In realtà, si stima che “solo” il 70% siti del Web usino PHP come motore e, tra questi, non tutti sono vulnerabili. Resta il fatto che sembri che almeno la metà sia attaccabile con successo e che chi non lo è ancora non è certo di essere al sicuro e, quindi, sta lavorando alacremente per capire che contromisure adottare e riattivare i servizi che (spesso) sono stati spenti. Tra i siti che si sono fermati troviamo quello della BBC, diversi siti del governo finlandese, il sito dell’agenzia per la cybersecurity dei Paesi Bassi e così via. Gli utenti consumatori, dal loro punto di vista, non possono fare nulla che attendere, ma la situazione, ormai, è in via di normalizzazione in quanto il 21 ottobre il progetto PHP ha pubblicato aggiornamenti straordinari per le versioni ancora supportate. La gravità della situazione ha portato anche a una presa di posizione congiunta della Commissione Europea, di ENISA, CERT-EU, Europol e della rete europea dei CSIRT, che hanno invitato le organizzazioni a intervenire immediatamente, dando priorità ai sistemi esposti su Internet. E mentre la polvere si posa, diventa evidente che in questa vicenda ci sono molti tasselli da mettere a posto e molte lezioni da imparare.

Loading...

Partiamo dalle vulnerabilità

Un aspetto molto interessante di tutta questa emergenza è che le avvisaglie risalgono a due anni fa. Il problema alla base di CVE-2026-109618 , infatti,era già emerso nel 2024, durante una verifica esterna della sicurezza del motore PHP. All’epoca, tuttavia, il team di sviluppo di PHP non era riuscito a individuare una soluzione soddisfacente. Il difetto riguardava una parte particolarmente delicata del funzionamento interno del linguaggio e le possibili correzioni presentavano conseguenze difficili da valutare: incompatibilità con il software esistente, nuovi rischi di denial of service e potenziali problemi per le numerose estensioni sviluppate da terze parti. Una cosa che accade spesso con i software usatissimi come PHP e che reggono le sorti di aziende, istituzioni e servizi più o meno indispensabili. Mancava inoltre una dimostrazione convincente che il problema potesse essere sfruttato per ottenere l’esecuzione di codice da remoto. Si sapeva che c’era un problema, ma non si era sicuri che fosse davvero sfruttabile per scopi illegali. Si scelse di aspettare: una mossa che nell’informatica moderna è quasi sempre foriera di grossi guai. E i guai arrivarono sotto forma di sistemi AI di aiuto alla cybersecurity: con il lancio di Mythos da parte di Anthropic, iniziarono ad arrivare segnalazioni inquietanti che mostravano come la vulnerabilità lasciata dormiente fosse davvero un potenziale pericolo. La PHP Foundation iniziò a intensificare gli sforzi anche sfruttando strumenti di IA e la consulenza di aziende specializzate in cybersecurity, ma il compito restava complesso.

La svolta avviene l’11 agosto 2026: qualcuno trova un sistema per violare i server.

Ad agosto, Ryan A, ricercatore della società di sicurezza Calif, segnala al progetto PHP una possibilità di esecuzione arbitraria di codice riconducibile alla stessa causa del problema di gestione della memoria identificato nel 2024. Nella stessa giornata, la stessa segnalazione giunge indipendentemente da OpenAI, confermando la stessa causa originale. A seguire, arrivarono ulteriori risultati da parte di Wiz, il 24 agosto, e nuovi vettori di attacco individuati da OpenAI il 18 settembre.

A questo punto, secondo quando ha dichiarato la PHP Foundation, la correzione del problema è diventata l’attività principale del team di sicurezza, con sviluppatori impegnati anche durante i fine settimana e nelle ore notturne.

La disclosure doveva essere coordinata. Ma è andato tutto a rotoli.

Una volta confermata la gravità delle vulnerabilità, il progetto PHP ha organizzato una procedura di notifica coordinata della vulnerabilità, ovvero coinvolgere ricercatori, distributori software, provider cloud e società di sicurezza perché tutti tenessero segrato il problema fino a quando non sarebbe stata pronta una contromisura, in modo da evitare di dare ai criminali uno strumento praticamente “inarrestabile” per violare i siti Internet. La pubblicazione della contromisura era inizialmente prevista per il 22 ottobre alle 14:00 UTC, ma il piano inizia a scricchiolare il 20 ottobre, intorno alle 15:00 UTC, quando i due identificativi CVE iniziano a circolare su forum e social network. Le informazioni diffuse riportano un punteggio CVSS di 10,0 (errato, il punteggio assegnato era 9.2 per entrambe) e un orario di pubblicazione errato. Non contengono ancora dettagli tecnici sufficienti a spiegare lo sfruttamento delle falle, ma allertano la comunità dei criminali che non riesce a credere che stia per esser rilasciata una vulnerabilità così potente. Il progetto PHP decide di anticipare l’annuncio pubblico, che viene diffuso alle 19:30 UTC, e di spostare il rilascio delle patch al 21 ottobre. La scelta di non pubblicare immediatamente gli aggiornamenti ha una ragione operativa: i distributori stanno ancora preparando i pacchetti correttivi. Rilasciare i dettagli senza offrire contemporaneamente una soluzione per mettere in sicurezza i sistemi avrebbe rischiato di fare un enorme favore ai criminali.

Ed ecco che la situazione precipita: un video viene pubblicato per errore

La situazione peggiora poche ore dopo l’annucio. Intorno alle 20:00 UTC del 20 ottobre, Calif pubblica erroneamente un video che mostra il funzionamento di un proof of concept, ossia una dimostrazione pratica dello sfruttamento delle vulnerabilità. Il video viene rimosso, ma alcune copie restano disponibili online e iniziano a circolare. Secondo la PHP Foundation, da quel momento iniziano i tentativi di sfruttamento delle vulnerabilità (che non sono ancora pienamente documentate, ma i criminali iniziano a provarci) e il team di sicurezza segue le dimostrazioni pubblicate nelle ore successive, senza tuttavia individuare exploit funzionanti tra quelli esaminati prima della disclosure ufficiale.

E tutto diventa di pubblico dominio

E dopo le maldestre operazioni di Calif che hanno dato qualche indizio ai criminali, arriva l’episodio più controverso avviene la mattina del 21 ottobre, alle 09:41. Secondo la ricostruzione della PHP Foundation, Chainguard (un’altra azienda specializzata) pubblica immagini container che contengono già le correzioni, oltre sei ore prima del rilascio coordinato. Chainguard aveva ricevuto le patch in anticipo, come altri distributori, per consentire ai propri clienti di aggiornare tempestivamente i sistemi. La loro pubblicazione anticipata, però, rende possibile analizzare le differenze tra il codice vulnerabile e quello corretto, aprendo il vaso di Pandora e mostrando come sfruttare le falle. La PHP Foundation ha accusato esplicitamente Chainguard di aver violato unilateralmente l’embargo, compromettendo settimane di coordinamento, ma ormai la frittata è fatta. Il 21 ottobre, intorno alle 15:40, vengono infine rilasciate le versioni corrette di PHP e pubblicati i dettagli delle vulnerabilità.

Perché PHP2Shell rappresenta un rischio così esteso

PHP è alla base di una parte considerevole dei siti Web e delle applicazioni aziendali. Viene utilizzato da piattaforme come WordPress, Drupal e Joomla, ma anche da gestionali, portali di commercio elettronico, applicazioni sviluppate internamente e numerosi servizi forniti da terze parti. Secondo le analisi di Wiz, le vulnerabilità interessano codice presente in versioni PHP risalenti a oltre un decennio fa, e almeno una delle falle riguarda release fino alla famiglia PHP 5.4. Il fatto che siano così vecchie e siano state notate solo ora è una conseguenza dell’arrivo dell’AI nella gestione della cybersecurity: le AI sono molto più brave degli esseri umani a cercare falle, soprattutto in progetti mastodontici come questo. Purtroppo, lo sforzo necessario a chiuderle è ancora fin troppo “umano” e se il problema è complesso possono passare diversi mesi prima di arrivare a una conclusione. Stavolta, il piano di divulgazione è andato in pezzi poche ore prima della sua naturale conclusione e le conseguenze sono modeste, anche se ci sono molti report al momento di tentativi di sfruttamento di questa vulnerabilità. Ma se non si trova un sistema migliore e più affidabile di gestire la segretezza di questi problemi, un giorno potremmo ritrovarci tutti in guai grossi, senza poter fare nulla per rimediare.

Riproduzione riservata ©

Brand connect

Loading...

Newsletter

Notizie e approfondimenti sugli avvenimenti politici, economici e finanziari.

Iscriviti