Il team di sicurezza di PHP ha pubblicato oggi, 21 ottobre, una correzione per due vulnerabilità, entrambe con un punteggio di 9,2 su 10. Era prevista per le 10:00 (ora della costa est degli Stati Uniti) ed è uscita in anticipo.
I ricercatori di sicurezza chiamano la coppia PHP2Shell. I nomi ufficiali sono CVE-2026-109618 e CVE-2026-109619.
Se il suo sito web funziona con WordPress o Drupal, funziona con PHP.
Aggiornamento, 9:36 (ora della costa est degli Stati Uniti): la correzione è uscita
PHP ha rilasciato la correzione in anticipo. L'abbiamo vista su php.net alle 9:36 (ora della costa est degli Stati Uniti).
Aggiorni a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. PHP 8.1 e precedenti non ricevono aggiornamenti dal progetto PHP. Alcune distribuzioni Linux e fornitori di supporto riportano la correzione, quindi chieda al suo, oppure passi a una versione supportata.
Con il rilascio, PHP ha pubblicato qual è davvero il problema. In parole semplici:
- Entrambi i difetti stanno nel modo in cui PHP prepara e ripulisce ogni richiesta web. Uno si verifica quando PHP esaurisce la memoria a metà della preparazione di una richiesta: la pulizia può allora trattare dati costruiti a metà come validi. L'altro lascia i dati di una richiesta dopo che la loro memoria è stata liberata, e la richiesta successiva sullo stesso processo può usarli.
- Ognuno dei due può permettere a uno sconosciuto di eseguire il proprio codice sul suo server, senza accedere, inviando richieste costruite apposta.
- Riguarda PHP quando serve pagine web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP dice che il rischio è più alto con mod_php di Apache, per cui ha un attacco funzionante.
- Avviene prima che il codice del suo sito venga eseguito. Quindi un plugin di sicurezza dentro WordPress o Drupal non può vederlo. A proteggerla sono l'aggiornamento e i limiti applicati davanti a PHP.
PHP elenca anche impostazioni che riducono l'esposizione se non può aggiornare subito, e precisa che non rendono sicuro un server. Sono nell'avviso su php.net.
Perché LFW.com non è mai stato esposto: questi difetti stanno nel codice che viene eseguito quando PHP gestisce una richiesta. Le pagine di LFW.com sono file generati in anticipo, e sui nostri server nessun PHP legge alcuna richiesta, quindi non c'è niente da attivare. Le copie in sola lettura pubblicate stamattina dai governi europei sono al sicuro per lo stesso motivo.
Se ha messo offline un sito, può tornare online appena il suo hosting conferma che usa una delle versioni corrette.
Cosa abbiamo controllato sui nostri server
Stamattina siamo partiti dalla nostra infrastruttura.
- LFW.com: non è interessato. È costruito con Astro e servito da Node.js, e sui nostri server PHP non è installato.
- Una demo di WordPress: abbiamo trovato una demo di WordPress in un container che avevamo fermato circa tre settimane fa e mai rimosso. Non era in esecuzione ed era protetta da password. L'abbiamo rimossa comunque, con il suo database e le sue immagini.
- Le nostre macchine di sviluppo: le copie locali di WordPress che usiamo per lo sviluppo sono ferme, e nessuna è raggiungibile da internet.
La demo è la parte che vale la pena raccontare. Oggi non aveva nessun problema. Era semplicemente un sito con PHP che non ci serviva più, ed era ancora lì.
Il sito che nessuno ricorda
In una giornata così, il sito principale di solito viene aggiornato. Qualcuno ne è responsabile e qualcuno lo tiene d'occhio.
Il rischio sta più spesso in un sito che nessuno ricorda di avere:
- il microsito di una campagna finita
- la copia di prova che un fornitore ha preparato per un restyling
- il sito di un evento di qualche anno fa
- una demo o un'installazione di prova mai rimossa
Quei siti funzionano ancora con PHP, e nessuno sta aspettando l'aggiornamento.
Cosa faremmo oggi
In quest'ordine:
- Controlli prima il suo hosting. Con un hosting gestito, guardi la sua pagina di stato o il suo blog. In una giornata così la maggior parte pubblica il proprio piano, e molti aggiornano PHP per lei, quindi potrebbe non doverli contattare.
- Faccia l'elenco di ogni sito con PHP. Compresi quelli dimenticati. Rimuova quelli che non usa.
- Aggiorni gli altri il giorno stesso della correzione. Chieda a chi gestisce ogni sito di avvisarla quando è fatto.
- Tenga un firewall davanti fino ad allora. Un firewall per applicazioni web aiuta solo se il server rifiuta il traffico che non passa da lì, quindi controlli anche questa impostazione.
Spegnere il server
Il Centro nazionale per la cibersicurezza del Regno Unito dice che, se non può aggiornare né applicare le soluzioni temporanee di PHP, deve valutare di mettere offline il sistema finché non può farlo. Vista la gravità segnalata, non è un cattivo consiglio, anche se può sembrare eccessivo.
Spegnere il server non deve per forza spegnere il sito. Nel frattempo può pubblicare una copia in sola lettura: pagine statiche, senza PHP dietro.
- I cittadini possono continuare a leggere le pagine e trovare i numeri di telefono.
- Moduli, accessi e ricerche aspettano che l'aggiornamento sia installato.
- La copia viene tolta quando torna il sito aggiornato.
Per un sito pubblico su cui le persone contano, è una via di mezzo migliore di una pagina bianca.
Diversi governi hanno messo offline dei siti stamattina
Diversi governi hanno deciso che qualche ora offline valeva la pena.
Ecco cosa abbiamo visto alle 8:50 (ora della costa est degli Stati Uniti):
- Il Centro nazionale per la cibersicurezza dei Paesi Bassi ha messo offline il proprio sito, NCSC.nl, per precauzione.
- DigiD e MijnOverheid, l'accesso del governo olandese e il suo portale per i cittadini, mostravano pagine di "temporaneamente non disponibile".
- L'Università di Vienna ha spento i suoi siti web, i moduli online, la webmail e Moodle.
- Il sito della Camera dei rappresentanti olandese non si è caricato affatto. NL Times ha riferito che anche quello è stato messo offline.
- Il centro informatico del governo finlandese, Valtori, ha bloccato per precauzione il traffico internet in entrata verso i servizi pubblici dello Stato, e lo ha spiegato sul suo sito. Ha aggiunto che l'interruzione non è stata causata da un attacco.
Non c'è niente di cui vergognarsi. Sono poche ore, e il problema è abbastanza grave che l'agenzia il cui mestiere è la cibersicurezza l'ha scelto per il proprio sito.
Cosa hanno chiesto le agenzie di cibersicurezza
Non è stata solo l'Europa. Agenzie nazionali di cibersicurezza di tre continenti hanno pubblicato avvisi lo stesso giorno, e nella sostanza sono d'accordo:
- Regno Unito: il Centro nazionale per la cibersicurezza chiede di trovare tutti i sistemi con PHP, aggiornare e valutare di mettere offline un sistema se non si può.
- Unione europea: il CERT-EU, che protegge le istituzioni stesse dell'UE, ha consigliato di isolare le applicazioni esposte a internet dove non si può aggiornare subito.
- Singapore: l'Agenzia per la cibersicurezza chiede di aggiornare subito e di cercare PHP su ogni server web, anche dove il sito principale non lo usa.
- Australia: il Centro australiano per la cibersicurezza ha invitato le organizzazioni a individuare PHP nei propri sistemi, prepararsi ad aggiornare e controllare i segnali di attacco.
Il punto di Singapore è quello che sottolineeremmo. Un sito costruito con altro può comunque avere PHP sullo stesso server: un vecchio strumento di amministrazione, un'installazione dimenticata, un componente aggiuntivo di un fornitore.
Cosa hanno fatto bene le loro pagine offline
Guardi bene quelle pagine. Non sono vuote e non sono messaggi di errore.
- Dicono perché. Ognuna indica le vulnerabilità di PHP come motivo.
- Dicono cosa è spento. Vienna elenca ogni servizio, così nessuno deve indovinare.
- Dicono dove andare. L'NCSC rimanda al suo sito di avvisi, a LinkedIn e a un indirizzo email attivo 24 ore su 24 per l'aiuto urgente.
- Sono pagine statiche. Non serve PHP per mostrarle, ed è per questo che sono ancora online.
Quest'ultimo punto è tutta l'idea della copia in sola lettura. Queste pagine ne sono la versione più piccola.
Scriva quella pagina prima che serva
Niente di tutto questo è difficile in una giornata tranquilla. È difficile alle 6 del mattino del giorno di un rilascio di sicurezza.
Quindi conviene decidere alcune cose adesso, finché va tutto bene:
- Chi può mettere offline il sito, e chi avvisa. Un nome e un sostituto.
- La pagina offline stessa, scritta e conservata in un posto che non usa PHP: il motivo, cosa è spento, dove seguire gli aggiornamenti e come raggiungere una persona.
- Quali pagine non possono mai spegnersi. Avvisi di emergenza, avvisi di bollire l'acqua, i numeri di telefono. Vanno nella copia in sola lettura.
- Come saprà che si può tornare online. Di solito: il suo hosting conferma la versione corretta e lei controlla una pagina di persona.
Qualche ora offline, pianificata, è una buona giornata. Non pianificata, è una notizia.
Se le serve una mano
Siamo felici di aiutarla con uno qualsiasi di questi passi, che si tratti di trovare i siti dimenticati o di pubblicare una copia in sola lettura. Ci scriva.
Leland Fiegel