I developer di PHP hanno accusato la società Chainguard, specializzata nella sicurezza delle catene di approvvigionamento software, di aver rivelato in modo inappropriato bug critici nel linguaggio di scripting open-source, prima di una divulgazione ufficiale pianificata. Mercoledì, poche ore dopo aver rilasciato patch di emergenza per due vulnerabilità note come PHP2shell, i manutentori di PHP hanno pubblicato un blog che descrive come sono stati scoperti e risolti i problemi.
Nel comunicato, hanno attribuito il merito della scoperta delle vulnerabilità ai ricercatori di Calif, OpenAI e Wiz, che hanno utilizzato modelli di intelligenza artificiale per identificare i problemi, ora tracciati come CVE-2026-109618 e CVE-2026-109619. Queste vulnerabilità possono consentire a un attaccante non autenticato di eseguire codice sui server che utilizzano PHP, un fatto preoccupante considerando che PHP alimenta gran parte del web pubblico. Inoltre, il blog solleva una certa ironia riguardo alla “violazione e divulgazione disordinata”, puntando il dito contro Chainguard per la cattiva gestione della situazione.
Secondo i developer di PHP, il problema è iniziato martedì intorno alle 15:00 UTC, quando due ID CVE hanno cominciato a circolare su forum online e social media, accompagnati da informazioni errate riguardo alla data di rilascio e alla gravità delle vulnerabilità. A quel punto, non erano trapelate informazioni tecniche, ma i rumors hanno indotto i manutentori di PHP a promuovere un avviso preventivo sulle vulnerabilità critiche, anticipando la divulgazione di un giorno, dal giovedì al mercoledì.
Il blog della PHP Foundation spiega che i distributori stavano ancora preparando la patch e che una divulgazione immediata avrebbe lasciato molti utenti senza una facile via per aggiornarsi. “Anticipare il rilascio di un giorno è stata la soluzione migliore tra agire rapidamente, dare tempo alle persone di prepararsi e garantire un semplice percorso di aggiornamento quando le vulnerabilità sono state rese note”, si legge nel blog.
Poche ore dopo, Calif ha “erroneamente” pubblicato un video che mostrava un exploit proof-of-concept e “informazioni aggiuntive, sebbene limitate” sui bug. “I consigli per la mitigazione che abbiamo iniziato a fornire a pochi fornitori di infrastrutture critiche il 20 ottobre alle 23:00 UTC potrebbero essere stati divulgati anche”, prosegue il blog della PHP Foundation, senza nominarli esplicitamente. Successivamente, è stata chiaramente citata Chainguard: “Il 21 ottobre alle 07:41 UTC, più di sei ore prima del rilascio coordinato, Chainguard ha unilateralmente infranto l’embargo e pubblicato immagini build contenenti la patch. Come altri distributori, Chainguard aveva ricevuto la patch in anticipo affinché i suoi utenti potessero aggiornare non appena le vulnerabilità venivano divulgate. Qualsiasi attaccante ora poteva studiare la patch in forma binaria mentre gli altri utenti di PHP stavano ancora aspettando il rilascio. Questo ha ignorato settimane di lavoro di molte parti verso una divulgazione coordinata.”
La risposta del CEO di Chainguard
Dan Lorenc, CEO di Chainguard, ha parlato con The Register mercoledì, e pur non contestando la tempistica degli eventi, ha dichiarato che la sua azienda “non ha pubblicato” informazioni riservate. “Queste situazioni sono complicate”, ha affermato Lorenc. Chainguard ha appreso di “qualcosa che stava per accadere in PHP” venerdì da uno dei ricercatori che hanno trovato i bug. Successivamente, utilizzando l’IA della sua azienda e un modello avanzato, lui e il team di Chainguard hanno identificato in modo indipendente le stesse vulnerabilità di corruzione della memoria. Tutto ciò è avvenuto con un “comando di base di ‘trovare vulnerabilità dannose in PHP’”, ha scritto Lorenc in un post su LinkedIn.
Sabato, Chainguard ha iniziato a lavorare con i manutentori di PHP, confermando che alcune delle sue scoperte corrispondevano alle segnalazioni dei bug e assistendo nel test delle patch. “Le patch sono complesse – non si tratta di una semplice vulnerabilità”, ha affermato Lorenc. “Ci è voluto davvero mesi per costruire una patch funzionante. E poi lunedì, sono iniziati i rumors e martedì la situazione è degenerata.” Alcune persone hanno pubblicato prove di concetto sui social media, mentre altri fornitori di sicurezza hanno riferito di aver visto exploit nel mondo reale, e martedì sera Lorenc ha deciso di rilasciare le patch, informando il canale di divulgazione coordinata di PHP riguardo ai suoi piani.
“Le persone venivano colpite in anticipo” rispetto alla divulgazione ufficiale di PHP, ha spiegato Lorenc, “per cui abbiamo deciso di distribuire le patch in questo modo”. Inoltre, martedì sera, Chainguard ha pubblicato artefatti e li ha resi accessibili a chiunque, non solo ai clienti. “E poi mi sono svegliato e ho visto che era tutta colpa nostra”, ha aggiunto Lorenc.
Quando gli è stato chiesto se avrebbe fatto qualcosa di diverso, data la reazione negativa per la divulgazione anticipata di Chainguard, Lorenc ha risposto di no. “Questo processo e questa politica si basano sul tentativo di coordinarsi il più possibile fino a quando non succede qualcosa di grave e le persone iniziano a trasformare queste cose in armi”, ha dichiarato. Lorenc ha finito dicendo: “È frustrante, perché siamo tutti sulla stessa squadra, e ci sono cattivi là fuori che fanno delle cose.”
Le vulnerabilità e il loro potenziale impatto
Sebbene non si conoscano ancora l’entità degli exploit o cosa accadrà ai sistemi legacy vulnerabili che non ricevono le patch di sicurezza, i ricercatori temono che sarà grave. “Un’esploitazione riuscita potrebbe consentire agli attaccanti di prendere il controllo dei server interessati, rubare dati sensibili e defacciare i siti web che li ospitano”, hanno avvertito i ricercatori di Wiz. Essi hanno aggiunto che PHP è utilizzato nel 70% di tutti i siti web nel mondo. “Ogni versione di PHP rilasciata nell’ultimo decennio è affetta da almeno una di queste vulnerabilità, risalendo alla versione 5.4”, hanno scritto i ricercatori di Wiz. “Gli attaccanti possono sfruttarle da remoto, in alcuni casi abbastanza facilmente. Si consiglia di patchare immediatamente.”
Entrambi i bug sono legati al modo in cui PHP gestisce la gestione della memoria e la gestione degli errori, e entrambe le vulnerabilità portano all’esecuzione remota di codice (RCE). Possono causare uno stato interno di PHP corrotto quando una richiesta termina in modo imprevisto, e poi una richiesta successiva può riutilizzare quello stato, portando a una divulgazione di memoria o a RCE. “Entrambi sono vulnerabilità di corruzione della memoria”, ha spiegato il ricercatore di VulnCheck, Patrick Garrity. “Se un attaccante può modellare la memoria di cui PHP si fida, può potenzialmente dirottare ciò che fa successivamente, e in questi casi significa esecuzione remota di codice.”
CVE-2026-109618 porta a RCE tramite corruzione da esaurimento di memoria. “Se una richiesta raggiunge il limite di memoria di PHP nel momento sbagliato, PHP potrebbe lasciare dati interni parzialmente inizializzati e successivamente trattarli come validi, corrompendo la memoria”, ha scritto il manutentore del progetto. “Su Apache con mod_php, una richiesta non autenticata può attivare questo prima che venga eseguito qualsiasi codice dell’applicazione.”
CVE-2026-109619 consente RCE tramite stato obsoleto. “Un errore fatale nel momento sbagliato potrebbe lasciare uno stato interno puntato verso la memoria che apparteneva a una richiesta precedente”, secondo la PGP Foundation. “Una richiesta successiva gestita dallo stesso lavoratore potrebbe quindi utilizzare quella memoria liberata. È stata confermata una condizione di uso-dopo-liberazione e un arresto anomalo del lavoratore, e il reporter ha dimostrato l’esecuzione remota di codice contro un’applicazione reale in esecuzione su Apache con mod_php.”
