21 ottobre 2026 | PHP | Sicurezza informatica
Il 21 ottobre 2026 il team di sicurezza di PHP ha pubblicato aggiornamenti per tutte le versioni di PHP ancora supportate. Essi correggono due vulnerabilità critiche diventate note come PHP2Shell. Il BSI ha emesso al riguardo un'allerta e chiede di applicare immediatamente la patch ai sistemi interessati. Chi gestisce un web server con PHP dovrebbe agire oggi stesso. Questo vale anche per chi gestisce «soltanto» un WordPress, un Nextcloud o un Joomla, perché queste applicazioni girano su PHP.
Questo articolo riassume che cosa è successo, quali versioni di PHP sono interessate, di quale versione avete bisogno ora e come verificare in pochi minuti se il vostro server è protetto.
Contenuto di questo articolo
- Che cosa è successo? La cronologia
- Le due vulnerabilità di PHP in sintesi
- Chi è interessato?
- Queste versioni di PHP sono sicure
- Come verificare e aggiornare il vostro server
- PHP 8.1 e precedenti: nessun aggiornamento ufficiale
- Misure transitorie e la questione «mettere il server offline?»
- Domande frequenti
- Supporto da parte di Biricon IT Services
Che cosa è successo? La cronologia
Il team di sicurezza di PHP ha annunciato in anticipo la pubblicazione delle correzioni, in modo che hoster e amministratori avessero il tempo di prepararsi. La pubblicazione stessa è avvenuta il 21 ottobre 2026. Il BSI ha emesso la propria allerta (versione 1.1) lo stesso giorno.
- 20 ottobre 2026: preavviso del team di sicurezza di PHP che il giorno seguente sarebbero usciti aggiornamenti di sicurezza.
- 21 ottobre 2026, 14:00 UTC (ore 16:00 CEST): vengono pubblicate le patch per PHP 8.5, 8.4, 8.3 e 8.2.
- 21 ottobre 2026: il BSI avverte delle «vulnerabilità critiche che minacciano le applicazioni web in tutto il mondo» e raccomanda di applicare immediatamente la patch. Secondo il BSI, grandi fornitori di hosting hanno in parte messo precauzionalmente offline dei server.
Le due vulnerabilità di PHP in sintesi
Si tratta di due errori distinti nel nucleo di PHP: CVE-2026-109618 e CVE-2026-109619. Secondo il team di sicurezza di PHP, entrambi possono far sì che un aggressore esegua codice sul server senza autenticarsi (unauthenticated Remote Code Execution). Le vulnerabilità sono valutate CVSS v4.0: 9,2 (critica).
| Caratteristica | Significato |
|---|---|
| Identificativi | CVE-2026-109618 e CVE-2026-109619 |
| Valutazione | CVSS v4.0: 9,2 — critica |
| Impatto | Esecuzione di codice sul server (Remote Code Execution), senza autenticazione |
| Causa 1 | Memoria danneggiata quando PHP durante l'elaborazione non dispone più di memoria di lavoro (Out-of-Memory) |
| Causa 2 | Stato globale obsoleto che resta in memoria tra una richiesta e l'altra |
| Particolarmente a rischio | Apache con mod_php |
Secondo la valutazione del BSI, al momento della pubblicazione non risultavano attacchi confermati, ma vi erano indizi non confermati di tentativi di sfruttamento. In caso di falle critiche in un software così diffuso, l'esperienza insegna che ci si deve aspettare che gli aggressori analizzino le correzioni e preparino attacchi automatizzati. La finestra temporale per applicare la patch è perciò breve.
Chi è interessato?
È interessato in linea di principio ogni server su cui gira PHP, indipendentemente da come PHP è integrato: PHP-FPM, mod_php in Apache, php-cgi, FrankenPHP o LiteSpeed. Secondo il team di sicurezza di PHP il rischio è massimo con Apache con mod_php.
Il BSI cita espressamente applicazioni che si basano su PHP e che possono quindi essere coinvolte:
- Sistemi di gestione dei contenuti: WordPress, Drupal, TYPO3, Joomla
- Sistemi di negozio: Magento
- Cloud e archiviazione di file: Nextcloud
- Interfacce di firewall: pfSense, OPNsense
L'applicazione stessa non deve essere difettosa. La falla è in PHP, per questo un aggiornamento di WordPress, Nextcloud & Co. da solo non aiuta. Occorre aggiornare la versione di PHP sul server. Con firewall come pfSense e OPNsense la versione corretta di PHP arriva tramite il rispettivo aggiornamento del firmware del produttore.
Queste versioni di PHP sono sicure
Le vulnerabilità sono corrette nelle seguenti versioni. Tutto ciò che è inferiore è considerato vulnerabile.
| Ramo PHP | Minimo richiesto | Nota |
|---|---|---|
| PHP 8.5 | 8.5.12 | ramo attuale |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Il supporto termina il 31 dicembre 2026 |
| PHP 8.1 e precedenti | nessun aggiornamento ufficiale, vedi in basso | |
Come verificare e aggiornare il vostro server
1. Individuare la versione di PHP installata
Sulla riga di comando del server, php -v mostra la versione di PHP da riga di comando. Il web server può utilizzare una versione di PHP diversa. Verificate perciò anche la versione di PHP-FPM ovvero del modulo Apache, ad esempio con php-fpm8.3 -v o tramite una pagina che emette phpinfo() (da rimuovere subito dopo).
2. Installare l'aggiornamento tramite il gestore di pacchetti
Con Debian, Ubuntu, RHEL e derivate la versione corretta arriva tramite il normale gestore di pacchetti, ad esempio apt update && apt upgrade o dnf upgrade. Con fonti esterne come il PPA Sury o il repository Remi i nuovi pacchetti compaiono di solito tempestivamente.
apt changelog php8.3-fpm o rpm -q --changelog php | grep CVE-2026-1096).
3. Riavviare il servizio PHP
Un aggiornamento del pacchetto da solo non basta: i processi PHP in esecuzione mantengono in memoria il vecchio codice. Riavviate PHP-FPM (systemctl restart php8.3-fpm) ovvero Apache (systemctl restart apache2) e verificate poi che i processi siano stati avviati dopo l'aggiornamento.
4. Siti web in hosting
Con lo shared hosting l'aggiornamento è di norma a cura del fornitore. Nel menu clienti si può di solito impostare la versione di PHP per ogni sito web. Scegliete lì una delle versioni sicure sopra indicate, oppure chiedete al fornitore lo stato delle patch. Secondo il BSI singoli fornitori hanno scollegato precauzionalmente dei server dalla rete. Se il vostro sito è brevemente irraggiungibile, può esserne questa la causa.
PHP 8.1 e precedenti: nessun aggiornamento ufficiale
Per PHP 8.1 e precedenti non esistono più aggiornamenti di sicurezza ufficiali. I gestori di tali sistemi hanno due possibilità:
- Passare a una versione supportata (raccomandato). Quanto più vecchia è la versione, tanto maggiore è l'onere di adeguamento per applicazione ed estensioni, perciò il passaggio dovrebbe essere testato prima.
- Eseguire il backport delle correzioni. Il team di sicurezza di PHP ha messo a disposizione le correzioni nei rami di sviluppo su GitHub. Chi compila PHP da sé può riportare queste modifiche nelle versioni più vecchie. È una soluzione transitoria e richiede competenze specialistiche.
Anche PHP 8.2 è supportato solo fino al 31 dicembre 2026. Pianificate perciò ora il passaggio a PHP 8.4 o 8.5 e non rimandatelo al cambio d'anno.
Misure transitorie e la questione «mettere il server offline?»
Con l'annuncio il team di sicurezza di PHP ha descritto anche misure di protezione provvisorie. Queste riducono il rischio, ma non chiudono completamente le falle. Non sostituiscono l'aggiornamento e sono pensate solo per colmare il tempo fino all'aggiornamento.
Se un server debba essere scollegato dalla rete fino all'aggiornamento dipende dalla sua importanza e dalla sua raggiungibilità. Il BSI spiega che i grandi fornitori hanno compiuto questo passo. Come regola empirica vale:
- Server raggiungibile pubblicamente, aggiornamento possibile ora: applicare subito la patch, nessuno spegnimento necessario.
- Server raggiungibile pubblicamente, aggiornamento non possibile a breve: limitare l'accesso (ad esempio tramite firewall solo per indirizzi noti) o spegnere temporaneamente il servizio, soprattutto con
mod_php. - Server raggiungibile solo internamente: applicare la patch in tempi brevi, l'urgenza è minore.
Domande frequenti
Devo aggiornare WordPress, Joomla o Nextcloud?
Non a causa di questa vulnerabilità. Si trova in PHP, non nell’applicazione. Aggiorni la versione di PHP sul server. Un aggiornamento dell’applicazione è comunque consigliabile, indipendentemente da ciò.
Come posso capire se qualcuno ha già sfruttato la vulnerabilità?
È difficile dare una risposta certa. Sono segnali sospetti file PHP sconosciuti nella directory web, processi insoliti sotto l’utente del web server, nuovi account utente o cronjob e traffico in uscita anomalo. In caso di sospetto concreto, il sistema dovrebbe essere sottoposto a un’analisi forense e, nel dubbio, reinstallato.
Basta un Web Application Firewall?
Un firewall può bloccare schemi di attacco noti, ma non sostituisce l’aggiornamento. Per approfondire l’interazione di più livelli di protezione, legga il nostro articolo Proteggere Odoo 19: firewall, 2FA & Web RBL. I principi valgono per qualsiasi applicazione web.
Odoo è interessato?
No. Odoo è scritto in Python e non gira su PHP. Sarebbero interessate solo le applicazioni PHP in esecuzione sullo stesso server.
Dove trovo le informazioni ufficiali?
L’annuncio del team di sicurezza di PHP è disponibile negli archivi delle news su php.net (voce del 20 ottobre 2026), le versioni su php.net/downloads. L’avviso del BSI porta il numero 2026-297981-1032 ed è pubblicato su bsi.bund.de .
Supporto da parte di Biricon IT Services
Se non è sicuro di quale versione di PHP giri sul Suo server o se ha bisogno di aiuto con le patch, saremo lieti di supportarLa: nella ricognizione di tutti i sistemi PHP, nell’installazione degli aggiornamenti, nel passaggio a una versione di PHP supportata e nel controllo di eventuali compromissioni. Come fornitore di servizi IT assistiamo server, firewall e applicazioni web per piccole e medie imprese.
Aggiornato al 21 ottobre 2026. La situazione può cambiare rapidamente; fanno fede le pubblicazioni del team di sicurezza di PHP e del BSI.