PHP rilascia patch d'emergenza il 21 ottobre per bloccare rischi RCE
- Rilasciate patch d'emergenza per PHP (versioni 8.2, 8.3, 8.4, 8.5) per bloccare due vulnerabilità critiche.
- Rischio massimo per server Apache che utilizzano mod_php: l'attacco può avvenire prima dell'esecuzione del codice del sito.
- Istituzioni in Finlandia e Olanda hanno spento preventivamente i servizi web per evitare intrusioni.
- I WAF non sono sostituti della patch; l'aggiornamento del core PHP è l'unica soluzione definitiva.
Il 21 ottobre 2026, il team di sicurezza di PHP ha rilasciato aggiornamenti d'emergenza per contrastare due vulnerabilità critiche che espongono milioni di server a rischi di Remote Code Execution (RCE). Le falle permettono a un attaccante di eseguire codice arbitrario sui server senza necessità di autenticazione, bypassando i normali controlli di accesso. Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
Due vulnerabilità critiche per milioni di server
La gravità di queste falle risiede nella loro natura: non richiedono che l'attaccante sia loggato nel sistema per compromettere l'infrastruttura. Secondo quanto riportato da Search Engine Journal, tutte le installazioni che servono richieste web sono potenzialmente a rischio. Questo significa che qualsiasi applicazione basata su PHP, inclusi i siti gestiti con WordPress, è vulnerabile se il server sottostante non è aggiornato.
Analisi strategica: Per un imprenditore, questo scenario evidenzia la fragilità della catena di fornitura software. Spesso l'attenzione è rivolta all'aggiornamento del CMS (come WordPress) o dei plugin, ma la vulnerabilità risiede nello strato inferiore, il linguaggio di programmazione stesso. Se il core PHP è compromesso, nessuna misura di sicurezza a livello applicativo può garantire l'integrità dei dati, poiché l'attaccante opera a un livello di privilegio superiore rispetto al codice del sito.
Perché il mod_php è il punto più fragile
Sebbene l'intera superficie di attacco sia vasta, l'architettura di Apache che utilizza mod_php rappresenta il vettore di rischio più elevato. In questa configurazione, PHP viene eseguito direttamente all'interno del processo di Apache, creando un legame simbiotico che gli attaccanti possono sfruttare.
Il pericolo specifico è che un attacco dimostrato può essere eseguito prima ancora che il codice specifico del sito web inizi a girare. Questo rende inutile qualsiasi controllo di sicurezza implementato all'interno del framework dell'applicazione o del tema utilizzato. L'attaccante colpisce il motore di esecuzione, non la pagina web.
Il panic delle istituzioni finlandesi e olandesi
La reazione di alcuni governi europei ha anticipato la gravità della situazione. Prima ancora che le patch fossero pienamente diffuse, diverse infrastrutture critiche hanno scelto la via della prevenzione estrema: lo spegnimento dei servizi.
International Cyber Digest ha segnalato che i siti web del parlamento olandese, dell'agenzia per la cybersicurezza dei Paesi Bassi, nonché i servizi web del governo finlandese e diversi siti universitari, sono stati portati offline. Nel caso della Finlandia, lo shutdown è stato descritto come una misura precauzionale e non come la conseguenza di una violazione già avvenuta.
Questa mossa riflette l'allarme lanciato anche dal National Cyber Security Centre del Regno Unito, che ha suggerito una linea d'azione drastica: 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'.
L'illusione della protezione tramite WAF
In situazioni di emergenza, molte aziende tendono a fare affidamento sui Web Application Firewall (WAF) per filtrare il traffico malevolo e mitigare l'attacco senza dover riavviare i server o aggiornare il software. Tuttavia, in questo caso, tale strategia è insufficiente.
Il team di PHP è stato categorico: l'aggiornamento è l'unica scelta sicura. Un firewall o un semplice cambio di configurazione non possono sostituire la patch del core. Sebbene i provider di hosting possano implementare regole WAF per ridurre il rumore degli attacchi, queste rimangono misure palliative. La vulnerabilità risiede nella gestione della memoria o nell'elaborazione dei dati a livello di linguaggio; un WAF può bloccare payload noti, ma non può correggere l'errore logico interno al binario di PHP.
Patch emergency: chi deve fare cosa
La risoluzione del problema richiede un intervento coordinato tra proprietari di siti e provider di infrastrutture. È fondamentale comprendere che aggiornare WordPress non aggiorna PHP.
| Soggetto | Azione Richiesta | Verifica |
|---|---|---|
| Proprietario Sito (Client) | Contattare l'hosting per confermare l'installazione delle patch 8.2.35, 8.3.36, 8.4.27 o 8.5.12. | Controllare in WordPress: Strumenti > Salute del sito > Info > Server. |
| Web Host / System Admin | Aggiornare le versioni di PHP supportate. Per versioni EOL (7.4, 8.0, 8.1), applicare i limited source fixes. | Verificare la versione attiva tramite cPanel o riga di comando. |
| Aziende con versioni EOL | Pianificare l'upgrade immediato a PHP 8.2 o superiore. Valutare l'offline temporaneo del server. | Confermare la compatibilità del codice con le nuove versioni di PHP. |
Per chi gestisce server in autonomia, è possibile consultare l'annuncio ufficiale su WordPress.org per coordinare l'aggiornamento.
La manutenzione del parco software europeo tra NIS2 e debito tecnico
L'episodio delle vulnerabilità PHP mette a nudo un problema sistemico dell'industria digitale europea: il debito tecnico. Milioni di siti continuano a girare su versioni di PHP (come la 7.4 o la 8.0) che sono ufficialmente End-of-Life (EOL) e non ricevono più aggiornamenti regolari. Per queste versioni, il team di PHP ha fornito solo correzioni limitate al codice sorgente per chi compila il software autonomamente, lasciando scoperti migliaia di piccoli e medi imprenditori che si affidano a hosting economici o configurazioni datate.
Analisi geopolitica e normativa: L'entrata in vigore della direttiva NIS2 impone standard di cybersecurity molto più rigidi per le entità essenziali e importanti. La gestione delle patch non è più solo una questione tecnica, ma un obbligo di compliance. Un'azienda che ignora l'aggiornamento del core PHP, esponendo i dati dei clienti a un RCE, potrebbe essere considerata negligente ai sensi della nuova normativa europea.
Il mercato italiano, caratterizzato da un'alta densità di PMI che utilizzano soluzioni web legacy, è particolarmente esposto. La tendenza a 'non toccare ciò che funziona' si scontra con una superficie di attacco che evolve rapidamente. L'indicatore verificabile per l'efficacia della risposta europea sarà il tasso di adozione di PHP 8.2+ nei prossimi sei mesi: se la quota di server EOL rimarrà invariata, assisteremo a un'ondata di compromissioni di massa non appena i payload per queste falle diventeranno pubblici e automatizzati.
Per approfondire i dettagli tecnici della vulnerabilità, è possibile consultare l'analisi di SOC Prime.
Domande frequenti
Aggiornare WordPress risolve il problema?
No. PHP è il linguaggio che fa girare WordPress sul server. L'aggiornamento del CMS non aggiorna la versione di PHP installata dall'hosting.
Il mio sito è a rischio se uso un WAF?
Sì. Il WAF può mitigare alcuni attacchi, ma PHP ha dichiarato che non è un sostituto della patch. Solo l'aggiornamento del software elimina la vulnerabilità.
Cosa fare se il mio sito usa PHP 7.4 o 8.0?
Queste versioni sono End-of-Life. Dovresti aggiornare immediatamente a una versione supportata (8.2+) o, se non è possibile nell'immediato, considerare di portare il sito offline per evitare intrusioni.
Fonti: Searchenginejournal, Wordpress, Socprime ·
glacom · Adopt glacom: il software che nessuno mantiene piu', lo prendiamo in carico noi →Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
