Le quattordici, e i siti già al buio
L'appuntamento era preciso, e non è così che di solito si annunciano le emergenze. Mercoledì 21 ottobre 2026, alle 14:00 UTC, PHP avrebbe rilasciato un aggiornamento di sicurezza per due vulnerabilità critiche. L'ora era stata pubblicata sulla stessa lista announce del linguaggio, ripresa dai ricercatori, annotata in un post di Dane Knecht e ripetuta dai giornali che dicevano agli amministratori di tenersi pronti. Huntress, in una nota di risposta rapida, ha descritto falle critiche trapelate e le ha numerate: CVE-2026-109618 e CVE-2026-109619. PC Gamer, giornale di riferimento improbabile per una crisi di un runtime, ha detto agli amministratori web di resistere, e di aspettarsi aggiornamenti d'emergenza capaci di tappare exploit trapelati.
Quando quell'ora è arrivata, una parte del web aveva già scelto il buio. Diversi siti importanti erano stati messi offline a causa di una vulnerabilità critica in PHP. La BBC ha riferito di siti tirati giù in tutto il mondo mentre veniva emesso l'aggiornamento di cyber-security. Non sono proprio la stessa affermazione del consiglio che viaggiava insieme a loro, e la differenza vale la pena di tenerla. Le autorità di U.S., Europe e Britain hanno raccomandato che i siti andassero temporaneamente offline finché non si fosse potuti intervenire. Una raccomandazione non è un'interruzione. Un'interruzione, nel racconto del Brussels Times e in quello della BBC, era già il fatto riportato della giornata: siti messi offline tra i timori di sicurezza, siti tirati giù mentre usciva l'aggiornamento. Da fuori, il quadro era una patch con un appuntamento, e un web che aveva cominciato a spegnersi prima che si potesse dire che i pacchetti fossero arrivati.
In Japan l'oscuramento aveva dei nomi. Gigazine ha riferito che NicoNico, pixiv e vari altri siti e app erano entrati in manutenzione per far fronte alla patch d'emergenza. ITmedia ha registrato manutenzione d'emergenza su CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server e つなぐ. Niente, in quegli avvisi, sul materiale che abbiamo, è la confessione che un intruso fosse già dentro. Si leggono come un giudizio: essere raggiungibili, nelle ore intorno alla correzione, era diventato lo stato più rischioso. Il security team di PHP aveva avvertito gli amministratori il giorno prima di prepararsi ad aggiornamenti d'emergenza per due vulnerabilità critiche. Il team ha annunciato la scoperta di due falle gravi, e le patch erano fissate per il 21 ottobre. I maintainer le avevano pianificate per vulnerabilità con un indice di gravità di 9,2 su 10.
Quando i pacchetti sono stati pubblicati, avevano delle versioni. PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 correggono due vulnerabilità critiche che possono consentire l'esecuzione remota di codice senza autenticazione. Il National Cyber Security Centre e la BBC hanno inquadrato l'aggiornamento nei termini più ampi a disposizione: un problema critico che può consentire agli attaccanti di eseguire comandi su qualunque web server che esegue PHP. L'episodio aveva già un nome, PHP2Shell, e il nome faceva il lavoro di un titolo. Lo ha usato Watchtowr. Lo ha usato Huntress. Amazon lo ha usato per un tentativo di sfruttamento. Wiz lo ha usato per una scoperta di ricerca nel cuore del linguaggio.
La storia pubblica era un rilascio controllato a un'ora pubblicata. La storia della telemetria era un tentativo che non ha aspettato l'annuncio.
Amazon Threat Intelligence ha identificato un tentativo di sfruttamento di PHP2Shell nella telemetria MadPot datato al 17 ottobre 2026, quattro giorni prima della disclosure pubblica di quei due CVE. Tra la lista announce e quella telemetria sta il disagio della settimana. Chi è responsabile del linguaggio aveva messo un orologio. Non era l'unico a girare.
Due vie d'ingresso, e un disaccordo su quanto sia ampio
Le vulnerabilità, come le ha identificate l'archivio news di PHP, non sono un bug descritto due volte. CVE-2026-109618 è esecuzione remota di codice via corruzione da out-of-memory. CVE-2026-109619 è esecuzione remota di codice via stato globale stale. L'impatto confermato, nel resoconto che ha esaminato il problema di out-of-memory, è l'esecuzione remota di codice senza autenticazione come account del web worker. Quell'ultima clausola fa un lavoro silenzioso. Non è un'affermazione, con fonte, di possesso totale di una macchina. È l'affermazione che il codice gira, senza login, come l'account che il web server usa già per fare il suo lavoro. Per moltissimi siti, quell'account è il lavoro.
La falla dello stato stale ha una forma che si può dire senza trasformarla in una procedura. PHP contiene vari stati globali — errore, sessione, oggetto ed estensione — che un worker trattiene ma che puntano a memoria di proprietà di una sola richiesta. Un worker, in questo assetto, sopravvive alla richiesta che lo ha riempito. La memoria no. Quello che la vulnerabilità fa di quello scarto è, nei termini dell'archivio, esecuzione remota di codice. L'altra falla arriva a una destinazione simile per la via indicata come corruzione da out-of-memory. Due meccanismi, una sola classe di esito, e un unico rilascio d'emergenza costruito per chiuderli entrambi.
Il rischio, ha detto l'archivio, è massimo per mod_php, con un exploit dimostrato in cui una richiesta non autenticata può innescare l'attacco prima che giri qualunque codice applicativo. È la frase che un operatore legge due volte. Una falla che aspetta un angolo preciso di un'applicazione si può triagiare. Una falla raggiungibile da una richiesta non autenticata, prima che l'applicazione abbia modo di stare attenta, è un'altra coda. È per questo che un indice di 9,2 su 10, che Ars Technica ha riportato come rating delle due vulnerabilità che i maintainer stavano per patchare, non sta sulla pagina come decorazione. È per questo che il messaggio del security team era di prepararsi ad aggiornamenti d'emergenza per l'indomani, non di trovare una finestra comoda.
C'è una differenza reale su quanto le fonti spingano il raggio del danno, e va nominata, non lisciata.
Da una parte, la BBC e il National Cyber Security Centre hanno inquadrato l'aggiornamento come risposta a un problema critico che può consentire agli attaccanti di eseguire comandi su qualunque web server che esegue PHP. «Any» è una parola grande. È la parola che trasforma un bug di runtime in qualcosa di più vicino a una contingenza civile. Dall'altra, l'archivio del linguaggio è stato più specifico su dove stesse il pericolo dimostrato: massimo per mod_php, e raggiungibile, in quel caso dimostrato, prima che giri il codice applicativo. Non sono sinonimi educati. Un lettore può tenere entrambi — un ampio avvertimento ufficiale sui server che eseguono PHP, e un'affermazione tecnica più stretta su dove il rischio è stato mostrato al massimo — senza fingere che dicano la stessa cosa. L'impatto confermato resta l'esecuzione remota di codice senza autenticazione come account del web worker. Quanto quella conferma viaggi, oltre la configurazione in cui è stata dimostrata, è l'argomento che gli advisory della giornata non si sono fermati a chiudere. Hanno patchato, e hanno detto alla gente di valutare di andare offline mentre lo facevano.
La questione delle versioni ha un bordo simile, non finito. Si ritiene che le vulnerabilità colpiscano PHP 5, 6, 7 e 8 — si ritiene, non confermato in ogni riga con cerimonia, e la convinzione la portano Watchtowr, BleepingComputer, la nota di security-release di PHP e Huntress. Le versioni indicate come correzione delle due falle critiche sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le fonti raccolte qui non tracciano una mappa completa di ciò che, il 21 ottobre, fosse disponibile per ogni linea più vecchia che i ricercatori ritengono colpita. Quello che tracciano è un buco nella carta: una convinzione sulla portata che risale attraverso 5, 6 e 7, e un elenco di fix che, nell'archivio e nella nota di rilascio, è un elenco di point release 8.x. Per un amministratore su un 8.2, 8.3, 8.4 o 8.5 corrente, l'istruzione era concreta. Per chi è ancora più indietro, il pubblico verbale di questo episodio è un avvertimento senza, in queste fonti, un numero di versione corrispondente.
Wiz Research ha scoperto più vulnerabilità critiche nel core di PHP, e ha messo l'esposizione al 70 per cento di tutti i siti del mondo. L'Australian Financial Review, raccontando che l'intelligenza artificiale aveva scoperto bug critici nel linguaggio usato dalla maggior parte dei web server, ha usato la stessa proporzione: il 70 per cento dei siti del mondo a rischio. Questo resoconto non ha un censimento indipendente. La cifra appartiene a quei due racconti, ed è la cifra contro cui il comportamento della giornata diventa intelligibile. Se anche una frazione seria di quella quota fosse giusta, un percorso non autenticato verso l'esecuzione di codice sul worker non sarebbe una storia da specialisti. Sarebbe un motivo perché un dicastero passi una mattina al telefono, che è ciò che descrive il reporting australiano.
Una falla del 2024, un accordo del 2026
L'emergenza ha una preistoria, ed è la parte meno lusinghiera del verbale.
La PHP Foundation ha trovato una falla critica nel 2024 ma non è riuscita a concordare una correzione fino al 2026. Il racconto di The Next Web è specifico sulla strettezza di quella frase: PHP sapeva di una delle falle nel 2024, e l'ostacolo non era l'ignoranza. Era l'accordo. Le fonti non dicono quale dei due CVE di ottobre fosse quella scoperta, né chi sostenesse quale rimedio, né quanto sarebbe costata una correzione respinta. Dicono che una falla critica è stata trovata, che su una correzione non si è riusciti a concordare, e che l'accordo è arrivato solo nel 2026.
Due anni sono un tempo lungo per lasciare una falla critica in un linguaggio che Wiz e l'Australian Financial Review associano entrambi a circa sette siti su dieci. È più lungo quando il rilascio finale non è una point version in calendario con due settimane di preavviso, ma una patch d'emergenza, annunciata per un mercoledì pomeriggio in UTC, con gli amministratori avvertiti il giorno prima di essere pronti. La distanza tra «l'abbiamo trovata» e «siamo d'accordo su come chiuderla» è, nel software ordinario, una lite da laboratorio. In un runtime così ampiamente innestato, su quei resoconti, la stessa distanza è una finestra di esposizione pubblica. Il verbale di ottobre non prova che cosa sia passato da quella finestra. Mostra che la finestra era reale, e che a metà mese non era più solo una questione di governance.
C'è la tentazione di trattare il mancato accordo come una morale. Il materiale non regge la morale nel dettaglio. Regge una cronologia. Una falla critica, nota alla Foundation nel 2024. Nessuna correzione concordata fino al 2026. Poi, in pochi giorni di ottobre, un grappolo di cose che di solito arrivano in sequenza è arrivato quasi una sull'altra: una disclosure di ricerca associata a Wiz, e a un reporting che ha accreditato l'intelligenza artificiale; un avvertimento del security team; un'ora pubblicata; patch per quattro linee di versione correnti; e, già nella telemetria di un cloud provider, un tentativo di sfruttamento datato 17 ottobre, prima della disclosure pubblica dei due numeri CVE.
Il leak, se è la parola giusta, è esso stesso un inquadramento con fonte, non un meccanismo assodato. Huntress ha titolato vulnerabilità critiche trapelate. PC Gamer ha scritto di exploit trapelati, e di amministratori in attesa degli aggiornamenti che li avrebbero tappati. L'announce ufficiale era di un imminente rilascio critico di sicurezza, fissato al 21 ottobre alle 14:00 UTC. Niente, in queste fonti, descrive come sia avvenuto un eventuale leak, chi tenesse i dettagli, o se il tentativo del 17 ottobre abbia usato le stesse informazioni che ricercatori e titolisti avrebbero poi chiamato trapelate. Quello che le fonti consentono è un'affermazione più dura e più piccola. Il tentativo precede la disclosure pubblica. La disclosure pubblica è stata gestita come un'emergenza con un orologio. E almeno una delle falle sottostanti era dentro la conoscenza della Foundation, irrisolta per mancato accordo, dal 2024.
Non è che non l'avessero vista. Su una delle falle, non sono riusciti a concordare una correzione — dal 2024 fino al 2026.
Quella distinzione cambia il tipo di rassicurazione che una patch può offrire. Un bug trovato lunedì e corretto mercoledì è un processo che lavora di corsa. Un bug trovato nel 2024 e rilasciato, in condizioni d'emergenza, nell'ottobre 2026 è un processo che alla fine ha funzionato, dopo un ritardo che, nel racconto di The Next Web, il consenso non è riuscito a chiudere. Le patch del 21 ottobre non cancellano il ritardo. Lo chiudono.
Vale la pena di notare che tipo di rilascio sia diventato, una volta arrivato l'accordo. Non un commit silenzioso. Un aggiornamento di sicurezza con un'ora pubblicata, anticipato sulla lista announce, abbastanza grave perché il security team passasse il giorno prima a dire agli amministratori di prepararsi, e abbastanza grave perché i rating attaccati alle due falle stessero a 9,2 su 10. La nota di PHP del giorno porta, nel titolo, la promessa di dire come il progetto stia rafforzando la propria sicurezza. Il contenuto di qualunque riforma più lunga sta fuori da queste fonti. Il fatto dell'emergenza no. Quello che si vede, nel materiale effettivamente in mano, è la decisione di rilasciare, a un'ora nominata, correzioni per due falle che il progetto non era più disposto a lasciare fino a un rilascio comodo.
Il giorno in cui il web ordinario si è spento da solo
Le interruzioni di solito si raccontano da fuori: un sito cade, un utente se ne accorge, una status page si aggiorna. Questa, in più posti, è stata raccontata come una scelta.
Il Brussels Times ha riferito di siti importanti andati offline mentre la vulnerabilità innescava timori di sicurezza, e l'affermazione sotto è diretta. Diversi siti importanti sono stati messi offline a causa di una vulnerabilità critica nel linguaggio. La scala della BBC era ancora più ampia: siti tirati giù in tutto il mondo mentre veniva emesso l'aggiornamento di cyber-security. Nessuno dei due resoconti elenca il metodo — che cosa è stato fermato, da chi, per quanto — e sarebbe una finzione fornire le operazioni mancanti. Fissano la causa al problema di PHP. Fissano la risposta, nel reporting di più di un Paese, come assenza piuttosto che come un hotfix applicato in silenzio.
Il consiglio ufficiale ha dato a quella scelta un garante. Le autorità di U.S., Europe e Britain hanno raccomandato che i siti andassero temporaneamente offline finché non si fosse potuti intervenire. È difficile sopravvalutare quanto di rado quella frase sia quella responsabile. Tirare giù un sito è, in tempi ordinari, l'esito che un attaccante vuole e che un operatore teme. Qui, tre insiemi di autorità hanno trattato l'assenza temporanea come lo stato più sicuro, per tutto il tempo in cui la correzione non era ancora applicata. L'avviso del National Cyber Security Centre su un problema critico di sicurezza che riguarda PHP sta nella stessa atmosfera, anche dove questo verbale non cita il Centre come autore della raccomandazione di andare offline con quelle parole. Quello per cui il Centre è citato, accanto alla BBC, è la sostanza: un problema critico che può consentire agli attaccanti di eseguire comandi su qualunque web server che esegue PHP, e un aggiornamento di sicurezza pubblicato per affrontarlo.
La versione australiana della mattina è stata una corsa alla patch. L'Australian Financial Review ha riferito che l'intelligenza artificiale aveva scoperto bug critici nel linguaggio di programmazione usato dalla maggior parte dei web server, e che le agenzie di governo si affannavano a patchare vulnerabilità nei siti. Quel dettaglio tira la storia fuori dal teatro solito delle interruzioni consumer. Servizi con un nome che vanno in manutenzione sono un tipo di danno: un pubblico che non raggiunge qualcosa che usa senza pensarci. Un'agenzia di governo che patcha di corsa è un altro. Lo stesso linguaggio, innestato in siti che non sono facoltativi allo stesso modo. La cornice dell'AFR era la cifra del 70 per cento, e la scoperta. La cornice operativa era più semplice. Il bug era nel linguaggio. Il linguaggio era nei siti. I siti dovevano muoversi.
Japan fornisce l'elenco più concreto, e quindi il correttivo più utile all'astrazione. È facile dire «il web» e intendere un diagramma. È più difficile liquidare un avviso di manutenzione che nomina CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server e つなぐ. Si aggiungano NicoNico e pixiv, come ha fatto Gigazine, e l'elenco smette di essere una metafora. L'hosting è il moltiplicatore nascosto in quei nomi. Una vulnerabilità in una sola applicazione è una vulnerabilità in quell'applicazione. Una vulnerabilità nel linguaggio, su un rental server o su X Server, è una coda di clienti che non hanno scelto il bug e non possono, in alcun senso significativo, patcharci intorno da soli. Queste fonti non contano quei clienti. Mostrano gli host che trattano la patch come abbastanza urgente da portare il servizio in manutenzione d'emergenza.
Il security team aveva chiesto preparazione, e i tempi mostrano la forma di ciò che era stato chiesto. L'avvertimento era di prepararsi ad aggiornamenti d'emergenza per l'indomani. Il rilascio era fissato alle 14:00 UTC del 21. Le patch, una volta uscite, erano le quattro point release già nominate. Quello che ha riempito le ore intorno a quell'appuntamento non è stato, su questo verbale, un blackout unico e coordinato. È stato un patchwork: alcuni siti messi offline tra i timori di sicurezza, alcuni tirati giù mentre usciva l'aggiornamento, alcuni messi in manutenzione nominata, alcuni attraversati di corsa da agenzie di governo australiane il cui problema era la patch stessa. L'elemento comune è il linguaggio, e il giudizio che aspettare una sera comoda non fosse più la scelta conservativa.
La gravità aiuta a spiegare il giudizio senza liquidarlo. Due vulnerabilità, ciascuna con un rating di 9,2 su 10, non è un accoppiamento che inviti un rollout a tappe in un weekend quieto. Una portata senza autenticazione, nel caso dimostrato di mod_php, prima che giri il codice applicativo, non è un accoppiamento che inviti fiducia in qualunque controllo un'applicazione possa fare dopo. Metteteli accanto a un avvertimento che il problema può consentire l'esecuzione di comandi su qualunque web server che esegue PHP, e il consiglio di andare offline finché non si è corretto smette di sembrare teatro. Sembra l'opzione residua, una volta capito che la falla sta nel runtime e non in un angolo che un operatore possa semplicemente spegnere.
Niente di tutto questo richiedeva che le vulnerabilità fossero nuove per tutti. Richiedeva che fossero diventate innegabili. La conoscenza della Foundation nel 2024, e la sua incapacità di concordare una correzione fino al 2026, sta nello stesso respiro degli avvisi di manutenzione. I siti andati al buio il 21 ottobre vivevano dentro un ritardo su cui non avevano votato. È il fatto politico dentro un fatto di release engineering. Un linguaggio usato, nel racconto di Wiz e dell'AFR, da qualcosa come il 70 per cento dei siti del mondo non è una codebase privata, anche quando la sua governance è una lite privata. Il costo di una correzione non concordata lo pagano persone che non sono alla riunione.
Chi sapeva, e chi ci stava già provando
In questa storia ci sono due primi, e rispondono a domande diverse.
Wiz Research ha scoperto più vulnerabilità critiche nel core di PHP. Il racconto dell'azienda, e quello dell'Australian Financial Review, mettono entrambi l'intelligenza artificiale nella scoperta. Wiz ha inquadrato il ritrovamento come un'AI che scopre vulnerabilità critiche di esecuzione remota di codice che riguardano il 70 per cento di internet. L'AFR ha riferito che l'AI aveva scoperto un bug che metteva a rischio il 70 per cento dei siti del mondo, e che le agenzie di governo australiane si affannavano. Come sia stato usato un modello, che cosa gli sia stato mostrato, che cosa un ricercatore umano abbia ancora dovuto provare: niente di tutto questo è nel materiale qui, e sarebbe una finzione fornirlo. Quello che c'è nel materiale è l'attribuzione. Uno sforzo di ricerca associato a Wiz, e descritto in più di un posto come lavoro dell'AI, ha fatto emergere più falle critiche nel core del linguaggio. In quel racconto, non era una misconfigurazione in un'estensione popolare. Era PHP stesso.
L'altro primo non è una scoperta. È un tentativo. Amazon Threat Intelligence ha identificato un tentativo di sfruttamento di PHP2Shell datato al 17 ottobre 2026, nella telemetria MadPot, quattro giorni prima della disclosure pubblica di CVE-2026-109618 e CVE-2026-109619. Un tentativo non è un censimento delle intrusioni. Queste fonti non dicono quanti server abbiano risposto, che cosa sia stato preso, o se il tentativo sia riuscito in modo durevole. Dicono che è stato identificato, che è datato al 17, e che la disclosure pubblica dei due CVE è arrivata quattro giorni dopo. In una settimana di affermazioni grandi — qualunque web server, il 70 per cento dei siti, takedown in tutto il mondo — la frase di Amazon è quasi austera, ed è quella che cambia di più la temperatura. Qualcuno non stava aspettando la FAQ.
Messa in piano, la sequenza è questa. Una falla critica nota alla Foundation dal 2024, senza una correzione concordata. Un tentativo di sfruttamento il 17 ottobre 2026, visto nella telemetria MadPot di Amazon. Un avvertimento del security team di PHP di prepararsi ad aggiornamenti d'emergenza il giorno dopo. Un rilascio annunciato alle 14:00 UTC del 21 ottobre, portato su php.announce e corroborato da Huntress, dal racconto di PC Gamer sugli amministratori in attesa, e dal post di Dane Knecht. Patch uscite lo stesso giorno, come 8.5.12, 8.4.27, 8.3.36 e 8.2.35, a chiudere due vulnerabilità critiche che consentono l'esecuzione remota di codice senza autenticazione. Intorno a quel rilascio: siti offline, siti in manutenzione, agenzie in affanno, autorità che raccomandano il buio come controllo temporaneo.
Quello che questa cronologia non regge è un unico complotto che corra da un disaccordo del 2024 a una sonda del 17 ottobre. Niente qui collega il mancato accordo, non pubblicato, della Foundation al tentativo MadPot, o quel tentativo alla disclosure di ricerca, o la disclosure di ricerca a un operatore con nome. Il quadro onesto è di più orologi, non di una cospirazione. Un orologio di governance che ha girato per due anni. Un orologio di ricerca che è finito in una scoperta pubblica attribuita a Wiz e all'AI. Un orologio difensivo fissato, molto deliberatamente, alle 14:00 UTC di un mercoledì. E un orologio offensivo che, nel racconto di Amazon, aveva già battuto il 17.
L'inquadramento degli exploit trapelati sta in modo scomodo attraverso quegli orologi, e la scomodità va lasciata visibile. Se Huntress e PC Gamer hanno ragione che le vulnerabilità, o gli exploit, erano trapelati, allora il rilascio d'emergenza è in parte una risposta a una perdita di controllo sull'informazione, non solo una risposta a un bug. Se la lista announce si legge da sola, il rilascio è un aggiornamento critico di sicurezza pianificato, con un'ora di inizio. Possono essere vere entrambe: un piano, e un piano condotto dove altri descrivevano già un leak. Le fonti non arbitrano. Mostrano un progetto che sceglie un'ora pubblica, ricercatori che descrivono falle trapelate, e i sensori di un cloud provider che registrano un tentativo prima che i numeri CVE fossero pubblici. Basta a respingere la versione consolatoria, in cui la prima volta che qualcuno di fuori ha sentito delle falle è stato un advisory levigato e un set di pacchetti.
Basta anche a essere cauti sul successo. «Exploitation attempt» è la frase che regge il racconto di Amazon. «May allow» è la frase attaccata all'esecuzione di comandi su qualunque web server che esegue PHP. «Demonstrated» è la parola che l'archivio di PHP usa per il percorso mod_php, dove una richiesta non autenticata può innescare l'attacco prima che giri il codice applicativo. «Confirmed impact» è l'esecuzione remota di codice senza autenticazione come account del web worker. Impilate senza cura, quelle frasi diventano un senso di compromissione generale già compiuta. Lette come sono scritte, sono più precise, e la precisione è la notizia. C'è un percorso dimostrato. C'è una classe di impatto confermata. C'è un tentativo registrato prima della disclosure. C'è un avvertimento abbastanza ampio da coprire qualunque server che esegue il linguaggio. Non c'è, in questo materiale, un conteggio pubblicato delle intrusioni.
Quello che quattro numeri di versione possono chiudere
I pacchetti sono la parte della storia con i numeri di versione, e i numeri di versione sono una misericordia. PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 correggono due vulnerabilità critiche che possono consentire l'esecuzione remota di codice senza autenticazione. Quattro branch, quattro point release, un pomeriggio. Per gli operatori su quei branch, l'emergenza aveva una fine che si poteva scaricare. L'aggiornamento di sicurezza non era solo promesso alle 14:00 UTC. È stato pubblicato, per affrontare un problema critico che può consentire agli attaccanti di eseguire comandi su qualunque web server che esegue PHP. È la frase che il National Cyber Security Centre e la BBC lasciano nel verbale, ed è la frase contro cui le finestre di manutenzione sono state aperte, e contro cui possono chiudersi.
Quello che i pacchetti non chiudono automaticamente è la discussione sullo scope.
Non rispondono, alla lettera di queste fonti, all'amministratore il cui PHP è 7, o 5, o 6, tutti dentro l'insieme delle versioni che si ritiene colpite. Una convinzione non è una patch. La convinzione è ben attestata — quattro fonti, tra cui la scrittura di security-release del progetto e una FAQ specialistica di Watchtowr. Le correzioni che hanno un nome non sono un set corrispondente. Fingere il contrario, per avere un finale pulito, vorrebbe dire inventare un backport che questi grappoli non contengono. L'affermazione pulita è quella disordinata. Gli 8.2, 8.3, 8.4 e 8.5 correnti hanno correzioni con un nome. Le linee più vecchie sono, nel giudizio di quelle quattro fonti, dentro il raggio ritenuto, e questo verbale si ferma lì.
Né i pacchetti dissolvono la differenza tra «any web server running PHP» e «highest for mod_php». Un operatore il cui setup non è quello che l'archivio ha segnato come rischio massimo può leggere l'avvertimento ufficiale e la nota tecnica e non sapere quale governi la notte. Il caso dimostrato dell'archivio è quello in cui una richiesta non autenticata innesca l'attacco prima che giri qualunque codice applicativo, e attacca quella dimostrazione a mod_php come rischio massimo. L'avvertimento più ampio non aspetta la distinzione. Le autorità in United States, Europe e Britain hanno raccomandato uno stato offline temporaneo finché i siti non si fossero potuti correggere, e quella raccomandazione non si legge come limitata a un solo modulo server. Se in questo episodio c'è una disputa, non è una lite urlata tra vendor. È questa: una descrizione istituzionale ampia di chi è esposto, e una descrizione tecnica più stretta di dove il pericolo è stato mostrato al massimo, pubblicate nella stessa settimana, sugli stessi due CVE. Entrambe sono nel verbale. Nessuna cancella l'altra.
L'affermazione sull'impatto ha un suo confine, e il confine vale la pena di tenerlo. L'impatto confermato è l'esecuzione remota di codice senza autenticazione come account del web worker. È grave, ed è specifico. L'esecuzione di comandi, nella formulazione di BBC e NCSC, è il potere di cui si avverte. L'account nominato nella conferma d'impatto è quello del worker. Un lettore attento non scambia l'uno con l'altro al rialzo. L'esecuzione di codice come worker basta, sull'affermazione con fonte, a contare enormemente: sono le mani stesse del sito. Non è, su questa evidenza, un'affermazione con fonte di controllo automatico oltre quell'account. La paura della giornata era calibrata sull'affermazione che le fonti fanno davvero, e quell'affermazione bastava già a svuotare homepage e a giustificare, nel giudizio di tre insiemi di autorità, una sparizione temporanea.
C'è un ulteriore confine intorno alla parola «attempt». Amazon ha visto un tentativo di sfruttamento di PHP2Shell il 17 ottobre, prima della disclosure. Le patch del 21 non possono disvederlo. Possono chiudere i bug di cui un tentativo del genere avrebbe avuto bisogno, sulle versioni che coprono, per gli operatori che le applicano. Non possono dire quanti tentativi di quel tipo non siano mai stati visti, o quanti siano riusciti in posti senza una telemetria del tipo di MadPot. L'assenza di un elenco di vittime in queste fonti non è la prova di una settimana quieta. È la prova che questo verbale riguarda la falla, la correzione, il consiglio e un tentativo identificato — non un bilancio compiuto del danno.
E c'è il confine intorno al 2024. Le patch concordano una correzione. Non spiegano il disaccordo che ne ha ritardata una. Il ritrovamento di The Next Web resta come il fruscio sotto le note di rilascio: una delle falle era nota nel 2024; una correzione non si è potuta concordare fino al 2026; l'accordo, quando è arrivato, è arrivato come emergenza, anticipata il giorno prima e valutata 9,2 su 10. Chi vuole una storia di sprint dalla scoperta alla patch dovrà far partire l'orologio in ottobre. Chi lo fa partire dove lo fa partire The Next Web vedrà una lite di due anni, e poi un mercoledì.
PHP2Shell è un nome abbastanza buono per una settimana. È un nome povero per la condizione che la settimana ha esposto. La condizione è che una falla in questo linguaggio può essere nota, e non concordata, e poi d'un tratto di tutti; che la patch, quando arriva, può essere reale e ancora non coprire, nelle fonti che abbiamo, ogni versione che i ricercatori ritengono in scope; che l'avvertimento ufficiale e la nota tecnica possono essere entrambi attenti e ancora non dire la stessa cosa. L'istruzione sensata, per un giorno, non era di essere più furbi del bug. Era di stare offline finché i pacchetti con quei quattro numeri non fossero più una promessa per le 14:00 UTC, ma un file davvero uscito.
Il web, nei resoconti di quel mercoledì, non è caduto da solo. Parti sono state messe a dormire di proposito, da operatori e host che avevano letto l'avvertimento e preferivano una pagina di manutenzione a un worker che esegue i comandi di qualcun altro. Non è una storiella su una point release. È la storia di quanta vita ordinaria stia oggi dentro un processo PHP — una quota che Wiz e l'Australian Financial Review mettono entrambi vicino al 70 per cento dei siti del mondo — e di quanto poco margine resti quando un worker non si può più fidare di non far indugiare la memoria di una richiesta come stato della successiva. La correzione, sulle linee che copre, è quattro numeri di versione e un pomeriggio. Il ritardo che ha fatto di quel pomeriggio un'emergenza è durato due anni.