PHP, falla di sicurezza: perché il 70% dei siti web deve aggiornarsi subito

Un aggiornamento rimandato di qualche ora può diventare la porta d’ingresso a un server intero. Non a una pagina rotta, non al solito plugin da disattivare. Al server. File, database, credenziali, malware: tutto potenzialmente alla portata di chi riesce a sfruttare due vulnerabilità appena emerse in PHP.

E il punto è questo: PHP non vive in un angolo remoto del web. Sta dietro WordPress, Drupal, Joomla, Magento, pannelli di hosting condiviso e una quantità enorme di applicazioni che nessuno pensa di controllare finché non succede qualcosa. Secondo i dati citati da SiteGround e W3Techs, il linguaggio gira sul 69,3% dei siti di cui si conosce la tecnologia lato server. Tradotto: quasi sette siti su dieci.

Non è allarmismo da titolo rosso. Le autorità di cybersicurezza di Stati Uniti, Regno Unito, Unione europea, Australia e Giappone hanno invitato le organizzazioni ad aggiornare subito oppure, se non possono farlo, a spegnere temporaneamente i sistemi esposti. Una scelta drastica, sì. Ma quando il rischio riguarda l’esecuzione di codice da remoto, tenere online un servizio vulnerabile assomiglia un po’ a lasciare la chiave nella serratura. Con un cartello sopra.

Due buchi, un rischio enorme

Le falle vengono descritte come vulnerabilità di Remote Code Execution, spesso abbreviato in RCE. È una delle espressioni che un amministratore di sistema non vuole leggere alle 7:42 del mattino, con il caffè ancora troppo caldo e una notifica di sicurezza sul telefono.

In parole semplici: un aggressore potrebbe eseguire comandi sul server da remoto, senza autenticarsi. Quindi senza dover conoscere username e password. Da lì il salto può essere brutto: installare codice malevolo, leggere file di configurazione, raggiungere database, rubare dati o usare la macchina per colpire qualcun altro.

Non significa che ogni portale PHP sia già compromesso. Sarebbe scorretto dirlo. Significa però che una macchina non aggiornata può diventare attaccabile, e che le prime ondate di attività ostili sarebbero già state osservate. Dane Knecht, responsabile tecnologico di Cloudflare, ha scritto su X che l’azienda stava rilevando attacchi iniziali e aggiornando le difese man mano che comparivano nuovi vettori.

“Stiamo osservando attacchi iniziali emergenti e stiamo aggiornando le mitigazioni man mano che appaiono nuovi vettori”, ha avvertito Dane Knecht di Cloudflare.

E qui c’è una regola vecchia quanto l’IT: quando i dettagli tecnici di una falla circolano, il tempo lavora contro chi deve mettere la patch. Non contro chi attacca. Contro chi deve aggiornare.

Lo schema, senza giri di parole

Schema del possibile attacco

Server PHP non aggiornato → richiesta malevola inviata via rete → esecuzione di comandi indesiderati → accesso a file e database → furto dati, malware o blocco del sito.

Il passaggio più inquietante è il secondo. L’aggressore non deve entrare dalla porta principale, diciamo. Può cercare un difetto nel muro e infilarsi da lì. Se la vulnerabilità consente davvero RCE senza autenticazione, quella crepa non richiede nemmeno un badge all’ingresso.

Secondo le informazioni diffuse nelle fonti disponibili, le due falle sono identificate come CVE-2026-109618 e CVE-2026-109619, con un punteggio di rischio CVSS v4.0 pari a 9,2 su 10. Un valore molto alto. Non il classico problema che si mette nella lista “da fare venerdì”.

Perché PHP è un bersaglio così grosso

PHP ha più di trent’anni e continua a reggere una fetta gigantesca della rete. È open source, è diffuso, è integrato dappertutto. E proprio questa presenza capillare cambia la scala del problema.

Un difetto in un singolo plugin WordPress colpisce chi usa quel plugin. Un difetto nel linguaggio può toccare hoster, e-commerce, siti istituzionali, gestionali, intranet esposte male, vecchi applicativi aziendali. Perfino software che il proprietario del sito non associa affatto a PHP. Boh, è il lato invisibile dell’infrastruttura: funziona per anni, silenzioso. Poi arriva l’avviso.

Huntress lo ha spiegato alla BBC in modo molto netto: PHP alimenta WordPress, Drupal, Joomla e Magento, ma anche piattaforme di hosting condiviso e pannelli di controllo. La parte scomoda è proprio questa. Molti proprietari non aggiornano direttamente PHP; dipendono dal provider, da un’agenzia, da un reparto IT esterno o da un’applicazione legacy che nessuno vuole toccare perché “poi salta tutto”.

Capita. Ma il rinvio costa caro quando la falla riguarda il motore, non la carrozzeria.

Le versioni coinvolte: qui serve attenzione

Le informazioni iniziali non sono del tutto sovrapponibili. Il CERT-EU avrebbe indicato una possibile esposizione delle versioni a partire da PHP 5, linguaggio lanciato nel 2004. Altre fonti citate, invece, parlano di server con PHP 5.4 o versioni successive.

Non è una sfumatura da poco. PHP 5 e le sue varianti più vecchie non ricevono supporto da anni, quindi un aggiornamento ordinario potrebbe non bastare nemmeno in teoria. Se gestisci un ambiente datato, non fare supposizioni basandoti sul numero della versione che “dovrebbe essere sicura”. Controlla l’avviso del tuo hosting, la documentazione del team PHP e le indicazioni delle autorità competenti.

Le release correttive indicate nelle fonti disponibili sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Però qui vale una precauzione banale ma fondamentale: verifica il pacchetto distribuito dal tuo sistema operativo o dal tuo provider. Su una VPS Ubuntu, su cPanel, su Plesk o su un hosting gestito, il nome dell’aggiornamento e i tempi di disponibilità possono cambiare.

Quando perfino le istituzioni staccano la spina

La gravità della situazione si legge anche nelle decisioni prese fuori dal mondo dei blog tech. Il governo finlandese, il Parlamento olandese e il consiglio di Edimburgo avrebbero messo temporaneamente offline alcuni servizi web per precauzione, in attesa della correzione.

In Germania, l’Ufficio federale per la sicurezza informatica ha classificato il rischio al livello 3 / Arancione, quindi estremamente elevato. L’allerta avrebbe spinto diverse organizzazioni, inclusi ospedali, a