PHP2Shell: vulnerabilità critica di PHP — il Suo sito è a rischio?

Sono coinvolte tutte le versioni di PHP che, nel proprio ramo, sono precedenti alla 8.5.12, alla 8.4.27, alla 8.3.36 e alla 8.2.35, e questo significa quasi ogni sito web in PHP che questa settimana nessuno ha aggiornato. Oggi il primo compito è stabilire quale versione serve il Suo sito, e aggiornarla — una mitigazione completa non esiste, e lo stesso comunicato di PHP dice che l’aggiornamento è l’unica scelta sicura.

Mercoledì 21 ottobre il team di PHP ha rilasciato insieme quattro versioni straordinarie; la coppia di vulnerabilità che queste versioni correggono ha preso il nome PHP2Shell, e il nome descrive il risultato con precisione: dalla richiesta di rete fino all’esecuzione di codice sul server. Questo articolo dice che cosa è stato trovato di preciso, come capire se riguarda Lei e in quale ordine agire — anche nel caso in cui non possa aggiornare subito.

Che cos’è PHP2Shell e che cosa è successo il 21 ottobre

Nel comunicato ufficiale si legge che la 8.5.12, la 8.4.27, la 8.3.36 e la 8.2.35 correggono due vulnerabilità critiche che possono consentire a un attaccante non autenticato l’esecuzione di codice da remoto (RCE), e che a tutti gli utenti di PHP si raccomanda con fermezza di aggiornare senza indugio. Nello stesso testo c’è anche la frase che decide tutto il resto di questo articolo: una mitigazione completa non esiste, e l’aggiornamento è l’unica scelta sicura.

A entrambe le vulnerabilità PHP ha assegnato un punteggio CVSS v4.0 di 9,2 su 10, ma si tratta di due errori distinti, con un meccanismo diverso e, come vedrà più avanti, anche con un grado di conferma diverso — ed è proprio questa seconda differenza che, in pratica, decide da quale server cominciare.

CVE-2026-109618 — memoria danneggiata dopo un esaurimento della memoria (out-of-memory): quando a PHP manca la memoria, usa longjmp() per interrompere l’elaborazione della richiesta. La descrizione ufficiale indica che in alcuni momenti la memoria della richiesta è raggiungibile prima che sia completamente inizializzata; se proprio allora l’allocazione non riesce, l’interruzione non viene gestita correttamente e resta memoria non valida, che il codice di chiusura legge ancora oppure sulla quale prende una decisione.

Un dettaglio che cambia a chi si applica questa minaccia: l’esaurimento della memoria si ottiene con una richiesta multipart preparata apposta, e non serve che contenga alcun file caricato. La descrizione ufficiale cita diversi problemi nell’analisi multipart — una richiesta senza una lunghezza dichiarata utilizzabile, una parte con un numero di intestazioni non limitato, campi file vuoti che non rientrano nei limiti. Questo significa che la richiesta può essere molto piccola e stare dentro i normali limiti di post_max_size e di memory_limit.

CVE-2026-109619 — stato globale non aggiornato: nel processo PHP, fra una richiesta e l’altra, resta uno stato globale: dati degli errori, delle sessioni, degli oggetti e delle estensioni. La descrizione ufficiale dice che questo stato va azzerato prima che la memoria della richiesta venga liberata. Se l’azzeramento viene interrotto da un errore fatale, oppure se al momento della chiusura la diagnostica lo riempie di nuovo, la memoria viene liberata ma il puntatore verso di essa resta. Questa classe di errori, a livello internazionale, si chiama use-after-free — uso di memoria già liberata.

C’è poi una condizione che rende questa vulnerabilità più difficile di quanto non sembri: il puntatore non aggiornato può usarlo solo un’operazione che avviene prima della normale inizializzazione della richiesta, e la descrizione ufficiale nomina due casi confermati di questo tipo — la diagnostica INI e l’elaborazione dell’avanzamento del caricamento di sessione. In più, la richiesta successiva dell’attaccante deve finire esattamente nello stesso processo in cui si è formato lo stato danneggiato, perciò un tentativo isolato riesce di rado, e la descrizione dice espressamente che più processi e il loro ricambio riducono le probabilità, ma la condizione stessa non la eliminano.

Quanto è facile sfruttarla e contro che cosa è stata dimostrata

Qui conviene essere precisi, perché è proprio in questo punto che la maggior parte degli articoli in rete esagera da una parte o dall’altra.

Una password non serve, e non serve nemmeno che qualcuno sul sito prema qualcosa — nel vettore CVSS questo si legge come PR:N e UI:N. Nello stesso vettore, però, ci sono AC:H e AT:P: la complessità dell’attacco è valutata alta, e l’attacco ha prerequisiti aggiuntivi. In pratica questo significa tentativi ripetuti, e la riuscita dipende dalla build di PHP, dalle estensioni, dal comportamento del frontend e dalla disposizione della memoria. Quindi no — una sola richiesta ordinaria non basta; all’attaccante, però, non costa nulla, perché il numero dei tentativi non lo limita niente.

Il grado di prova delle due falle è diverso, e questa differenza conta quando si sceglie quanta fretta avere. Nel caso di CVE-2026-109618 l’esecuzione di codice da remoto completa è stata confermata contro mod_php, con i limiti predefiniti di input e di memoria; quanto a PHP-FPM, la stessa descrizione dice che l’analisi del codice sorgente lo considera vulnerabile, ma un attacco PHP-FPM completo non è stato dimostrato. FrankenPHP vi è indicato come analogo di mod_php, LSAPI come analogo di PHP-FPM, in entrambi i casi senza un attacco verificato.

Nel caso di CVE-2026-109619 il percorso del ciclo di vita della sessione è stato verificato sia contro mod_php sia contro PHP-FPM, mentre l’altro percorso, quello che passa dal backtrace dell’errore fatale, è confermato solo contro mod_php.

Ne consegue un ordine pratico: se il Suo sito gira su mod_php, Lei è in prima fila, perché è proprio lì che entrambe le falle sono state confermate. Nel caso di PHP-FPM e di LiteSpeed il rischio è reale, ma per ora confermato solo in parte. In nessuno di questi casi è un motivo per aspettare — è un motivo per sapere da quale server cominciare.

Come è andata questa settimana, ora per ora

La cronologia non è una curiosità — spiega perché i consigli delle prime ore erano diversi da quelli che valgono adesso, e perché una parte degli articoli in rete è ancora superata.

La sera del 20 ottobre si sapeva che stava arrivando qualcosa, ma non che cosa di preciso: PHP aveva annunciato un rilascio straordinario imminente, e la pagina di stato di CloudLinux, quella stessa sera, registra che la pubblicazione dei dati tecnici e delle versioni coinvolte è prevista per il momento del rilascio del giorno dopo, e la descrizione tecnica, in quel momento, non era ancora pubblica.

Entro il giorno dopo la situazione era cambiata, e non in meglio: la mattina del 21 ottobre CloudLinux registra che in circolazione pubblica c’è già un pattern di attacco, e alle 9.08 UTC diffonde un insieme di regole del firewall che blocca il pattern noto della richiesta di sfruttamento. Diciotto minuti dopo, sulla stessa pagina, compare la frase che descrive meglio questa settimana — i tentativi corrispondenti a quel pattern si osservano già, quindi qualcuno cercava già i server sui quali la patch di sicurezza ancora non c’era.

Le patch di sicurezza di PHP sono uscite alle 14.00 UTC, il che significa che fra un pattern di attacco disponibile pubblicamente e una patch disponibile pubblicamente sono passate diverse ore, e in quelle ore i tentativi di attacco erano già in corso.

Un’avvertenza, qui, è giusto dirla: il mondo non era del tutto senza patch, perché nel comunicato di PHP si legge che le distribuzioni Linux e i fornitori di supporto a lungo termine hanno ricevuto le patch in anticipo, perciò per una parte dei server l’aggiornamento era disponibile prima che per gli altri — disponibile pubblicamente, però, non lo era per nessuno.

Poi è cominciata la parte più lunga, che continua ancora: la distribuzione dei pacchetti; chi mantiene i sistemi operativi e le piattaforme di hosting costruisce i propri pacchetti separatamente, e questi compaiono nel giro di ore o di giorni, ciascuno con il proprio ritmo. È proprio in questa fase che si trova una gran parte degli utenti dell’hosting condiviso, e proprio per questo la domanda «la patch è uscita» e la domanda «la patch è sul mio server» questa settimana sono due domande diverse, con risposte diverse.

Il Suo sito è a rischio?

Negli avvisi ufficiali gli intervalli delle versioni coinvolte sono scritti così: tutto ciò che è precedente alla 8.2.35, tutto ciò che è precedente alla 8.3.36, tutto ciò che è precedente alla 8.4.27 e tutto ciò che è precedente alla 8.5.12 — ciascuno nel proprio ramo.

Un dettaglio sul quale è facile sbagliarsi: il numero che mostra php -v non dice sempre tutto. Le distribuzioni Linux e le piattaforme di hosting spesso riportano la patch su una versione più vecchia senza cambiarne il numero — cambia solo il numero di rilascio del pacchetto. In quel caso la 8.4.26 può essere già riparata, e può anche non esserlo; l’unico modo per saperlo è guardare la descrizione del pacchetto oppure chiedere al fornitore; il numero di versione, da solo, a questa domanda non risponde.

A parte, le versioni più vecchie: PHP 8.1 e le precedenti non ricevono più aggiornamenti regolari dal progetto PHP; tenuta presente la gravità, però, il team di sicurezza ha preparato patch minime del codice sorgente per le versioni 7.4, 8.0 e 8.1 — per chi compila dal codice sorgente o non ha accesso al supporto di chi mantiene i pacchetti. Il comunicato, lì accanto, consiglia di rivolgersi al proprio fornitore, perché una parte delle distribuzioni e dei fornitori di supporto a lungo termine riporta le patch. Se il Suo sito gira su PHP 7.x, il vero problema non è questa settimana — il vero problema è che la prossima volta la patch potrebbe anche non esserci. E PHP 8.2, che questa volta la patch l’ha ricevuta, raggiunge l’end of life il 31 dicembre 2026.

Come verificare la versione, a seconda di dove vive il sito

La verifica richiede minuti, e conviene farla per ogni sito separatamente, non per ogni server: su un solo server vivono spesso siti con versioni di PHP diverse, e di solito è proprio il più vecchio, quello che tutti hanno dimenticato, a essere raggiungibile pubblicamente.

Hosting condiviso con cPanel: la versione la mostra la sezione MultiPHP Manager, in cui ogni dominio ha la propria riga; Plesk, per la stessa cosa, usa PHP Settings all’interno di ciascun abbonamento. In entrambi i casi conviene accertarsi di stare guardando il dominio di cui si parla, e non il valore predefinito del server.

Server proprio o server virtuale (VPS): dalla riga di comando lo mostra php -v, con un’avvertenza sostanziale: il PHP della riga di comando è spesso una versione del tutto diversa da quella che serve le richieste web. La risposta più affidabile la dà lo stesso percorso lungo il quale lavora il sito — il file eseguibile indicato nella sezione pool della configurazione di PHP-FPM.

Contenitori. Se il sito gira in un ambiente Docker, la versione la decide l’immagine, non la macchina host, e quindi i passi sono due: ricostruire l’immagine a partire da un’immagine di base aggiornata e poi riavviare i container. Un’immagine costruita prima del 21 ottobre la patch non la contiene, indipendentemente da quante volte il container sia stato riavviato.

Se non ha accesso a nessuno di questi: allora la domanda va al fornitore di hosting, e questa settimana è una domanda del tutto normale, alla quale una risposta è già pronta. La formulazione che accorcia lo scambio di messaggi: «Su quale versione di PHP gira il mio dominio, la patch di PHP2Shell c’è, e se ancora non c’è, in quale data ci sarà?»

Che cosa fare oggi

L’ordine di oggi è questo: prima aggiornare PHP e riavviare tutto ciò che lo esegue, poi accertarsi che i visitatori siano davvero serviti dalla versione nuova, quindi verificare se il repository di pacchetti in uso la patch l’ha rilasciata, e solo dopo cercare le tracce. Il primo passo richiede minuti, l’ultimo può richiedere giorni, e proprio per questo non conviene scambiarli di posto.

Per prima cosa, aggiorni: nel caso dell’hosting gestito lo fa il fornitore, e il Suo compito è fare la domanda e ottenere una data. Se il server lo amministra Lei, dopo l’aggiornamento dei pacchetti bisogna riavviare ciò che esegue PHP: Apache, PHP-FPM o LSAPI. Questo passo si salta con una frequenza sorprendente — il pacchetto è stato sostituito, ma i processi vecchi continuano a lavorare con il codice vecchio, così il controllo mostra la versione nuova mentre i visitatori li serve ancora quella vecchia.

In secondo luogo, verifichi che l’aggiornamento sia davvero applicato — lungo lo stesso percorso per cui lavora il sito, non dalla riga di comando.

In terzo luogo, se usa un repository di pacchetti mantenuto da volontari, verifichi se ha rilasciato la patch. Nel comunicato di PHP c’è un avviso a parte su rpms.remirepo.net: ai suoi utenti si consiglia di passare ai pacchetti della distribuzione oppure di compilare dal codice sorgente.

In quarto luogo, solo dopo verifichi se sul sito ci sono tracce; l’aggiornamento chiude la porta, ma non risponde alla domanda se qualcuno da quella porta è già entrato.

Se non può aggiornare subito

Le conviene leggere questa parte sapendo con chiarezza che nessuno dei passi indicati qui sostituisce l’aggiornamento — il comunicato di PHP lo dice espressamente.

Contro CVE-2026-109618 il comunicato indica la rimozione del limite di memoria: memory_limit=-1, e in modo tale che l’applicazione non possa riscriverlo — per esempio con php_admin_value nella configurazione di PHP-FPM o di Apache, accertandosi che nessun’altra impostazione riporti indietro il limite finito. Bisogna capire che cosa costa questa scelta: su un server condiviso scambia un rischio con un altro, perché una sola richiesta ora può consumare tutta la memoria disponibile. Nella descrizione della vulnerabilità c’è anche l’avviso di non usare RLIMIT_AS e RLIMIT_DATA, perché possono far fallire l’allocazione di memoria e portare così proprio sul percorso vulnerabile.

Contro CVE-2026-109619 il comunicato indica session.upload_progress.enabled=0 e, nel caso di PHP 8.5, fatal_error_backtraces=0 — in entrambi i casi con l’indicazione di riavviare poi tutti i processi. Nella descrizione stessa della vulnerabilità c’è anche pm.max_requests=1, che impone a PHP-FPM di sostituire il processo dopo ogni richiesta; è un’impostazione del pool di PHP-FPM, e lì è citata con la riserva «se le prestazioni non sono un fattore». Lì si dice anche ciò che tiene questa misura dentro i suoi limiti veri: la sostituzione dei processi riduce le probabilità su una singola richiesta, ma la condizione stessa non la elimina.

È utile anche ciò che non è una mitigazione, ma riduce la superficie d’attacco: un post_max_size conservativo, una profondità di annidamento dell’input ragionevole e un volume di caricamento limitato, e sono valori buoni in qualsiasi settimana, non solo in questa.

Come capire se Lei è già stato colpito

Dopo l’aggiornamento conviene rivedere i log del server web degli ultimi giorni: ciò che va cercato è un numero insolitamente alto di richieste multipart verso uno stesso indirizzo — e qui è facile cercare nel modo sbagliato: tendono a essere piccole e a rientrare nei limiti ordinari, perciò per volume non le si trova. Più eloquenti sono le serie improvvise di errori 500, che cominciano e finiscono senza un motivo visibile: un attacco che si basa sull’esaurimento della memoria fallisce molto più spesso di quanto riesca, e ogni tentativo fallito lascia un errore.

Nel file system contano gli orari di modifica: un file PHP cambiato di notte, quando nessuno lavorava, va spiegato. Conviene controllare anche le attività pianificate e le voci che garantiscono l’avvio automatico dopo un riavvio — per un attaccante che dispone dell’esecuzione di codice il primo compito è radicarsi, così che l’accesso sopravviva proprio all’aggiornamento che Lei ha appena installato.

A parte, conviene controllare l’elenco degli account di amministratore e le password e le chiavi delle applicazioni. Se l’esecuzione di codice è avvenuta, tutto ciò che il server conosce va considerato come già letto — anche i dati di connessione al database e le chiavi API nel file di configurazione.

Se qualcosa di tutto questo non sembra a posto, la pulizia è un lavoro a parte, con un ordine suo, e conviene farla in modo metodico, non cancellando i file sospetti uno alla volta. Lo abbiamo descritto separatamente — come avviene il ripristino di un sito hackerato — e, se desidera che lo faccia qualcun altro, il ripristino di siti hackerati è un servizio a parte con una sequenza fissa: isolamento, pulizia, rimozione della causa e verifica che il sito sia stato tolto dagli elenchi degli avvisi dei motori di ricerca.

Quando l’evento diventa un incidente da notificare

Se c’è motivo di ritenere che l’attaccante abbia avuto accesso a dati personali, la questione tecnica diventa anche giuridica. Il regolamento generale sulla protezione dei dati prevede un termine che non decorre dall’attacco, ma dal momento in cui il titolare del trattamento è venuto a conoscenza della violazione dei dati personali: ove possibile, non oltre 72 ore per la notifica all’autorità di controllo. L’obbligo non sorge quando è improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche e, se il rischio è elevato, vanno informati anche gli interessati — anche questo obbligo, nel regolamento, ha le proprie eccezioni.

Il senso pratico di questa parte è uno solo: il momento in cui nei log si trova qualcosa di sospetto non è il momento in cui cominciano a decorrere le 72 ore — è il momento in cui bisogna accertare se una violazione dei dati personali sia avvenuta. Una serie isolata di errori 500, che come descritto sopra nella maggior parte dei casi è un tentativo fallito, non è di per sé una violazione. Proprio per questo non conviene rimandare l’accertamento a «quando ci sarà meno da fare», e proprio per questo i log vanno conservati prima che la rotazione li sovrascriva: sono l’unica prova sia di ciò che è accaduto, sia di ciò che non è accaduto.

Se ha in carico più siti

Per le agenzie e per le aziende con più siti, questa settimana è un compito organizzativo almeno quanto tecnico, e l’ordine che funziona è semplice: prima l’elenco, poi le versioni, poi l’aggiornamento in ordine di priorità.

La priorità non la decide l’importanza del sito, ma la raggiungibilità e ciò che lo serve. In cima stanno i siti pubblicamente raggiungibili su mod_php, perché è proprio lì che entrambe le vulnerabilità sono state confermate; poi il resto di ciò che è pubblico, e solo dopo i sistemi interni dietro un firewall. Gli ambienti di test e di sviluppo, quelli che tutti dimenticano, nell’elenco vanno inclusi per forza — spesso girano su una versione di PHP più vecchia e spesso sono raggiungibili da internet, perché un tempo così era più comodo.

I siti che gestisce qualcun altro restano nell’elenco, ma con un’altra colonna: a chi è stata inviata la domanda e in quale data è arrivata la risposta. Questa colonna, più avanti, si rivela più utile delle altre, perché è proprio essa a mostrare quale fornitore risponde e quale no.

Che cosa ha significato, in questo caso, l’hosting gestito

Questa settimana mostra bene dove sta il confine tra la piattaforma e l’applicazione, e quindi è giusto dire come la cosa si è vista dalla nostra parte.

I nostri server girano su CloudLinux e hanno Imunify360 integrato: quando il pattern di attacco ha cominciato a circolare in pubblico, CloudLinux ha registrato sulla propria pagina di stato che l’insieme di regole del firewall che blocca il pattern di sfruttamento noto è stato diffuso alle 9.08 UTC — diverse ore prima che PHP rilasciasse la patch stessa alle 14.00, e prima che sulla stessa pagina comparisse la nota secondo cui i tentativi si stavano già osservando. Nel corso della giornata sono seguiti altri due aggiornamenti delle regole, il secondo dei quali blocca lo strumento di sfruttamento già disponibile pubblicamente. Tutto questo è avvenuto in automatico, senza la partecipazione del cliente, e nel settore questa misura si chiama virtual patching: una regola del web application firewall (WAF) blocca lo sfruttamento della vulnerabilità senza modificare il codice vulnerabile.

E adesso ciò che una frase del genere non significa, perché è proprio qui che il settore, questa settimana, ha venduto il maggior numero di esagerazioni. Una regola del firewall blocca i pattern di attacco noti — la stessa parola la usa anche CloudLinux. La stessa pagina chiama questa misura una soluzione temporanea, non una correzione completa; non è invulnerabilità, e lo stesso CloudLinux continua a consigliare di aggiornare PHP non appena i pacchetti sono disponibili. La differenza tra «protetto» e «riparato», questa settimana, è del tutto concreta, e vendere l’uno al posto dell’altro sarebbe scorretto.

Come si presenta la patch stessa è una buona illustrazione di ciò su cui si era avvertito prima. I nostri server hanno ricevuto una nuova build di ea-php84 la sera dello stesso giorno, alcune ore dopo il rilascio di PHP. Il numero di versione non è cambiato — php -v scrive ancora 8.4.26, non 8.4.27, e l’unica cosa che dall’esterno testimonia il cambiamento è la data di build, saltata dal 9 al 21 ottobre. È proprio così che si presenta una patch riportata su una versione precedente, e proprio per questo la domanda al fornitore di hosting vale più del numero che mostra lo schermo.

Per questo il valore che qui ha comprato l’hosting gestito non è l’invulnerabilità, ma una finestra di esposizione più stretta: le ore in cui il pattern di attacco già circolava e i tentativi già avvenivano sono state coperte bloccando i pattern noti, non aspettate. E dopo — che qualcuno segua i pacchetti e riavvii i processi, invece di aspettare che se ne accorga il cliente. Il nostro hosting gestito parte da 45 € al mese, e sono proprio le settimane di questo tipo ciò per cui, in quella cifra, si paga.

Se il Suo sito in questo momento gira in un posto dove alla domanda sulla versione di PHP e sulla data dell’aggiornamento non si riesce a ottenere una risposta, questo è già di per sé una risposta. Parliamo del trasferimento — la migrazione di solito si può fare senza interruzione.

Dopo l’aggiornamento va riavviato più di quanto sembra

Un processo worker PHP che resta in vita fra una richiesta e l’altra non è nulla di esotico — è proprio così che lavorano un pool ordinario di PHP-FPM e mod_php, ed è proprio contro di essi che l’esecuzione di codice è stata confermata. Per questo CVE-2026-109619 non è la minaccia di qualche configurazione speciale; è un problema della configurazione ordinaria.

Ne consegue il passo che più spesso si salta: sostituire il pacchetto non tocca il processo che sta già lavorando. Dopo l’aggiornamento bisogna riavviare ogni processo che esegue PHP, e questo vale anche per quelli che di solito nessuno tocca. I processi PHP che restano in esecuzione a lungo tendono a non riavviarsi per settimane, perciò dopo l’aggiornamento conviene elencarli a parte e accertarsi che ciascuno sia stato avviato di nuovo.

La domanda di verifica giusta, perciò, non è «che cosa mostra php -v», bensì «ogni processo che esegue PHP è stato avviato dopo che il pacchetto è stato sostituito».

Perché non basta «noi non carichiamo nulla»

Un’obiezione diffusa suona più o meno così: il nostro sito è un sito vetrina, non ha né un modulo di caricamento né account di utente, quindi questo non ci riguarda. Purtroppo riguarda, e la ragione è proprio quella descritta sopra: all’attacco non serve un file caricato, basta una richiesta multipart preparata apposta, e la si può inviare a qualsiasi indirizzo che risponda con PHP. La presenza di un modulo sulla pagina non è un prerequisito, perché l’attaccante il modulo non lo compila.

Allo stesso modo non importa se il sito è piccolo; gli attacchi a vulnerabilità di questo tipo avvengono a tappeto e in automatico, e una selezione secondo il numero dei visitatori non la fa nessuno. L’unità Unit 42 di Palo Alto Networks, il giorno della pubblicazione, ha riferito più di 22,6 milioni di istanze PHP raggiungibili da internet e potenzialmente colpite; nessuna di esse è stata scelta in modo particolare.

La seconda obiezione riguarda WordPress e i plugin: anche questa, stavolta, non regge, solo nella direzione opposta: la vulnerabilità è in PHP stesso, non in WordPress, in Laravel o in un plugin. Questo significa che aggiornare i plugin il problema non lo risolve e, insieme, che è colpito ogni sito web in PHP, indipendentemente da ciò su cui è costruito.

Che cosa di questa settimana conviene tenere

A chi aveva già tutto in ordine non è servita una reazione rapida, ma tre cose messe a posto prima: si sapeva quale sito gira su quale versione di PHP, si sapeva chi risponde dell’aggiornamento, e c’erano backup dai quali si era davvero verificato che il sito si può ripristinare. Nessuna delle tre si può fare il giorno in cui l’avviso è già pubblicato, e proprio per questo questa settimana per alcuni team è stata mezz’ora di lavoro e per altri due giorni.

Se da questa settimana va preso un solo compito, perché la prossima volta sia più facile, quel compito è un elenco: ogni sito, la sua versione di PHP, il modo in cui viene eseguito, il suo fornitore di hosting e la persona che può premere «aggiorna». Il prossimo avviso di questo tipo arriverà, e l’unica domanda è quanto tempo servirà allora per rispondere alla domanda «riguarda noi».