Una vulnerabilità critica in PHP. Ma la vera domanda è: sapresti se riguarda la tua azienda?
COSA SIGNIFICA CVE
CVE significa Common Vulnerabilities and Exposures. È un sistema utilizzato per assegnare un identificativo univoco alle vulnerabilità di sicurezza conosciute.
Un codice come CVE-2026-109618, quindi, non indica un virus o un attacco specifico: è il “nome” con cui una determinata vulnerabilità viene identificata e tracciata in modo univoco.
In questo modo produttori, ricercatori, fornitori IT e aziende possono parlare dello stesso problema di sicurezza, verificare quali sistemi sono interessati e valutare gli aggiornamenti o gli interventi necessari.
Vulnerabilità critica in PHP: che cosa è successo
Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti di sicurezza per due vulnerabilità critiche, identificate come CVE-2026-109618 e CVE-2026-109619.
Entrambe possono consentire una Remote Code Execution (RCE) senza autenticazione. Detto in termini meno tecnici: in caso di sfruttamento riuscito, il problema non riguarda semplicemente una pagina web che non funziona correttamente. Si crea la possibilità di eseguire codice sul sistema interessato.
Le versioni pubblicate per correggere le due vulnerabilità sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Il progetto PHP indica come interessate le installazioni che gestiscono richieste web, comprese configurazioni PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed.
PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti dal progetto PHP, anche se alcuni vendor e distribuzioni possono fornire correzioni tramite backport.
Il 23 ottobre PHP ha inoltre pubblicato un advisory relativo a CVE-2026-115560, un ulteriore possibile vettore RCE che richiede però una particolare combinazione di configurazione e codice applicativo descritta dal progetto come insolita. È un dettaglio importante perché ricorda che gli aggiornamenti di sicurezza possono evolvere rapidamente nei giorni successivi alla prima comunicazione.
Remote Code Execution: cosa significa davvero per un’azienda?
Termini come RCE, CVE, CVSS e patch fanno parte del linguaggio quotidiano di chi si occupa di cybersecurity. Per chi gestisce un’azienda, però, dicono poco su una questione molto più concreta: che cosa potrebbe significare una compromissione per i miei sistemi?
Per capirlo è utile cambiare prospettiva. I prossimi esempi non descrivono conseguenze certe delle vulnerabilità critica in PHP appena pubblicate, né casi realmente avvenuti. Sono scenari ipotetici utili a comprendere perché la possibilità di eseguire codice su un sistema vulnerabile viene considerata un rischio importante.
1. Il sito funziona ancora. Ma il server potrebbe essere compromesso
Quando si pensa a un attacco informatico è facile immaginare un sito irraggiungibile, una schermata modificata oppure un servizio completamente bloccato.
Ma l’indisponibilità non è l’unico possibile segnale di una compromissione. Immaginiamo uno scenario nel quale un attaccante riesca a sfruttare una vulnerabilità critica in PHP che consente l’esecuzione di codice. Il sito potrebbe continuare a rispondere alle richieste degli utenti, mentre sul sistema si verifica un’attività non autorizzata.
La lezione: verificare che un sito sia online non equivale a verificare che il sistema che lo ospita sia sicuro.
2. WordPress e i plugin sono aggiornati. Possiamo stare tranquilli?
Un altro equivoco frequente consiste nel far coincidere la sicurezza del sito con l’aggiornamento del CMS. Aggiornare WordPress, plugin e temi è importante, ma un’applicazione web si appoggia a diversi livelli tecnologici.
In questo caso specifico le vulnerabilità si trovano nel motore PHP. Il problema è quindi a un livello differente rispetto al codice di WordPress, di un plugin o del tema.
La lezione: un CMS aggiornato è una componente della sicurezza, non una verifica dell’intero stack tecnologico.
3. Il sistema che nessuno ricordava più
Immaginiamo un’altra situazione. Anni fa l’azienda utilizzava un’applicazione sviluppata internamente oppure fornita da un partner. Nel frattempo il processo è cambiato, è arrivato un nuovo gestionale e quella vecchia applicazione non viene quasi più utilizzata.
Il server, però, è ancora presente. Oppure esiste ancora un’interfaccia web che utilizza PHP e che non rientra più nei normali cicli di verifica e aggiornamento.
A questo punto il problema non è soltanto: “PHP è vulnerabile?”. La domanda precedente è ancora più importante: “Sapevamo ancora di avere quel sistema?”
La lezione: non si può proteggere, aggiornare o dismettere ciò che non si sa più di avere.
La domanda non è “quante vulnerabilità esistono?”
La domanda utile è: quali di queste vulnerabilità riguardano realmente gli asset della mia azienda? Per rispondere serve prima conoscere ciò che è presente nell’infrastruttura e poi mettere le vulnerabilità nel loro contesto.
Contattaci per far analizzare la tua infrastruttura
La parte difficile non è leggere una CVE. È capire se ci riguarda
La vicenda PHP evidenzia un aspetto spesso sottovalutato della sicurezza informatica: conoscere l’esistenza di una vulnerabilità è solo il primo passaggio.
CISA (Cybersecurity and Infrastructure Security Agency) raccomanda alle organizzazioni di identificare e inventariare i sistemi che utilizzano PHP, ricordando che PHP può essere presente anche come componente di altri software e che la sua presenza non è necessariamente evidente.
È un principio che vale ben oltre PHP. Server, PC, applicazioni, sistemi operativi, apparati e software cambiano nel tempo. Alcuni vengono sostituiti, altri rimangono attivi più a lungo del previsto. Nel frattempo vengono scoperte nuove vulnerabilità e pubblicate nuove correzioni.
Per questo la vulnerability management non dovrebbe ridursi alla ricerca occasionale della CVE del giorno. Deve partire dalla visibilità sull’infrastruttura.
Dalla vulnerabilità critica in PHP a una gestione continua del rischio
Il modello reattivo è semplice: emerge una vulnerabilità importante, qualcuno legge la notizia e inizia la ricerca dei sistemi potenzialmente coinvolti.
Un approccio più strutturato parte invece dalla conoscenza degli asset e dalla capacità di collegare le vulnerabilità alle tecnologie effettivamente presenti. Non elimina il rischio e non sostituisce l’attività di remediation, ma permette di affrontare il problema partendo da informazioni più utili.
ConnectSecure e Continuous Vulnerability Assessment: dalla notizia alla visibilità
È in questo contesto che Ventunocento propone un percorso di Continuous Vulnerability Assessment con ConnectSecure.
Il punto non è ricevere una lista sempre più lunga di sigle tecniche. È costruire un processo che aiuti a conoscere gli asset monitorati, rilevare le vulnerabilità e valutarle nel contesto dell’infrastruttura aziendale, così da poter individuare le situazioni sulle quali è opportuno intervenire.
La tecnologia, da sola, non sostituisce la valutazione tecnica. Una vulnerabilità deve essere messa in relazione con il sistema interessato, la sua funzione, l’esposizione e le possibilità di aggiornamento o mitigazione.
È qui che Ventunocento vuole posizionarsi: non come semplice fornitore di uno strumento di scanning, ma come partner che aiuta l’azienda a trasformare una segnalazione tecnica in una decisione comprensibile e gestibile.
Cosa fare davanti a una vulnerabilità critica in PHP
Nel caso delle vulnerabilità critica in PHP pubblicate il 21 ottobre, il progetto PHP raccomanda l’aggiornamento immediato. Le versioni corrette indicate nell’advisory ufficiale sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
CISA raccomanda inoltre di identificare i sistemi che eseguono PHP, dare priorità ai sistemi esposti a Internet e monitorare attività sospette. Per le versioni non più supportate direttamente dal progetto PHP occorre verificare eventuali aggiornamenti forniti dalla propria distribuzione o dal vendor oppure pianificare il passaggio a una versione supportata.
Per chi utilizza hosting gestiti, applicazioni fornite da terzi o prodotti nei quali PHP è una componente interna, diventa importante verificare anche le indicazioni del rispettivo provider o produttore.
In sintesi: il vero rischio è ciò che non conosciamo
Le vulnerabilità PHP di questi giorni verranno corrette. Arriveranno altre patch e, inevitabilmente, emergeranno nuove vulnerabilità critica in PHP e in molte altre tecnologie.
Per un’azienda, quindi, la strategia non può essere inseguire ogni nuovo advisory pubblicato su Internet. Il passaggio più importante è costruire la capacità di rispondere rapidamente a una domanda molto più semplice:
“Questa vulnerabilità critica in PHP riguarda qualcosa che utilizziamo davvero?”
Se per trovare la risposta servono giorni di ricerche, telefonate ai fornitori e controlli manuali, il problema non è soltanto la singola vulnerabilità. È la visibilità sull’infrastruttura.
Sai quali vulnerabilità sono presenti nella tua infrastruttura?
Leggere di una nuova vulnerabilità è facile. Capire se riguarda un server, un’applicazione o un altro asset della propria infrastruttura è un’altra cosa.
Ventunocento affianca le aziende con un approccio di Continuous Vulnerability Assessment basato su ConnectSecure, con l’obiettivo di aumentare la visibilità sugli asset monitorati, individuare le vulnerabilità e supportarne la valutazione nel contesto reale dell’organizzazione.
Prima comprendiamo cosa è presente. Poi valutiamo dove intervenire, Contattaci per valutare la sicurezza della tua infrastruttura.
Fonti utilizzate
PHP – Security advisory: Critical remote code execution vulnerabilities, update now
Advisory ufficiale del progetto PHP, 21 ottobre 2026.
php.net/archive/2026.php
PHP – Informational advisory: Session upload progress
Aggiornamento ufficiale del progetto PHP, 23 ottobre 2026.
php.net/archive/2026.php
CERT-EU – Critical Vulnerabilities in PHP, Security Advisory 2026-018
Advisory aggiornato al 23 ottobre 2026.
cert.europa.eu/publications/security-advisories/2026-018/
CISA – Critical Vulnerabilities in PHP Require Immediate Patching
Alert pubblicato il 21 ottobre 2026.
cisa.gov – Critical Vulnerabilities in PHP Require Immediate Patching