Vulnerabilità critiche di PHP (CVE-2026-109618 e CVE-2026-109619): come proteggere i server Bare Metal e VPS
Il 21 ottobre 2026 il progetto PHP ha pubblicato patch importanti per due vulnerabilità critiche. Se PHP è in esecuzione su uno dei suoi server dedicati Bare Metal o VPS, ecco come verificare la sua esposizione e proteggersi, passo dopo passo.
Questo articolo è rivolto ai nostri clienti con server dedicati e VPS. I clienti Web Cloud e di hosting condiviso riceveranno automaticamente un componente PHP aggiornato.
L’essenziale in sintesi
| Elemento | Dettaglio |
|---|---|
| Le vulnerabilità | CVE-2026-109618 e CVE-2026-109619 |
| Il rischio | Presa di controllo del server da remoto, senza credenziali |
| Gravità | Critica (CVSS 9,2 su 10) |
| Versioni vulnerabili | Tutte le versioni di PHP precedenti a PHP 7.4 |
| Versioni corrette | 8.2.35, 8.3.36, 8.4.27 e 8.5.12 |
| Il nostro consiglio | Aggiornare PHP senza ulteriori ritardi, poi riavviare i servizi PHP |
Cosa sta succedendo, spiegato in modo semplice
Le due vulnerabilità riguardano il cuore di PHP, non un CMS o un framework in particolare. Riguardano il modo in cui PHP gestisce la memoria tra due richieste:
- CVE-2026-109618: una richiesta volutamente troppo pesante (l’invio di un modulo, ad esempio) porta PHP a esaurire la memoria e a lasciare dati in uno stato incoerente.
- CVE-2026-109619: informazioni di una richiesta precedente restano in memoria anziché essere cancellate e vengono riutilizzate dalla richiesta successiva.
In entrambi i casi un attaccante può eseguire il proprio codice sul suo server, con i privilegi del suo server web. Non ha bisogno di account né di password: basta una connessione al suo sito. I ricercatori hanno dimostrato lo sfruttamento, in particolare con Apache (mod_php) e PHP-FPM, le due configurazioni più diffuse.
È coinvolto? Verifichi in due minuti
È coinvolto in particolare se PHP serve un sito o un’applicazione su uno dei suoi server Bare Metal (Kimsufi, So you Start, Rise, Advance, Scale, High Grade) o su un VPS OVHcloud.
Si connetta in SSH e digiti:
php -v
Confronti il risultato con questa tabella:
| Cosa fare | La tua versione |
|---|---|
| Aggiornare alla 8.5.12 | 8.5.x |
| Aggiornare alla 8.4.27 | 8.4.x |
| Aggiornare alla 8.3.36 | 8.3.x |
| Aggiornare alla 8.2.35 | 8.2.x |
| Aggiornare alle versioni CVE-2026-109618-109619. Tenga presente che per le versioni 7.4, 8.0 e 8.1 è necessaria una ricompilazione | Dalla 8.1.x alla 7.4 |
| Il progetto PHP non pubblicherà alcuna patch: le consigliamo di pianificare una migrazione verso una versione supportata (nel frattempo i nostri team stanno valutando altre opzioni) | Inferiore alla 7.4 |
Buono a sapersi: la versione mostrata da riga di comando può essere diversa da quella utilizzata dal suo sito, soprattutto se sono installate più versioni di PHP. In caso di dubbio, verifichi anche la versione nella configurazione del suo server web o del suo pannello di amministrazione (Plesk, cPanel…).
Aggiornare passo dopo passo
L’aggiornamento non dovrebbe richiedere più di una quindicina di minuti per server. Le consigliamo di iniziare dai server accessibili da Internet.
Esegua un backup. Su un VPS è sufficiente uno snapshot dallo Spazio Cliente OVHcloud. Su un server Bare Metal, salvi almeno i file di configurazione e i dati.
Aggiorni i pacchetti PHP con il gestore di pacchetti della sua distribuzione:
- Debian / Ubuntu:
sudo apt update && sudo apt upgrade - AlmaLinux / Rocky Linux:
sudo dnf upgrade - PHP compilato dai sorgenti: scarichi la versione corretta su php.net
- Container Docker: ricostruisca le immagini a partire da un’immagine PHP aggiornata, quindi le ridistribuisca
Riavvii i servizi PHP. È il passaggio dimenticato più spesso: senza riavvio, la vecchia versione continua a girare in memoria.
- PHP-FPM:
sudo systemctl restart php8.x-fpm(Debian/Ubuntu, sostituendo x con la sua versione) oppuresudo systemctl restart php-fpm - Apache:
sudo systemctl restart apache2oppuresudo systemctl restart httpd
Verifichi con php -v che la versione corretta sia attiva e che il sito funzioni normalmente.
Se la sua distribuzione non offre ancora la versione corretta, ricontrolli regolarmente: alcuni repository pubblicano gli aggiornamenti con qualche ora di ritardo. Nel frattempo, applichi le misure temporanee indicate di seguito.
Non può aggiornare subito?
Il progetto PHP è chiaro: solo l’aggiornamento protegge completamente il server. Le seguenti impostazioni, tratte dagli avvisi ufficiali, riducono il rischio nel frattempo. Vanno inserite nel php.ini e richiedono poi un riavvio di PHP-FPM o di Apache.
- Disattivi il monitoraggio dell’avanzamento dei caricamenti di file:
session.upload_progress.enabled = 0. Questa funzione è usata di rado e PHP consiglia di lasciarla disattivata anche dopo l’aggiornamento. - Solo su PHP 8.5:
fatal_error_backtraces = 0. - Se la sua applicazione non utilizza moduli con caricamento di file, blocchi questo tipo di richieste (multipart) a livello del server web o del proxy.
PHP menziona anche la rimozione del limite di memoria (memory_limit = -1). Le consigliamo di usare questa opzione con cautela: una sola richiesta potrebbe consumare tutta la memoria del server.
Usa ancora PHP 8.1 o una versione precedente? Queste versioni non riceveranno patch. Applichi queste misure fin da oggi e pianifichi al più presto una migrazione a PHP 8.4 o 8.5.
Siamo qui per aiutarla
Su un server Bare Metal o un VPS mantiene il pieno controllo del suo sistema: non interveniamo in alcun modo sulle sue istanze senza il suo consenso. Per questo ci teniamo a fornirle tutti gli strumenti per agire in modo rapido e sereno.
Da parte nostra, stiamo aggiornando le immagini dei sistemi operativi disponibili per l’installazione e avvisando i clienti le cui istanze sembrano esposte. Integreremo questo articolo se verranno pubblicate nuove informazioni.
Ha una domanda o un dubbio sulla sua configurazione? I nostri team di supporto sono a sua disposizione e i nostri partner possono accompagnarla nell’aggiornamento o nella migrazione delle versioni di PHP.
Per saperne di più