OpenAI propone cinque fasi per coordinare la risposta alle falle PHP

OpenAI ha pubblicato il 21 ottobre 2026 una proposta in cinque fasi per coordinare la risposta a vulnerabilità critiche, presentandola nel resoconto del caso PHP. Il piano descrive come coinvolgere manutentori, organizzazioni interessate, fornitori e governi, e quando rivalutare i tempi della divulgazione. Resta una proposta, non uno standard adottato. OpenAI ha riferito che Calif ha individuato una falla con GPT-5.6 Sol e che Wiz ha scoperto autonomamente entrambe; i manutentori di PHP hanno guidato le correzioni.

PHP è un linguaggio di programmazione open source che viene eseguito sui server per gestire siti e applicazioni web. Le due falle riguardavano quindi installazioni di PHP che ricevevano richieste web. NeoTeo ha già spiegato quali versioni PHP correggono le vulnerabilità; qui l’attenzione è sulle regole di coordinamento proposte da OpenAI e su ciò che gli amministratori possono fare.

Le cinque fasi del piano OpenAI

La sequenza parte dalla correzione del software e arriva alle istruzioni pubbliche per applicare la patch. OpenAI propone che manutentori, ricercatori e partner tecnici verifichino l’impatto, sviluppino la correzione e la mettano alla prova, anche cercando varianti che possano aggirarla. Poi, con i manutentori alla guida delle decisioni, le organizzazioni interessate ricevono il tempo e le informazioni necessari a prepararsi: i distributori possono adattare le correzioni ai rami più vecchi, gli hosting provider preparare mitigazioni e i fornitori di sicurezza predisporre sistemi di rilevamento o blocco.

La terza fase prevede il coordinamento con le autorità, così che le indicazioni raggiungano anche le infrastrutture critiche e i servizi essenziali. Nel caso PHP, OpenAI afferma di aver coinvolto partner governativi statunitensi, tra cui CISA, l’Office of the National Cyber Director e la White House Super Intelligence Force, oltre a partner internazionali. La quarta fase consiste nel preparare gli aggiornamenti per prodotti e servizi che dipendono dal software interessato. La quinta comincia quando esiste una patch: pubblicare istruzioni per individuare i sistemi esposti, reperire gli aggiornamenti o le mitigazioni e controllare che la correzione sia in funzione.

Quando il calendario può cambiare

Nel modello proposto, ogni partecipante dovrebbe ricevere le informazioni necessarie al proprio compito difensivo. OpenAI osserva che anche dettagli limitati possono rivelare una vulnerabilità; il rischio della condivisione va quindi bilanciato con la protezione che consente di preparare.

Il calendario andrebbe rivalutato se iniziasse lo sfruttamento attivo, se le informazioni trapelassero, se una patch pubblica rivelasse la falla o se i ritardi nella correzione aumentassero il rischio per gli utenti. OpenAI chiede inoltre alla comunità di discutere quanto debbano durare le finestre di divulgazione, quando convengano le notifiche graduali e quali garanzie servano per eventuali interventi di emergenza. Sono temi sottoposti al confronto, non regole già definite dal piano.

Le vulnerabilità PHP e le versioni corrette

PHP ha descritto entrambe le falle come vulnerabilità di esecuzione di codice da remoto senza autenticazione e ha assegnato a ciascuna un punteggio CVSS v4.0 di 9,2. CVE-2026-109618 riguarda un errore nella gestione dell’esaurimento della memoria: PHP può interrompersi mentre alcuni dati della richiesta sono inizializzati solo in parte, e la procedura di pulizia può poi trattarli come validi. CVE-2026-109619 riguarda invece uno stato interno della richiesta che può restare in memoria dopo che la memoria che lo sosteneva è stata liberata; una richiesta successiva gestita dallo stesso processo di lavoro può riutilizzarlo prima che venga reimpostato.

PHP ha pubblicato queste versioni corrette:

Per PHP 8.1 e i rami precedenti il progetto non rilascia più aggiornamenti ordinari. PHP ha reso disponibili correzioni minime del codice sorgente per 7.4, 8.0 e 8.1; alcuni distributori Linux e fornitori con supporto a lungo termine possono offrire pacchetti con correzioni retroportate. PHP invita gli amministratori a informarsi presso il proprio fornitore.

Cosa possono fare le mitigazioni temporanee

PHP indica l’aggiornamento a una delle versioni corrette come soluzione completa. Le misure provvisorie riducono l’esposizione a percorsi specifici, ma non rendono sicura un’installazione. L’avviso ufficiale PHP dettaglia le configurazioni pertinenti:

• Per CVE-2026-109618, PHP consiglia memory_limit=-1, configurato in modo che le impostazioni dell’applicazione non reintroducano un limite finito. Per le richieste, raccomanda di limitare post_max_size a 8M se non servono caricamenti di file oppure a 32M se sono necessari; upload_max_filesize deve restare inferiore a post_max_size.
• Per CVE-2026-109619, PHP indica di impostare session.upload_progress.enabled=0 prima dell’analisi delle richieste e di riavviare tutti i processi di lavoro. La misura blocca i percorsi di sessione confermati, non ogni possibile variante.
• Su PHP 8.5, fatal_error_backtraces=0 blocca il percorso confermato legato alle tracce degli errori fatali.

Le configurazioni possono dipendere dall’ambiente server e dall’applicazione: le mitigazioni non sostituiscono l’aggiornamento alle versioni corrette.