Sicurezza e manutenzione
Due vulnerabilità critiche in PHP: come proteggere il tuo sito?
Vulnerabilità PHP di ottobre 2026: versioni corrette, verifiche dell’hosting e passaggi per aggiornare il tuo sito WordPress o la tua applicazione PHP.
Il mio sito usa PHP: cosa devo fare adesso?
Chiedi al tuo provider di hosting o al responsabile tecnico di confermare la correzione delle due vulnerabilità CVE-2026-109618 e CVE-2026-109619 nell’ambiente che serve effettivamente il tuo sito. Le versioni corrette di PHP sono 8.2.35, 8.3.36, 8.4.27 e 8.5.12; anche un pacchetto del fornitore può contenere le correzioni riportate su una versione precedente. Aggiornare WordPress o i suoi plugin non basta ad aggiornare PHP. Fai verificare l’applicazione della correzione, il riavvio dei processi interessati e i percorsi essenziali del sito.
Un avviso di sicurezza si traduce rapidamente in domande molto concrete per un’azienda: il nostro sito è interessato, chi deve intervenire e come possiamo verificare che il problema sia stato affrontato? Le due vulnerabilità critiche di PHP annunciate a ottobre 2026 richiedono un intervento rapido e coordinato con il responsabile dell’hosting.
Questo aggiornamento, verificato il 23 ottobre 2026, distingue le correzioni disponibili, le verifiche da richiedere e l’organizzazione da prevedere in seguito. Troverai anche i servizi Oryon adatti a valutare la situazione, gestire gli aggiornamenti e monitorare la tua infrastruttura.
Due vulnerabilità confermate, con correzioni già disponibili
Gli avvisi di sicurezza PHP identificano CVE-2026-109618, legata alla gestione dell’esaurimento della memoria, e CVE-2026-109619, legata a uno stato interno mantenuto tra le richieste. Entrambe sono classificate come critiche, con un punteggio CVSS v4 di 9,2 su 10. Uno sfruttamento riuscito può consentire l’esecuzione di codice su un server vulnerabile senza autenticazione.
Il rischio riguarda le installazioni PHP che elaborano richieste web, tra cui PHP-FPM, Apache con mod_php, CGI, FrankenPHP e LiteSpeed. Le condizioni di sfruttamento variano in base all’ambiente. Il 22 ottobre il CERT-FR segnalava prove di fattibilità per alcune configurazioni; ciò non consente di quantificare i siti effettivamente compromessi.
Quasi il 70 %: un dato sull’utilizzo, non un bilancio dei siti compromessi
Al 23 ottobre 2026, W3Techs stima che PHP sia utilizzato dal 69,3 % dei siti di cui è noto il linguaggio lato server. Questo perimetro è importante: non si tratta di tutti i siti del Web, né di un inventario delle installazioni ancora vulnerabili.
Per la tua azienda, la domanda utile riguarda quindi la propria installazione. Un logo WordPress, una pagina che risponde normalmente o una versione mostrata da uno strumento pubblico non bastano a confermare che entrambe le correzioni siano state applicate.
Quali versioni di PHP correggono queste vulnerabilità?
Il progetto PHP ha pubblicato le seguenti versioni il 21 ottobre 2026. Per un’installazione distribuita direttamente da PHP, verifica il ramo in uso e adotta una versione corretta di quel ramo, oppure una versione successiva compatibile con la tua applicazione.
Le distribuzioni Linux possono riportare una correzione su una versione precedente senza adottare questo numero di versione. Ubuntu, ad esempio, ha corretto entrambe le CVE nel pacchetto 8.3.6-0ubuntu0.24.04.13 per Ubuntu 24.04. Chiedi il numero completo del pacchetto e il bollettino corrispondente del fornitore prima di trarre conclusioni dal solo numero di versione di PHP.
PHP 8.1 e i rami precedenti non ricevono più il supporto generale del progetto PHP. Esistono correzioni mirate riportate su queste versioni, ma non ripristinano tale supporto: verifica la copertura del tuo fornitore e prepara una migrazione compatibile. PHP 8.2 raggiunge la fine del supporto il 31 dicembre 2026.
| Ramo PHP | Versione corretta |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Un piano d’azione per il tuo sito o la tua applicazione
Inizia identificando chi può modificare l’ambiente PHP. Su un hosting condiviso, questo intervento spetta generalmente al provider. Su un server amministrato dalla tua azienda, va organizzato con il responsabile tecnico o con il fornitore che gestisce i sistemi. Chi modifica le tue pagine non ha necessariamente accesso al server.
- Inventariare i siti, i sottodomini e le applicazioni PHP interessati, compresi gli ambienti dimenticati ma ancora accessibili.
- Ottenere una conferma che copra entrambe le CVE, il pacchetto o l’immagine installati e l’ambiente web effettivamente utilizzato. La versione da riga di comando può essere diversa da quella del sito.
- Verificare che siano disponibili un backup utilizzabile e una procedura di ripristino, quindi preparare i test di compatibilità. Questa preparazione deve restare proporzionata all’urgenza.
- Applicare la correzione validata con il provider di hosting. Per un container, aggiornare l’immagine, quindi ricreare e distribuire nuovamente le istanze interessate.
- Riavviare i processi PHP o web interessati secondo la procedura dell’ambiente, quindi confermare la versione o il pacchetto effettivamente caricati.
- Testare i moduli, l’accesso, l’amministrazione e, per un negozio, il percorso di acquisto. Registrare il risultato, l’ora dell’intervento e gli eventuali punti ancora da risolvere.
Perché un aggiornamento di WordPress o un firewall non bastano
WordPress, i suoi plugin, il tema e PHP sono componenti distinti. Una bacheca WordPress aggiornata non conferma che l’ambiente PHP abbia ricevuto la correzione. Occorre seguire entrambi i livelli, verificando la compatibilità prima di cambiare ramo PHP.
PHP indica che nessuna misura di mitigazione offre una protezione completa in sostituzione dell’aggiornamento. Il CERT-FR descrive soluzioni provvisorie non validate: alcune riducono soltanto una parte della superficie di attacco e possono compromettere alcune funzioni del sito. Un firewall per applicazioni web può contribuire a una protezione temporanea, senza sostituire la correzione.
Se non è possibile applicare subito la correzione, concorda con il responsabile dell’hosting le restrizioni o l’isolamento temporaneo necessari. In presenza di segni di intrusione, un aggiornamento da solo non dimostra che il server sia integro: conserva i registri disponibili e fai analizzare l’incidente.
Dopo l’urgenza: sapere chi segue gli aggiornamenti
Una manutenzione utile lascia tracce comprensibili: i componenti seguiti, i rispettivi responsabili, le operazioni svolte e le verifiche effettuate. Prevede inoltre la sostituzione delle versioni prossime alla fine del supporto. Senza questa organizzazione, un avviso può far emergere un sito di cui nessuno sa più aggiornare l’hosting.
Chiedi un perimetro scritto: PHP e sistema, CMS e plugin, codice specifico, backup, test di ripristino e monitoraggio. Specifica chi riceve gli avvisi e chi autorizza un intervento urgente. Il risultato atteso è una procedura utilizzabile e documentata; nessun servizio può promettere l’assenza di qualsiasi vulnerabilità.
Come può aiutarti Oryon
Non sai quale versione sia in esecuzione sul tuo sito, chi gestisca PHP o quali aggiornamenti abbiano la priorità? L’audit tecnico Oryon consente di valutare la situazione nel perimetro concordato, classificare i rischi e proporre interventi. L’audit e l’esecuzione delle correzioni sono servizi il cui ambito va definito separatamente.
Per la gestione dei server Linux, il nostro servizio combina inventario, aggiornamenti, monitoraggio e backup con ripristino testato. Per un sito WordPress, il nostro supporto comprende in particolare la ripresa di progetti, la messa in sicurezza e la manutenzione, con preparazione degli interventi e verifiche secondo il preventivo. Definiamo insieme a te ciò che riguarda il provider di hosting, il sito e il codice specifico.
Per preparare il confronto, indica l’indirizzo del sito, il provider di hosting, il CMS utilizzato se lo conosci e la risposta già ricevuta su queste due CVE. Non inviare password tramite il modulo di contatto. Potremo così definire le verifiche e l’intervento adatti al tuo contesto.